Updated 2018-01-15T04-10Z

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

A nightmare.

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

Happy New Year!

• Click here for my Personal Homepage
• Or follow a link about MENTEC 's related endeavour
• This page is pointed to by 2000.klug-suchen.de .