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

[Thomas DeBellis]

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
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20201228/6fbc1f8c/attachment-0001.htm>