[HECnet] DECnet-10 doesn't work past Nov 9 2021?
Thomas DeBellis
tommytimesharing at gmail.com
Mon Dec 28 20:06:24 PST 2020
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
>>>>
>
More information about the Hecnet-list
mailing list