RT-11 MACRO V5.05 Y2K crash 4-Mar-2008 and fix - VMS

This is a discussion on RT-11 MACRO V5.05 Y2K crash 4-Mar-2008 and fix - VMS ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: RT-11 MACRO V5.05 Y2K crash 4-Mar-2008 and fix

  1. RT-11 MACRO V5.05 Y2K crash 4-Mar-2008 and fix


    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

  2. Re: RT-11 MACRO V5.05 Y2K crash 4-Mar-2008 and fix

    >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?

    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'.

  3. Re: RT-11 MACRO V5.05 Y2K crash 4-Mar-2008 and fix

    On Tue, 22 Apr 2008 21:23:17 -0400, "Jerome H. Fine"
    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

    >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.


    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

  4. Re: RT-11 MACRO V5.05 Y2K crash 4-Mar-2008 and fix

    >paramucho wrote:

    >>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

  5. Re: RT-11 MACRO V5.05 Y2K crash 4-Mar-2008 and fix

    >Jerome H. Fine wrote:

    > 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

  6. Re: RT-11 MACRO V5.05 Y2K crash 4-Mar-2008 and fix

    >Jerome H. Fine wrote:

    > 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

+ Reply to Thread