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

[Thomas DeBellis]

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/2cbf0f39/attachment-0001.htm>