RT-11 MACRO V5.05 Y2K crash 4-Mar-2008 and fix
paramucho
MACRO V5.05 crashed on 4-Mar-2008.
It's a coding bug. MACRO was bit clearing a 5-bit rather than 4-bit
field for the month. The fix:
Loc Old New
62160 177740 177760
For other versions you're looking for this sequence:
Old New
000315
006215
006215
042725
177740 177760
010015
Jerome H. Fine
Jerome Fine replies:
This is the first post about RT-11 that I have seen in a long time. Do you
know of any other individuals who still use RT-11? Have you received
any other e-mails from RT-11 users?
By the way, I can make available a full Y2K fix for V05.05 of MACRO
which includes a 4 digit year - as opposed to DEC's version which only
supports a 2 digit year. Almost two hundred words need to be modified,
so an SLP file is probably the way to submit it. Naturally, the patch
includes the above modification along with checking the extra two bits
for the year in the date word.
I also expanded the time of assembly to include seconds and decimal
fraction of seconds to the nearest hundredth of a second. However,
most users do not want that sort of accuracy. In addition, what looks
like a decimal fraction of seconds (after the period in the value for the
Elapsed Tine) for the assembly time is actually ticks. I changed that to
a decimal fraction of seconds to the nearest hundredth of a second.
These latter two changes are optional and require a single instruction
each to enable or disable via a tiny SLP file - each option can be
enabled or disabled independently so that four SLP files are used.
There is also one other problem when a cross-reference is requested.
As long as MACRO.SAV and CREF.SAV are located on SY:, there
is not a problem. Otherwise, CREF.SAV does not return to the file
which invoked it. I have not solved that bug at this point.
I can include the SLP file if anyone is interested. In addition, if anyone
is using V05.03 of RT-11 for hobby use under SIMH, the version of
the MACRO.SAV file is V05.03b for that release. It should be fairly
easy to change any offsets in the SLP file to support the Y2K changes
required - except that you will also obviously need the rest of the files
in V05.03 of RT-11 made Y2K compliant as well. While not all of them
are essential, the most important are probably DIR and PIP followed by
IND, LINK, LIBR and BUP.
Sincerely yours,
Jerome Fine
--
To obtain the actual e-mail address, please remove
the ten characters which immediately follow the 'at'.
paramucho
<jhfin...@dp3knospamcompsys.to> wrote:
> >paramucho wrote:
>
>>MACRO V5.05 crashed on 4-Mar-2008.
>>
>>It's a coding bug. MACRO was bit clearing a 5-bit rather than 4-bit
>>field for the month. The fix:
>>
>>Loc Old New
>>62160 177740 177760
>>
>>For other versions you're looking for this sequence:
>>
>>Old New
>>000315
>>006215
>>006215
>>042725
>>177740 177760
>>010015
>>
>Jerome Fine replies:
>
>This is the first post about RT-11 that I have seen in a long time. Do you
>know of any other individuals who still use RT-11? Have you received
>any other e-mails from RT-11 users?
No
I just want the assembler to keep working -- I rarely look at
listings. I've gotten used to the crazy dates in the LINK maps.
Ian
Jerome H. Fine
>>Jerome Fine replies:
>>
>>This is the first post about RT-11 that I have seen in a long time. Do you
>>know of any other individuals who still use RT-11? Have you received
>>any other e-mails from RT-11 users?
>>
>No
>
>
Jerome Fine replies:
I suspect that a few individuals may still be writing code under RT-11,
but perhaps they are too embarrassed to admit it publicly. Since I will
be 70 years old this summer, it is no longer a problem. I also don't mind
admitting that I am addicted to RT-11.
>>I can include the SLP file if anyone is interested. In addition, if anyone
>>is using V05.03 of RT-11 for hobby use under SIMH, the version of
>>the MACRO.SAV file is V05.03b for that release. It should be fairly
>>easy to change any offsets in the SLP file to support the Y2K changes
>>required - except that you will also obviously need the rest of the files
>>in V05.03 of RT-11 made Y2K compliant as well. While not all of them
>>are essential, the most important are probably DIR and PIP followed by
>>IND, LINK, LIBR and BUP.
>>
>>
>
>I just want the assembler to keep working -- I rarely look at
>listings. I've gotten used to the crazy dates in the LINK maps.
>
I agree that the correct date on a listing does not add very much. The
commercial
fellows like to document things more carefully - not that there are many
left who
are writing programs.
As for Y2K, what I really want is to document what is required to
support Y9K
dates. My current concept is to add a 16 bit word to extend the date
value so
that the year has the 7 bits in the current word plus 16 more for a
total of 23 bits.
Since that seems like overkill, perhaps some of the top bits may needed
as flag
bits of some kind. In addition, if updates to programs that run under
all V05.0x
versions of RT-11 are considered a priority (so that hobby users also
have access
to Y9K dates using V05.03 of RT-11), then probably a bit in SYSGEN would
also be reasonable. If the next available word in the fixed offsets for
V05.07 is
used, then V05.03 of RT-11 could be assembled with that extra word as well
(leaving a few extra words unused). At some point (perhaps in 90 years
around
2099), it seems probable that all RT-11 code might actually become legally
available to all users and it would be rather "nice" if there was a Y9K
version
waiting in the wings.
Comments are requested as to the above proposal to handle Y9K and any other
bug fixes and enhancements.
If there is no response, I will continue to produce Y2K versions of
V05.03 RT-11
utilities with enhancements as well. After that, I will make the
patches needed to
the source files for the Resident Monitor and KMON to support Y9K.
Does anyone else want to participate?
Sincerely yours,
Jerome Fine
Jerome H. Fine
> There is also one other problem when a cross-reference is requested.
> As long as MACRO.SAV and CREF.SAV are located on SY:, there
> is not a problem. Otherwise, CREF.SAV does not return to the file
> which invoked it. I have not solved that bug at this point.
Jerome Fine replies:
While I was checking some of the code which controls the
banners at the top of each page, I noticed the code which
is used to .Chain to SY:CREF.SAV from SY:MACRO.SAV, or
that is what I see up to now.
It should be fairly easy to determine the device where
the MACRO.SAV file resides via a .CStatus request. At
that point, the SY: can be changed to the actual device.
Does this seem reasonable?
What if CREF.SAV is not on the same device as MACRO.SAV?
A .LookUp could be used to verify that CREF.SAV exists on
the same device as MACRO.SAV and if it doesn't, change the
device for CREF.SAV back to SY: so at least there would
be an alternative. Can anyone think of a more appropriate
solution?
Sincerely yours,
Jerome Fine
Jerome H. Fine
> While I was checking some of the code which controls the
> banners at the top of each page, I noticed the code which
> is used to .Chain to SY:CREF.SAV from SY:MACRO.SAV, or
> that is what I see up to now.
>
> It should be fairly easy to determine the device where
> the MACRO.SAV file resides via a .CStatus request. At
> that point, the SY: can be changed to the actual device.
> Does this seem reasonable?
>
> What if CREF.SAV is not on the same device as MACRO.SAV?
> A .LookUp could be used to verify that CREF.SAV exists on
> the same device as MACRO.SAV and if it doesn't, change the
> device for CREF.SAV back to SY: so at least there would
> be an alternative. Can anyone think of a more appropriate
> solution?
Jerome Fine replies (again):
With no other suggestions, I noticed that it is almost trivial to
add one additional device, namely CS:, to the list that is
available for the location of CREF.SAV; this would result in:
(a) CS: is checked first by performing a .LookUp on CS:CREF.SAV;
if the CS: device is not valid or the file CS:CREF.SAV is not
found, then use (b).
(b) The same device as dev:MACRO.SAV is then checked by performing
a .LookUp using dev:CREF.SAV; if the file dev:CREF.SAV is not
found, then use (c).
(c) SY: is then used as the final default - a .LookUp is NOT done for the
file SY:CREF.SAV since if it can't be found, no recovery is possible.
The reason that I used CS: was so CS: could be a READ ONLY device
whereas WF: and CF: must be writable.
Note that CS: would not need to be LOADed prior to CS:CREF.SAV being
executed since RT-11 automatically performs a LOAD of CS: prior to
executing the CS:CREF.SAV file. This might be a problem when a command
file uses MACRO.SAV to perform many times without first exiting. On
the other hand, if memory is extremely limited and a command file is used
to invoke MACRO.SAV separately each time, then in-between each time
that MACRO.SAV is run, it would also be possible to:
UNLOAD CS:
By the way, does anyone have a set of current source files for MACRO.SAV?
90% of the changes were needed because the date string is 2 extra characters
for the year and the date buffers could not be expanded.
Are there any other bugs in MACRO.SAV or CREF.SAV that need correcting?
Are there any enhancements that would be useful?
Sincerely your,
Jerome Fine