[HECnet] DECnet-10 doesn't work past Nov 9 2021?

I did some date arithmetic; there are 16,383 days between 1/1/1977 and 11/9/2021. Since Tops-10 is calculating by half days, that's why I clamp it to the unsigned octal value of 177777 (3FFF hex). Would a later version of NICE have expanded this to four bytes? That seems like the thing to do. On 12/28/20 11:00 PM, Johnny Billquist wrote: > Uh? It seemed VMS is treating it as signed, and/or wrapping at 15 > bits, so it fails after Nov 9, 2021. > > Why not just do as RSX, and treat it as unsigned 16 bits. Which > leaves it working correct until 2065. > > If we, at some point, want to change things after that, we can either > change the format, or change the base year. > > ? Johnny > > On 2020-12-29 04:52, Thomas DeBellis wrote: >> So it appears that NICE wants the Julian half day count in an >> unsigned short, or 16 bits; that seems obvious enough. >> >> I wrote a Tops-10 patch to have it wrap like what appears to be >> happening on OpenVMS. >> >> In D36COM.MAC at NMXTIM+9,? change the following two lines (which >> skip or fall into the COM911 BUGHLT), >> >> ???????? SKIPL T2??????????????? ;MAKE SURE WE HAVE A POSITIVE >> NUMBER OF SECONDS >> ???????? TDNE T1,[XWD -1,600000] ;MAKE SURE NO DATE OVERFLOW >> >> to >> >> ???????? SKIPGE T2?????????????? ;Do WE HAVE A POSITIVE NUMBER OF >> SECONDS? >> ????????? MOVMS T2?????????????? ; No.? Fine, now we're plenty positive >> ???????? TDZA T1,[XWD -1,600000] ;MAKE SURE never any DATE OVERFLOW >> ever >> >> 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'. >> ------------------------------------------------------------------------ >> >> On 12/28/20 10:08 PM, Thomas DeBellis wrote: >>> >>> 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). >>> >>> 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. >>> >>> I'll take another look at the code and see if I can't come up with >>> a workaround. >>> >>> 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? >>> >>> On 12/27/20 8:17 PM, Jason Brady wrote: >>>> Ah...here are the test system (HERMES) operator log messages >>>> (notice the 31-JAN-1977 00:00:06.21 timestamp): >>>> >>>> $ START /NETWORK DECNET >>>> %%%%%%%%%%%? OPCOM? 27-DEC-2022 16:41:31.22? %%%%%%%%%%% >>>> Message from user DECNET on HERMES >>>> DECnet starting >>>> >>>> %RUN-S-PROC_ID, identification of created process is 00000125 >>>> %DCL-I-SUPERSEDE, previous value of MOM$SYSTEM has been superseded >>>> %DCL-I-SUPERSEDE, previous value of MOM$SYSTEM_NOSOFTID has been >>>> superseded >>>> %DCL-I-SUPERSEDE, previous value of MOM$SYSTEM_SOFTID has been >>>> superseded >>>> %NCP-I-NOINFO, No information in database >>>> %RUN-S-PROC_ID, identification of created process is 00000127 >>>> $ >>>> %%%%%%%%%%%? OPCOM? 27-DEC-2022 16:41:36.76? %%%%%%%%%%% >>>> Message from user DECNET on HERMES >>>> DECnet event 4.10, circuit up >>>> From node 2.404 (HERMES), 31-JAN-1977 00:00:06.21 >>>> Circuit EWA-0 >>>> >>>> $ >>>> %%%%%%%%%%%? OPCOM? 27-DEC-2022 16:41:41.87? %%%%%%%%%%% >>>> Message from user DECNET on HERMES >>>> DECnet event 4.15, adjacency up >>>> From node 2.404 (HERMES), 31-JAN-1977 00:00:06.21 >>>> Circuit EWA-0, Adjacent node = 2.400 (APOLLO) >>>> >>>> And from APOLLO adjacent node (down/up when DECnet cycled): >>>> >>>> APOLLO-> >>>> %%%%%%%%%%%? OPCOM? 27-DEC-2020 16:31:27.60? %%%%%%%%%%% >>>> Message from user DECNET on APOLLO >>>> DECnet event 4.18, adjacency down >>>> From node 2.400 (APOLLO), 27-DEC-2020 16:31:27.59 >>>> Circuit EWA-0, Adjacent node listener receive timeout >>>> Adjacent node = 2.404 (HERMES) >>>> >>>> APOLLO-> >>>> %%%%%%%%%%%? OPCOM? 27-DEC-2020 16:42:33.54? %%%%%%%%%%% >>>> Message from user DECNET on APOLLO >>>> DECnet event 4.15, adjacency up >>>> From node 2.400 (APOLLO), 27-DEC-2020 16:42:33.54 >>>> Circuit EWA-0, Adjacent node = 2.404 (HERMES) >>>> >>>> >>>> On Sun, Dec 27, 2020, at 5:03 PM, Paul Koning wrote: >>>>> 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? >>>>> >>>>> paul >>>>> >>>>>> On Dec 27, 2020, at 7:42 PM, Jason Brady <jr_brady at fastmail.com >>>>>> <mailto:jr_brady at fastmail.com>> wrote: >>>>>> >>>>>> Booted test Alpha system running OpenVMS 8.4 and set the date to >>>>>> 27-DEC-2022. Started DECnet Phase IV. No errors. >>>>>> >>>>>> From node APOLLO, no problem transferring files from the test >>>>>> system and displaying network info (TELL ... SHOW EXEC, etc.). >>>>>> >>>>>> Snippet from test system NML$SERVER.LOG: >>>>>> >>>>>> -------------------------------------------------------- >>>>>> ??????? Connect request received at 27-DEC-2022 16:29:25.54 >>>>>> ??????????? from remote process APOLLO::"0=JASON" >>>>>> ??????????? for object "SYS$COMMON:[SYSEXE]NML.EXE" >>>>>> -------------------------------------------------------- >>>>>> >>>>>> Snippet from test system FAL$SERVER.LOG: >>>>>> >>>>>> -------------------------------------------------------- >>>>>> ??????? Connect request received at 27-DEC-2022 16:26:56.85 >>>>>> ??????????? from remote process APOLLO::"0=JASON" >>>>>> ??????????? for object "SYS$COMMON:[SYSEXE]FAL.EXE" >>>>>> -------------------------------------------------------- >>>>>> >>>>>> Is the above satisfactory, at least for OpenVMS Alpha? >>>>>> >>>>>> Regards, >>>>>> Jason >>>>>> >>>>>> On Sun, Dec 27, 2020, at 10:06 AM, Robert Armstrong wrote: >>>>>>> > John Forecast wrote: >>>>>>> >DECnet event logging for any system may fail after Nov 9th 2021. >>>>>>> >>>>>>> ? 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... >>>>>>> >>>>>>> Bob >>>> >