After sending my last update on 36 bit DECnet, I went back to working a
large ALGOL program from 1980 that I recently scanned. Again, the ALGOL
that ships with PANDA is quite old, dating to 10A145, whereas the most
recent version I picked up from a Tops-10 site on HECnet is 10B310--so
I've been dusting that off.
I remembered that it is not Y2K compliant, so I quick fixed it, in
ALGCON.MAC. at DEC2:, change
DEC2:?? IDIVI A4,^D10???????? ; A4=TENS, A5=ONES
TO:
DEC2:?? CAIG??? A4,^D99???????? ;[T143] After 1999?
???????? JRST?? DEC2A?????????? ;[T143]? Nope, nothing to fix
??????? SUBI??? A4,^D100??????? ;[T143] Reduce by a century
??????? JRST??? DEC2A?????????? ;[T143] Check if in right century
DEC2A:? REMARK????????????????? ;[T143] Here when year is in range
??????? IDIVI?? A4,^D10???????? ; A4=TENS, A5=ONES
Simple enough.? And then something in the back of my mind started
recalling a comment that such fixes wouldn't work after 2052.? A dim
memory surfaced about my first DECtape in 1975 (it was a birthday
present) that I had to have updated because of something called 'DATE75'.
So I went spelunking and here is what DATE75 is all about. Briefly,
/very/ early versions of Tops-10 could only handle dates between January
1^st 1964 and January 4^th 1975.?? 3 additional bits were found in the
directory and other formats that brought the end date out to February
1^st 2052--a fine hack.
Anyway, a number of things broke in 1975 when the first bit started
getting used, which is why apparently somebody had to play with my
DECtape.? Bugs were also found (times being off by 11 years and four
days) in January 8^th 1986 when the 2^nd bit started being used.
It may very well be that, despite my kludge to prevent Tops-10 from
crashing in November of next year, it may drop dead before the NICE
field is expired in 2052.
I think it might depend on what overflows in the result of the DATE
UUO.? Unfortunately, its format deeply confused me in High School, but
maybe I'll have another look after all these year.