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.