CLASSICCMP(a)trailing-edge.com wrote:
In addition,
some of the code in RT-11 in the monitor and elsewhere
rejects a date value with a year value of zero - meaning that 1972 is
considered invalid by that code.
This was fixed in RT-11 5.7, it now consistently
handles 1972 through
2099, inclusive.
Jerome Fine replies:
I am confused here just a little bit. And I am not taking exception to
what was done in V5.7 - in fact, I believe that the decisions which were
made were correct. However, if "this was fixed in RT-11 V5.7" is
what I think the word "fixed" means, then not allowing the command:
"DATE 01-Jan-72"
in all versions of RT-11 which did allow the command "DATE 01-Jan-73"
means that these previous versions had a "bug". If a "bug" is the
correct
interpretation for not allowing a year of 1972, I wonder why the developers
of RT-11 never corrected that aspect in all the years of RT-11 development?
Personally, I always was confused that DIR accepted 1972 as a perfectly
legal DATE to be displayed, but then RT-11 in general, regarded 1972
as invalid. I felt that aspect was a "bug" in itself, but nothing to complain
about. There were too many other serious bugs to be fixed first.
the DATE/TIME
hardware clock on the third party board. Any idea
how the 11/93 does the 1999 transition with the now Y2K compliant
firmware update?
Look in the NL.MAC source code - the SETUP.SAV window range was
chosen identically:
I stated my question incorrectly. I know how the DATE value is divided
in the different 4 fields. What I was specifically wondering about was how
DATE/TIME values in the 11/93 were handled before the firmware on the
11/93 was made Y2K compliant as what happens now - if indeed anything
is different? I have seen references to the upgrade needed by the 11/93
firmware to make it Y2K compliant. What I am curious about is how the
Y2K compliant firmware for the 11/93 handles the year and if that was
any different before the 11/93 firmware was made Y2K compliant.
Sincerely yours,
Jerome Fine
