CLASSICCMP RT-11 BUG LIST by Jerome H. Fine V1.1 - DRAFT - June 10th, 2003 This document is a first attempt to set up the Classiccmp RT-11 Bug List. Over the years, it is hoped that it will become one of the essential documents that RT-11 users will consult. Since these initial drafts are considered to be open to any and all changes, please feel free to contact the author to make suggestions. In addition, this list will only be useful if there are contributions from as many RT-11 users as possible. Even if you are not sure, please inform the current list person (initially the first author) of as many problems about RT-11 as you are aware of. My current e-mail address is: Jerome H. Fine Unfortunately, after more that a year of existance for V1.0, no feedback has occurred. While this does limit the usefulness of the Bug List, I will continue to add additional bugs when I have the time. Due to spam, the above e-mail address may be discontinued. In that case, please send a note to the classiccmp list - currently at: cctalk@classiccmp.org and I will respond since I am a list member. In order to get the Classiccmp RT-11 Bug List off to as rapid and as early a start as possible, the first two bugs to be reported were not be very important. While a patch will be developed if users demonstrate sufficient interest, that will not be a high priority. OPERATING SYSTEM BUGS ----------------------- RT11SJ.SYS RT11SB.SYS RT11FB.SYS RT11XM.SYS DEVICE DRIVER BUGS -------------------- SLX.SYS PROGRAMS WITH BUGS -------------------- MACRO.SAV (a) All current and old versions - the number of digits when the year is displayed on the listing is only two. A four digit year is required. (b) At the end of the listing, the "Elapsed time:" is displayed. The format seems to be: HH:MM:SS.th where HH = number of Hours MM = number of Minutes SS = number of Seconds t = tenths of a second h = hundredths of a second In actual fact, while the above assumptions are correct for HH, MM and SS, the "t" and "h" assumptions are quite wrong. Rather, the "th" value is the number of ticks left over out of a full second. For a 60 Hz clock, this value is between 0 and 59 while for a 50 Hz clock, the range is between 0 and 49. For example, for an assembly which has an Elapsed time of 00:00:01.59 (obviously for a system with a 60 Hz clock), an assembly which takes 16 milliseconds longer will have an Elapsed time of 00:00:02.00 which is not what is expected. (c) CHAIN from MACRO.SAV => SY:CREF.SAV When a cross-reference is required after MACRO.SAV is complete, a CHAIN is made to SY:CREF.SAV with the required information passed in the appropriate manner. However, if MACRO.SAV was initiated on a device other than SY:, then the default device from which the CREF.SAV program is initiated should be the same device as from which MACRO.SAV was initiated followed by DK: followed by SY: as a last resort. (d) Use of VBGEXE to initiate MACRO In cases when there is insufficient low memory to run MACRO along with those times when the user wishes to make more table space available so that MACRO runs more quickly, there needs to be a flag set for CREF.SAV so that a CHAIN back to MACRO.SAV is done via VBGEXE rather than directly back to the MACRO.SAV program. CREF.SAV (a) CHAIN from CREF.SAV => SY:MACRO.SAV When a cross-reference is required after MACRO.SAV is complete, a CHAIN is made to CREF.SAV with the required information passed in the appropiate manner. However, if MACRO.SAV was initiated on a device other than SY:, then there is no provision to CHAIN back to the original MACRO.SAV on whatever device it was originally situated. (b) When MACRO.SAV was initiated via VBGEXE, CREF.SAV should be able to CHAIN back to MACRO.SAV, but first invoking VBGEXE. LIBR.SAV (a) The display of the date and time by this utility is noticibly different as compared with the same information when displayed by the LINK utility. At present, the format for a library seems to be: DAY NN-MMM-YY HH:MM:SS where DAY = 3 character Day name of the week - all capitals NN = 2 digit day Number of the month MMM = 3 character alphabetic Month of the year - all capitals YY = last two decimal digits of the Year HH = 2 digit number of Hours MM = 2 digit number of Minutes SS = 2 digit number of Seconds t = 1 digit tenths of a second h = 1 digit hundredths of a second In order to be compatible with the same output from the LINK.SAV program, the above information should be modified to be to be output as: Day NN-Mmm-YYYY HH:MM:SS.th where Day = 9 character day of the week with a leading capital NN = 2 digit day Number of the month Mmm = 3 character Month of the year with a leading capital YYYY = 4 digit number of the Year HH = 2 digit number of Hours MM = 2 digit number of Minutes SS = 2 digit number of Seconds t = 1 digit tenths of a second h = 1 digit hundredths of a second (b) For a system which uses a 50 Hz clock, the display of the time will be incorrect when the values have been passed from a system which used a 60 Hz clock. In a similar manner, a system which uses a 50 Hz clock will save a time stamp which a system that uses a 60 Hz clock will not display correctly. The solution may be to define a flag bit which saves the clock rate of the system which produced the time stamp. DUP.SAV (a) When the RT-11 command: COPY/DEVICE DU0:/START:65535./END:65535. DU1:/START:65535. is executed, the result is correct. However, the commands: COPY/DEVICE DU0: DU1: COPY/DEVICE DU0:/START:0./END:65534. DU1:/START:0. COPY/DEVICE DU0:/START:0./END:65535. DU1:/START:0. all result in the same identical action without even a warning message from the use of "/END:65535." whereas the command: COPY/DEVICE DU0:/START:1./END:65535. DU1:/START:1. at least provides the user with a warning message that DU1: (the output device) is smaller than DU0: For thoss users who are not aware of the problem, RT-11 assumes that block "65535." does not actually exist in an RT-11 partition of 65536 blocks due to problems with the SIZE request. But, since it not only exists, but it is possible to copy block "65535." to another device, then the bug in DUP should be fixed. On the other hand, since a work around (when JUST ONE block is written) exists fixing the bug is considered a low priority at the present time.