<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>T10 and T20 we can fix/updated to whatever we chose as the "long term solution",<br></div><div>and if we are "useful to the society" we document how the "next generation" should<br data-mce-bogus="1"></div><div>solve the problem. I suggest a 100-Year vision here, and with the current format of 16 bits </div><div>SOMEONE has to make another fix within the 100 years, most likely after I'm gone.....<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Or can we document "today's fix" and the "next fix"?<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>--P<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"John Forecast" <john@forecast.name><br><b>To: </b>"hecnet" <hecnet@Update.UU.SE><br><b>Sent: </b>Wednesday, December 30, 2020 7:17:59 PM<br><b>Subject: </b>Re: [HECnet] DECnet-10 doesn't work past Nov 9 2021?<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br class=""><div><br class=""><blockquote class=""><div class="">On Dec 30, 2020, at 5:11 PM, Johnny Billquist <<a href="mailto:bqt@softjar.se" target="_blank" rel="nofollow noopener noreferrer">bqt@softjar.se</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Well, for another year from now, this isn't even being tested. Only on Nov 9, 2021 will the value exceed 32767, at which point things could potentially become funny.<br class="">VMS apparently seems to just truncate at 15 bits, so it reports dates back in 1977 again after that time. But we don't know if that truncation happens at sender or receiver...<br class=""><br class="">RSX should continue to show correct dates on events up until 2065, treating the value as an unsigned 16 bit value.<br class=""><br class="">Since any kind of fixing will require changes in the code anyway, I do think the least intrusive change is to just adopt what RSX did, and use all 16 bits as an unsigned value, which means nothing really changes beyond that we continue as things are.<br class=""><br class="">If I got things right, VMS might show and/or report dates back in 1977 again. Annoying, but nothing worse than that.<br class=""><br class="">Tops-10 seems to currently do a BUGHLT, so that really needs fixing.<br class=""><br class="">TOPS-20 is a bit unknown, but it might just report wrong dates.<br class=""><br class="">RSTS/E? Paul, could you check? I would hope that maybe the last release/patches would make RSTS/E do the same thing as RSX.<br class=""><br class="">I have no idea about Ultrix or any other implementation. Anyone else who can complement this information with more details?<br class=""><br class=""></div></div></blockquote><div><br class=""></div>It’s pretty painful to test this on Ultrix. The latest version I have a DECnet release for is 4.0 which does not include Y2K patches. In particular, date cannot accept a year past 1999 so you have to keep setting the date/time to 12312359.59, let it roll over the date to the following year and repeat until you get to the desired year. That said, it doesn’t crash but it does generate some strange dates - probably because it’s expecting to display the year in 2 digits:</div><div><br class=""></div><div><div style="margin:0px;font-stretch:normal;font-size:10px;line-height:normal;font-family:'monaco'" class=""><span class=""> Event type 4.15, Adjacency up</span></div><div style="margin:0px;font-stretch:normal;font-size:10px;line-height:normal;font-family:'monaco'" class=""><span class="">Occurred 18-Sep-212 12:00:13.0 on node 63.223</span></div><div style="margin:0px;font-stretch:normal;font-size:10px;line-height:normal;font-family:'monaco'" class=""><span class="">Circuit QNA-0</span></div><div style="margin:0px;font-stretch:normal;font-size:10px;line-height:normal;font-family:'monaco'" class=""><span class="">Adjacent node = 63.2</span></div><div style="margin:0px;font-stretch:normal;font-size:10px;line-height:normal;font-family:'monaco';min-height:14px" class=""><span class=""></span><br class=""></div><div style="margin:0px;font-stretch:normal;font-size:10px;line-height:normal;font-family:'monaco';min-height:14px" class=""><span class=""></span><br class=""></div><div style="margin:0px;font-stretch:normal;font-size:10px;line-height:normal;font-family:'monaco'" class=""><span class="">date</span></div><div style="margin:0px;font-stretch:normal;font-size:10px;line-height:normal;font-family:'monaco'" class=""><span class="">Sun Jan 1 00:00:35 EST 2023</span></div><div class=""><span class=""><br class=""></span></div><div class=""><span class=""> John.</span></div><div class=""><span class=""><br class=""></span></div></div><div><blockquote class=""><div style="margin:0px;font-stretch:normal;font-size:10px;line-height:normal;font-family:'monaco'" class=""><br class=""></div><div class="">We could perhaps create a page with a summary of what we know.<br class=""><br class=""> Johnny<br class=""><br class="">On 2020-12-30 23:00, Thomas DeBellis wrote:<br class=""><blockquote class="">Ah, I got it; I was counting and thinking the wrong way.<br class="">If RSX is using unsigned and hasn't blown up, then I don't see why anybody else shouldn't at least have a look. I'll have to check further into the Tops-20 conditional to see what it's all about; the code is completely different from Tops-10. The question is where else it might be being handled.<br class="">I have sources to everything except the Tops-20 NICE process; NMLT20, so if I have to fix something there... That's a bummer; we were a source site and asked for years (particularly for early versions which would crash if you looked at them wrong). I don't suppose anybody having ever heard of this; it appears to have been write in some variant of BLISS.<br class="">Meanwhile, if anybody wants to try my trivial patch to D36COM, I'd like to hear about it. I'm pretty sure it will keep your Tops-10 machine from crashing...<br class="">On 12/28/20 11:20 PM, Johnny Billquist wrote:<br class=""><blockquote class="">Argh. 32766 would be 77776 of course, and so on... But I hope people get the idea. I see no reason why not just treat it as an unsigned 16 bit value for now.<br class=""><br class="">And as Peter suggest, if we want to extend things further, we can change the base. But simply going unsigned already gives us 44 more years to think about it. And at least RSX have already done this since 20 years ago.<br class=""><br class=""> Johnny<br class=""><br class="">On 2020-12-29 05:18, Johnny Billquist wrote:<br class=""><blockquote class="">16363 days, means 32766 half days, which is octal 77777, which is 7FFF hex. 16 bits can hold up to 65535, which is 177777 octal, or FFFF hex, if treated unsigned. Which with the current encoding will cover up to the year 2065.<br class=""><br class=""> Johnny<br class=""><br class="">On 2020-12-29 05:06, Thomas DeBellis wrote:<br class=""><blockquote class="">I did some date arithmetic; there are 16,383 days between 1/1/1977 and 11/9/2021.<br class=""><br class="">Since Tops-10 is calculating by half days, that's why I clamp it to the unsigned octal value of 177777 (3FFF hex).<br class=""><br class="">Would a later version of NICE have expanded this to four bytes? That seems like the thing to do.<br class=""><br class="">On 12/28/20 11:00 PM, Johnny Billquist wrote:<br class=""><blockquote class="">Uh? It seemed VMS is treating it as signed, and/or wrapping at 15 bits, so it fails after Nov 9, 2021.<br class=""><br class="">Why not just do as RSX, and treat it as unsigned 16 bits. Which leaves it working correct until 2065.<br class=""><br class="">If we, at some point, want to change things after that, we can either change the format, or change the base year.<br class=""><br class=""> Johnny<br class=""><br class="">On 2020-12-29 04:52, Thomas DeBellis wrote:<br class=""><blockquote class="">So it appears that NICE wants the Julian half day count in an unsigned short, or 16 bits; that seems obvious enough.<br class=""><br class="">I wrote a Tops-10 patch to have it wrap like what appears to be happening on OpenVMS.<br class=""><br class="">In D36COM.MAC at NMXTIM+9, change the following two lines (which skip or fall into the COM911 BUGHLT),<br class=""><br class=""> SKIPL T2 ;MAKE SURE WE HAVE A POSITIVE NUMBER OF SECONDS<br class=""> TDNE T1,[XWD -1,600000] ;MAKE SURE NO DATE OVERFLOW<br class=""><br class="">to<br class=""><br class=""> SKIPGE T2 ;Do WE HAVE A POSITIVE NUMBER OF SECONDS?<br class=""> MOVMS T2 ; No. Fine, now we're plenty positive<br class=""> TDZA T1,[XWD -1,600000] ;MAKE SURE never any DATE OVERFLOW ever<br class=""><br class="">However, I don't run any Tops-10 systems, so if anybody wants to try this and let me know, that would be appreciated. Better to wrap the count than to just stop code. At WPI, we would have considered that 'rude'.<br class="">------------------------------------------------------------------------ <br class="">On 12/28/20 10:08 PM, Thomas DeBellis wrote:<br class=""><blockquote class=""><br class="">If I'm understanding this correctly, it would seem to indicate that there is no reason for Tops-10 to crash because of a Julian half day roll over. I had verified that there is no problem with the internal time for system logging (I.E., the records that SPEAR gets out of ERROR.SYS).<br class=""><br class="">Tops-10 and Tops-20 share the same internal time format (a significant difference between Tops-20 and TENEX), even if Tops-10 doesn't handle it properly as an unsigned word, it will still handle events up to 27-Sep-2217. Since that's over 196 years from now, I would assume this is adequate time to really address the problem.<br class=""><br class="">I'll take another look at the code and see if I can't come up with a workaround.<br class=""><br class="">Meanwhile, I wanted to make sure I understood what was going on where with the output below. Which OPCOM is running where? Is this only OPCOM output from APOLLO as HERMES comes up and sends a circuit up message? The START /NETWORK DECNET is issued on HERMES?<br class=""><br class="">On 12/27/20 8:17 PM, Jason Brady wrote:<br class=""><blockquote class="">Ah...here are the test system (HERMES) operator log messages (notice the 31-JAN-1977 00:00:06.21 timestamp):<br class=""><br class="">$ START /NETWORK DECNET<br class="">%%%%%%%%%%% OPCOM 27-DEC-2022 16:41:31.22 %%%%%%%%%%%<br class="">Message from user DECNET on HERMES<br class="">DECnet starting<br class=""><br class="">%RUN-S-PROC_ID, identification of created process is 00000125<br class="">%DCL-I-SUPERSEDE, previous value of MOM$SYSTEM has been superseded<br class="">%DCL-I-SUPERSEDE, previous value of MOM$SYSTEM_NOSOFTID has been superseded<br class="">%DCL-I-SUPERSEDE, previous value of MOM$SYSTEM_SOFTID has been superseded<br class="">%NCP-I-NOINFO, No information in database<br class="">%RUN-S-PROC_ID, identification of created process is 00000127<br class="">$<br class="">%%%%%%%%%%% OPCOM 27-DEC-2022 16:41:36.76 %%%%%%%%%%%<br class="">Message from user DECNET on HERMES<br class="">DECnet event 4.10, circuit up<br class="">From node 2.404 (HERMES), 31-JAN-1977 00:00:06.21<br class="">Circuit EWA-0<br class=""><br class="">$<br class="">%%%%%%%%%%% OPCOM 27-DEC-2022 16:41:41.87 %%%%%%%%%%%<br class="">Message from user DECNET on HERMES<br class="">DECnet event 4.15, adjacency up<br class="">>From node 2.404 (HERMES), 31-JAN-1977 00:00:06.21<br class="">Circuit EWA-0, Adjacent node = 2.400 (APOLLO)<br class=""><br class="">And from APOLLO adjacent node (down/up when DECnet cycled):<br class=""><br class="">APOLLO-><br class="">%%%%%%%%%%% OPCOM 27-DEC-2020 16:31:27.60 %%%%%%%%%%%<br class="">Message from user DECNET on APOLLO<br class="">DECnet event 4.18, adjacency down<br class="">From node 2.400 (APOLLO), 27-DEC-2020 16:31:27.59<br class="">Circuit EWA-0, Adjacent node listener receive timeout<br class="">Adjacent node = 2.404 (HERMES)<br class=""><br class="">APOLLO-><br class="">%%%%%%%%%%% OPCOM 27-DEC-2020 16:42:33.54 %%%%%%%%%%%<br class="">Message from user DECNET on APOLLO<br class="">DECnet event 4.15, adjacency up<br class="">From node 2.400 (APOLLO), 27-DEC-2020 16:42:33.54<br class="">Circuit EWA-0, Adjacent node = 2.404 (HERMES)<br class=""><br class=""><br class="">On Sun, Dec 27, 2020, at 5:03 PM, Paul Koning wrote:<br class=""><blockquote class="">That doesn't fully answer the question. What you see is the system log, which presumably uses VMS time stamps. Those have a wide range. The question is what the DECnet events would show, when encoded in the NICE protocol. If you configure it to send events (like node reachable or circuit up) to another node, what do the timestamps look like on that other node?<br class=""><br class="">paul<br class=""><br class=""><blockquote class="">On Dec 27, 2020, at 7:42 PM, Jason Brady <<a href="mailto:jr_brady@fastmail.com" target="_blank" rel="nofollow noopener noreferrer">jr_brady@fastmail.com</a> <<a href="mailto:jr_brady@fastmail.com" target="_blank" rel="nofollow noopener noreferrer">mailto:jr_brady@fastmail.com</a>>> wrote:<br class=""><br class="">Booted test Alpha system running OpenVMS 8.4 and set the date to 27-DEC-2022. Started DECnet Phase IV. No errors.<br class=""><br class="">From node APOLLO, no problem transferring files from the test system and displaying network info (TELL ... SHOW EXEC, etc.).<br class=""><br class="">Snippet from test system NML$SERVER.LOG:<br class=""><br class="">--------------------------------------------------------<br class=""> Connect request received at 27-DEC-2022 16:29:25.54<br class=""> from remote process APOLLO::"0=JASON"<br class=""> for object "SYS$COMMON:[SYSEXE]NML.EXE"<br class="">--------------------------------------------------------<br class=""><br class="">Snippet from test system FAL$SERVER.LOG:<br class=""><br class="">--------------------------------------------------------<br class=""> Connect request received at 27-DEC-2022 16:26:56.85<br class=""> from remote process APOLLO::"0=JASON"<br class=""> for object "SYS$COMMON:[SYSEXE]FAL.EXE"<br class="">--------------------------------------------------------<br class=""><br class="">Is the above satisfactory, at least for OpenVMS Alpha?<br class=""><br class="">Regards,<br class="">Jason<br class=""><br class="">On Sun, Dec 27, 2020, at 10:06 AM, Robert Armstrong wrote:<br class=""><blockquote class="">> John Forecast wrote:<br class="">>DECnet event logging for any system may fail after Nov 9th 2021.<br class=""><br class=""> Oh, that's a much bigger deal! Do you happen to know if VMS handles this field as unsigned?? A lot of people here are going to be bummed if VMS quits working next fall...<br class=""><br class="">Bob<br class=""></blockquote></blockquote></blockquote><br class=""></blockquote></blockquote></blockquote><br class=""></blockquote></blockquote><br class=""></blockquote><br class=""></blockquote></blockquote><br class="">-- <br class="">Johnny Billquist || "I'm on a bus<br class=""> || on a psychedelic trip<br class=""><a href="mailto:bqt@softjar.se" target="_blank" rel="nofollow noopener noreferrer">email: bqt@softjar.se</a> || Reading murder books<br class="">pdp is alive! || tryin' to stay hip" - B. Idol<br class=""></div></blockquote></div><br class=""><br></blockquote></div></div></body></html>