Heavy New Year?
Supposed, you run an RT-11® operating system
on your good old
DEC® machine or even on a brand-new clone.
The O/S is, for
instance, a version 5.5 (i. e. the one made in 1989). In the first
days of the year 2000, you attempt to hack the new system DATE into
This is the end of the days for the unpatched
RT-11®s up to version 5.6:
Neither does the monitor eat the DATE, nor do the DIR, PIP,
BUP, QUEMAN or ERROUT utilities cope with the according options
renames the new century to "-BAD-" date both in its header and in
the listing entries. Even worse, from 2036 on,
the PIP tool confuses the extended DATE with the PROTECTION flag.
FSM writes a wrong system year onto magtapes from 2000 on.
In IND.SAV, the string symbol <DATE> is useless. The SPOOL
handler is unable to print the accurate calendar date on the flag
page, neither do this MACRO.SAV nor LINK.SAV nor LIBR.SAV within
their page headers. Only IDATE and DATE4Y (=DATE) in SYSLIB.OBJ
are up to date already.
Yet, as you may imagine, there is help. The scene
professionals call it the solution of the "Y2k" problem. For my
machine, I have invested the necessary considerable period of time into
the version 5.5 of RT-11® to make it
operate perfectly for another
100 years until the 31-DEC-2099. And it does. So, I know
how to do
that. Before you are going to suffer from the same nightmare,
I suggest you to check
for help. After all, the best wishes should work again as usual:
Happy New Year!
Search strings for full-text search engines,
which do not scan Meta keywords:
Y2k, Year2k, Year2000, Date2k, Date, 2000, Date2000,
RT-11, RT11, RT 11, V5.5, V 5.5, V 5.05, V5.05,
epoch bits, age bits, era bits