27 Dec
2020
27 Dec
'20
5:46 p.m.
This topic came up on the alt.sys.pdp10 list
https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ
Apparently DECnet-10 won't work past November 9th 2021, which isn't that far
away. Personally I'd never heard this before and had no idea, and since I
know there are a few 36 bit emulations on HECnet that are obviously using
DECnet I thought I'd pass it along.
TOPS20 isn't explicitly mentioned, but I'm guessing that it has the exact
same issue. That'd mean no DECnet on 36 bit systems after next year!
Unless, of course, you want to start playing games with the date (which I
hate doing).
Bob
27 Dec
27 Dec
6:30 p.m.
On Dec 27, 2020, at 11:46 AM, Robert Armstrong <bob
at jfcl.com> wrote:
This topic came up on the alt.sys.pdp10 list
https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ
<https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ>
Apparently DECnet-10 won?t work past November 9th 2021, which isn?t that far away.
Personally I?d never heard this before and had no idea, and since I know there are a few
36 bit emulations on HECnet that are obviously using DECnet I thought I?d pass it along.
TOPS20 isn?t explicitly mentioned, but I?m guessing that it has the exact same issue.
That?d mean no DECnet on 36 bit systems after next year! Unless, of course, you want to
start playing games with the date (which I hate doing)?
Bob
It?s not just a DECnet-10/20 problem. DECnet event logging for any system may fail after
Nov 9th 2021. Events are time-stamped when they are generated with a 2-byte field holding
the number of half julian days since Jan-1 1977. The spec (Network Management 4.0.0, page
170/171) implies that these 2 bytes should be treated as a signed value (0 - 32767) which
will overflow on Nov 9th 2021. If the code treats it as unsigned, then we?re good for
another 44 years. I wrote most of the RSX and Ultrix event logging code but I don?t
remember if that field was treated as signed or unsigned. Phase V fixed the problem
allowing the time stamp to go well past the year 9999.
John.
6:52 p.m.
Making it unsigned on t10/t20 is simple, can the VMS/RSX/etc experts we
have here set their system date to 2022 and se what happens?
Thanks John for the clarification.
-P
From: "John Forecast" <john at
forecast.name>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Sunday, December 27, 2020 12:30:54 PM
Subject: Re: [HECnet] DECnet-10 doesn't work past Nov 9 2021?
> On Dec 27, 2020, at 11:46 AM, Robert Armstrong
< [ mailto:bob at jfcl.com |
> bob at jfcl.com ] > wrote:
> This topic came up on the alt.sys.pdp10 list
> [ https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ |
> https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ ]
> Apparently DECnet-10 won?t work past November 9 th 2021, which isn?t that far
> away. Personally I?d never heard this before and had no idea, and since I know
> there are a few 36 bit emulations on HECnet that are obviously using DECnet I
> thought I?d pass it along.
> TOPS20 isn?t explicitly mentioned, but I?m guessing that it has the exact same
> issue. That?d mean no DECnet on 36 bit systems after next year! Unless, of
> course, you want to start playing games with the date (which I hate doing)?
> Bob
It?s not just a DECnet-10/20 problem. DECnet event
logging for any system may
fail after Nov 9th 2021. Events are time-stamped when they are generated with a
2-byte field holding the number of half julian days since Jan-1 1977. The spec
(Network Management 4.0.0, page 170/171) implies that these 2 bytes should be
treated as a signed value (0 - 32767) which will overflow on Nov 9th 2021. If
the code treats it as unsigned, then we?re good for another 44 years. I wrote
most of the RSX and Ultrix event logging code but I don?t remember if that
field was treated as signed or unsigned. Phase V fixed the problem allowing the
time stamp to go well past the year 9999.
John.
7:01 p.m.
On 2020-12-27 18:30, John Forecast wrote:
This is explicitly mentioned in the RSX-11M-PLUS V4.6 release notes.
Section 8.8.
8.8.1 is about DAP, which specifies dates in ASCII, using DDMMMYY. RSX
will treat YY 70-99 as in the 20th century, and 00-69 as in the 21st
century.
8.8.2 is about Network Management Protocol V4.2.0, where it is
explicitly stated that RSX will treat that number as unsigned, and will
work until 2065. After that, it will roll around. Logging will still
work, but dates will be back to 1977 in the logs.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Dec 27, 2020, at 11:46 AM, Robert Armstrong
<bob at jfcl.com
<mailto:bob at jfcl.com>> wrote:
? This topic came up on the alt.sys.pdp10 list
https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ
<https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ>
Apparently DECnet-10 won?t work past November 9^th 2021, which isn?t
that far away.?? Personally I?d never heard this before and had no
idea, and since I know there are a few 36 bit emulations on HECnet
that are obviously using DECnet I thought I?d pass it along.
? TOPS20 isn?t explicitly mentioned, but I?m guessing that it has the
exact same issue.? That?d mean no DECnet on 36 bit systems after next
year!? Unless, of course, you want to start playing games with the
date (which I hate doing)?
Bob
It?s not just a DECnet-10/20 problem. DECnet event logging for any
system may fail after Nov 9th 2021. Events are time-stamped when they
are generated with a 2-byte field holding the number of half julian days
since Jan-1 1977. The spec (Network Management 4.0.0, page 170/171)
implies that these 2 bytes should be treated as a signed value (0 -
32767) which will overflow on Nov 9th 2021. If the code treats it as
unsigned, then we?re good for another 44 years. I wrote most of the RSX
and Ultrix event logging code but I don?t remember if that field was
treated as signed or unsigned. Phase V fixed the problem allowing the
time stamp to go well past the year 9999.
7:10 p.m.
On 2020-12-27 19:06, Robert Armstrong wrote:
As mentioned, RSX will handle it fine.
But anyway, I'm not sure this really is that much of a deal. Logging
will get the wrong dates, or may fail more fatally. But that's just
logging. It don't actually have much to do with the actual operations.
Of course, I have no idea what may fall out if logging throws a wrench
into the system, though.
For RSX, even after 2065, it won't really be a problem. Logs will just
have the wrong date, which have some implications if you are going to be
searching through logs for things on a specific date, or if you look at
printouts.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
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...
7:32 p.m.
On Dec 27, 2020, at 1:10 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2020-12-27 19:06, Robert Armstrong wrote:
As mentioned, RSX will handle it fine.
But anyway, I'm not sure this really is that much of a deal. Logging will get the
wrong dates, or may fail more fatally. But that's just logging. It don't actually
have much to do with the actual operations.
Of course, I have no idea what may fall out if logging throws a wrench into the system,
though.
For RSX, even after 2065, it won't really be a problem. Logs will just have the wrong
date, which have some implications if you are going to be searching through logs for
things on a specific date, or if you look at printouts.
Johnny
I agree. A significant number of events are generated in system or driver code. RSX (in
kernel mode) allocates a buffer, copies the event information into the buffer and queues
it for the event logger task (EVL?). Ultrix is similar although it uses a special socket
to get the data up into user mode. I don?t know what VMS does. Obviously, Tops-10/20 went
the extra step of checking for overflow - probably the best bet there is to follow the RSX
model and get rid of the BUGCHK.
John.
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... 
28 Dec
28 Dec
1:42 a.m.
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
2:03 a.m.
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> 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
2:17 a.m.
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> 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
29 Dec
29 Dec
4:08 a.m.
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
4:52 a.m.
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
>
5 a.m.
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
>>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5:06 a.m.
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
>>
5:15 a.m.
I think the best fix here is to change the base date to for
example 2020 on systems we knew how to do this on.
It will send a happy positive number to everyone and some will think
it's in the past and some will get it right.
(Johnny already said this..)
-P
----- Original Message -----
From: "tommytimesharing"
<tommytimesharing at gmail.com>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Monday, December 28, 2020 11:06:24 PM
Subject: Re: [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.
5:52 a.m.
Sure, you can always lie to Tops-10 about the date; but it seems to me
that it might be more friendly to not have it crash, say if some
neophyte is just poking around.
It might be difficult with the KLH micro-engine; as I recall, this gets
the date and time from the host, I forget what happens if you try to
override that.? You can't override it until you're booted, by which time
you've already crashed if somebody wants you to log a DECnet event.
Tops-10 can pull the date from elsewhere (like other processors), but I
don't think that's relevant anymore.
On 12/28/20 11:15 PM, Peter Lothberg wrote:
I think the best fix here is to change the base date
to for
example 2020 on systems we knew how to do this on.
It will send a happy positive number to everyone and some will think
it's in the past and some will get it right.
(Johnny already said this..)
-P
----- Original Message -----
> From: "tommytimesharing" <tommytimesharing at gmail.com>
> To: "hecnet" <hecnet at Update.UU.SE>
> Sent: Monday, December 28, 2020 11:06:24 PM
> Subject: Re: [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.
5:18 a.m.
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.
Johnny
On 2020-12-29 05:06, Thomas DeBellis wrote:
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
>>>>
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5:20 a.m.
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.
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.
Johnny
On 2020-12-29 05:18, Johnny Billquist wrote:
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.
? Johnny
On 2020-12-29 05:06, Thomas DeBellis wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
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
>>>>
>
30 Dec
30 Dec
11 p.m.
Ah, I got it; I was counting and thinking the wrong way.
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.
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.
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...
On 12/28/20 11:20 PM, Johnny Billquist wrote:
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.
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.
? Johnny
On 2020-12-29 05:18, Johnny Billquist wrote:
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.
?? Johnny
On 2020-12-29 05:06, Thomas DeBellis wrote:
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
>>>>
>
11:11 p.m.
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.
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...
RSX should continue to show correct dates on events up until 2065,
treating the value as an unsigned 16 bit value.
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.
If I got things right, VMS might show and/or report dates back in 1977
again. Annoying, but nothing worse than that.
Tops-10 seems to currently do a BUGHLT, so that really needs fixing.
TOPS-20 is a bit unknown, but it might just report wrong dates.
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.
I have no idea about Ultrix or any other implementation. Anyone else who
can complement this information with more details?
We could perhaps create a page with a summary of what we know.
Johnny
On 2020-12-30 23:00, Thomas DeBellis wrote:
Ah, I got it; I was counting and thinking the wrong
way.
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.
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.
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...
On 12/28/20 11:20 PM, Johnny Billquist wrote:
> 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.
>
> 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.
>
> ? Johnny
>
> On 2020-12-29 05:18, Johnny Billquist wrote:
>> 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.
>>
>> ?? Johnny
>>
>> On 2020-12-29 05:06, Thomas DeBellis wrote:
>>> 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
>>>>>>>
>>>>
>>
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
31 Dec
31 Dec
1:17 a.m.
On Dec 30, 2020, at 5:11 PM, Johnny Billquist <bqt
at softjar.se> wrote:
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.
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...
RSX should continue to show correct dates on events up until 2065, treating the value as
an unsigned 16 bit value.
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.
If I got things right, VMS might show and/or report dates back in 1977 again. Annoying,
but nothing worse than that.
Tops-10 seems to currently do a BUGHLT, so that really needs fixing.
TOPS-20 is a bit unknown, but it might just report wrong dates.
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.
I have no idea about Ultrix or any other implementation. Anyone else who can complement
this information with more details?
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:
Event type 4.15, Adjacency up
Occurred 18-Sep-212 12:00:13.0 on node 63.223
Circuit QNA-0
Adjacent node = 63.2
date
Sun Jan 1 00:00:35 EST 2023
John.
We could perhaps create a page with a summary of what we know.
Johnny
On 2020-12-30 23:00, Thomas DeBellis wrote:
Ah, I got it; I was counting and thinking the
wrong way.
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.
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.
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...
On 12/28/20 11:20 PM, Johnny Billquist wrote:
> 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.
>
> 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.
>
> Johnny
>
> On 2020-12-29 05:18, Johnny Billquist wrote:
>> 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.
>>
>> Johnny
>>
>> On 2020-12-29 05:06, Thomas DeBellis wrote:
>>> 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
>>>>>>>
>>>>
>>
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
3:21 a.m.
T10 and T20 we can fix/updated to whatever we chose as the "long term solution",
and if we are "useful to the society" we document how the "next
generation" should
solve the problem. I suggest a 100-Year vision here, and with the current format of 16
bits
SOMEONE has to make another fix within the 100 years, most likely after I'm gone.....
Or can we document "today's fix" and the "next fix"?
--P
From: "John Forecast" <john at
forecast.name>
To: "hecnet" <hecnet at Update.UU.SE>
Sent: Wednesday, December 30, 2020 7:17:59 PM
Subject: Re: [HECnet] DECnet-10 doesn't work past Nov 9 2021?
> On Dec 30, 2020, at 5:11 PM, Johnny Billquist <
[ mailto:bqt at softjar.se |
> bqt at softjar.se ] > wrote:
> 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.
> 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...
> RSX should continue to show correct dates on
events up until 2065, treating the
> value as an unsigned 16 bit value.
> 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.
> If I got things right, VMS might show and/or
report dates back in 1977 again.
> Annoying, but nothing worse than that.
> Tops-10 seems to currently do a BUGHLT, so that
really needs fixing.
> TOPS-20 is a bit unknown, but it might just report
wrong dates.
> 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.
> I have no idea about Ultrix or any other
implementation. Anyone else who can
> complement this information with more details?
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:
Event type 4.15, Adjacency up
Occurred 18-Sep-212 12:00:13.0 on node 63.223
Circuit QNA-0
Adjacent node = 63.2
date
Sun Jan 1 00:00:35 EST 2023
John.
> We could perhaps create a page with a summary of
what we know.
> Johnny
> On 2020-12-30 23:00, Thomas DeBellis wrote:
>> Ah, I got it; I was counting and thinking the
wrong way.
>> 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.
>> 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.
>> 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...
>> On 12/28/20 11:20 PM, Johnny Billquist wrote:
>>> 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.
>>> 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.
>> > Johnny
>>> On 2020-12-29 05:18, Johnny Billquist
wrote:
>>>> 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.
>>> > Johnny
>>>> On 2020-12-29 05:06, Thomas DeBellis
wrote:
>>>>> 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 < [ mailto:jr_brady at fastmail.com |
>>>>>>>>>>> jr_brady at fastmail.com ] < [
mailto: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
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> [ mailto:bqt at softjar.se | email: bqt at softjar.se ] || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
1 Jan
1 Jan
7:08 p.m.
On Dec 30, 2020, at 5:11 PM, Johnny Billquist <bqt
at softjar.se> wrote:
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.
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...
RSX should continue to show correct dates on events up until 2065, treating the value as
an unsigned 16 bit value.
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.
If I got things right, VMS might show and/or report dates back in 1977 again. Annoying,
but nothing worse than that.
Tops-10 seems to currently do a BUGHLT, so that really needs fixing.
TOPS-20 is a bit unknown, but it might just report wrong dates.
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.
As shipped by DEC, it wasn't even Y2K compliant. At least not the version for which I
have sources; perhaps it was fixed in a patch I have not seen.
Recently I repaired the event logging code to fix this, and since I knew of the Nov
'21 problem I changed it to use unsigned 16 bit values. So it should be like RSX,
good until 2065. You can find the fixed version in https://github.com/pkoning2/decstuff
in the "decnete" subdirecty.
paul
7:40 p.m.
On 2021-01-01 19:08, Paul Koning wrote:
Hmm. 10.1A, which was done by Mentec somewhere close to the end of the
90s should probably have some fixes/improvements. Unfortunately, I do
not have the sources, and I cannot even find any release notes for it...
On Dec 30, 2020, at 5:11 PM, Johnny Billquist
<bqt at softjar.se> wrote:
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.
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...
RSX should continue to show correct dates on events up until 2065, treating the value as
an unsigned 16 bit value.
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.
If I got things right, VMS might show and/or report dates back in 1977 again. Annoying,
but nothing worse than that.
Tops-10 seems to currently do a BUGHLT, so that really needs fixing.
TOPS-20 is a bit unknown, but it might just report wrong dates.
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.
As shipped by DEC, it wasn't even Y2K compliant. At least not the version for which
I have sources; perhaps it was fixed in a patch I have not seen. Recently I repaired the event logging code to fix
this, and since I knew of the Nov '21 problem I changed it to use unsigned 16 bit
values. So it should be like RSX, good until 2065. You can find the fixed version in
https://github.com/pkoning2/decstuff in the "decnete" subdirecty.
Excellent!
And we really should try and put a comprehensive page together with
RSTS/E patches and fixes...
(And I really should do that for RSX as well...)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
8:56 p.m.
On Jan 1, 2021, at 1:40 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2021-01-01 19:08, Paul Koning wrote:
Hmm. 10.1A, which was done by Mentec somewhere close to the end of the 90s should
probably have some fixes/improvements. Unfortunately, I do not have the sources, and I
cannot even find any release notes for it...
RSTS itself was made Y2K compliant. The issue is code in the DECnet kit, that's
separate and I don't know that it was fixed. The same goes for other random bits; for
example the RT-11 based assembler shows wrong dates in the listing page header.
On Dec
30, 2020, at 5:11 PM, Johnny Billquist <bqt at softjar.se> wrote:
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.
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...
RSX should continue to show correct dates on events up until 2065, treating the value as
an unsigned 16 bit value.
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.
If I got things right, VMS might show and/or report dates back in 1977 again. Annoying,
but nothing worse than that.
Tops-10 seems to currently do a BUGHLT, so that really needs fixing.
TOPS-20 is a bit unknown, but it might just report wrong dates.
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.
As shipped by DEC, it wasn't even Y2K
compliant. At least not the version for which I have sources; perhaps it was fixed in a
patch I have not seen. Recently I
repaired the event logging code to fix this, and since I knew of the Nov '21 problem I
changed it to use unsigned 16 bit values. So it should be like RSX, good until 2065. You
can find the fixed version in https://github.com/pkoning2/decstuff in the
"decnete" subdirecty.
Excellent!
And we really should try and put a comprehensive page together with RSTS/E patches and
fixes...
(And I really should do that for RSX as well...) 
10:01 p.m.
I know about the macro-11/RT-11 date. V5.x fixed it by adding an ?EPOC? bit. I have not
looked at those sources in years but it shouldn?t be that hard to replicate. I ?may? have
the DECnet sources as well. I will have to look...
-Steve Davidson
SF:iP1
On Jan 1, 2021, at 14:58, Paul Koning <paulkoning
at comcast.net> wrote:
?
paul
On Jan 1, 2021, at 1:40 PM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2021-01-01 19:08, Paul Koning wrote:
Hmm. 10.1A, which was done by Mentec somewhere close to the end of the 90s should
probably have some fixes/improvements. Unfortunately, I do not have the sources, and I
cannot even find any release notes for it...
RSTS itself was made Y2K compliant. The issue is code in the DECnet kit, that's
separate and I don't know that it was fixed. The same goes for other random bits; for
example the RT-11 based assembler shows wrong dates in the listing page header.
> On
Dec 30, 2020, at 5:11 PM, Johnny Billquist <bqt at softjar.se> wrote:
>
> 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.
> 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...
>
> RSX should continue to show correct dates on events up until 2065, treating the value
as an unsigned 16 bit value.
>
> 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.
>
> If I got things right, VMS might show and/or report dates back in 1977 again.
Annoying, but nothing worse than that.
>
> Tops-10 seems to currently do a BUGHLT, so that really needs fixing.
>
> TOPS-20 is a bit unknown, but it might just report wrong dates.
>
> 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.
As shipped by DEC, it wasn't even Y2K
compliant. At least not the version for which I have sources; perhaps it was fixed in a
patch I have not seen. Recently
I repaired the event logging code to fix this, and since I knew of the Nov '21 problem
I changed it to use unsigned 16 bit values. So it should be like RSX, good until 2065.
You can find the fixed version in https://github.com/pkoning2/decstuff in the
"decnete" subdirecty.
Excellent!
And we really should try and put a comprehensive page together with RSTS/E patches and
fixes...
(And I really should do that for RSX as well...) 
10:50 p.m.
On Sat, Jan 2, 2021 at 6:58 AM Paul Koning <paulkoning at comcast.net> wrote:
I've put up a scanned copy of the RSTS/E Cover Letter for V10.1A on GitHub
at
https://github.com/agn453/RSTS-E/blob/master/docs/AV-RK36A-TE-RSTS_E-V10.1A…
It details changes to the RT11 run-time system (including the support of
the .DATE4
system call) and updates to the RT-11 MACRO, CREF, LIBR and LINK utilities;
as
well as updates to EDT, error display and ANSI tape handling.
Unfortunately I don't have a copy of the update tape - but you'll also find
my fixes to
the RT-11 file interchange program (FIT) for the updated RT-11 date format
and other
references to updates (including pointing to Paul's GitHub site) at
https://github.com/agn453/RSTS-E
Some of the updates can be grabbed from my RSTS/E V10.1 HECnet node
from the default DECnet account on DINGO:: and other places referenced by
the
FILES.TXT description file.
Since the RSTS/E V10.1 source kits are on Bitsavers - maybe it's time we
looked at
re-implementing the Mentac updates (unless one of us has a copy of the
update tape).
Tony
--
Tony Nicholson <tony.nicholson at computer.org>
[snip]
Hmm. 10.1A,
which was done by Mentec somewhere close to the end of the
90s should probably have
some fixes/improvements. Unfortunately, I do not
have the sources, and I cannot even find any release notes for it...
RSTS itself was made Y2K compliant. The issue is code in the DECnet kit,
that's separate and I don't know that it was fixed. The same goes for
other random bits; for example the RT-11 based assembler shows wrong dates
in the listing page header.
> Recently I repaired the event logging code to
fix this, and since I
knew of the Nov '21 problem I changed it to use unsigned
16 bit values. So
it should be like RSX, good until 2065. You can find the fixed version in
https://github.com/pkoning2/decstuff in the "decnete" subdirecty.
Excellent!
And we really should try and put a comprehensive page together with
RSTS/E patches
and fixes...
(And I really should do that for RSX as well...)
paul
27 Dec
27 Dec
8:56 p.m.
On Dec 27, 2020, at 12:30 PM, John Forecast <john
at forecast.name> wrote:
Ignoring the spec and treating that field as unsigned is certainly a reasonable thing to
do.
That said, I don't see any reason why "timestamps will be wrong" translates
to "DECnet won't work".
paul
On Dec 27, 2020, at 11:46 AM, Robert Armstrong
<bob at jfcl.com> wrote:
This topic came up on the alt.sys.pdp10 list
https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ
Apparently DECnet-10 won?t work past November 9th 2021, which isn?t that far away.
Personally I?d never heard this before and had no idea, and since I know there are a few
36 bit emulations on HECnet that are obviously using DECnet I thought I?d pass it along.
TOPS20 isn?t explicitly mentioned, but I?m guessing that it has the exact same issue.
That?d mean no DECnet on 36 bit systems after next year! Unless, of course, you want to
start playing games with the date (which I hate doing)?
Bob
It?s not just a DECnet-10/20 problem. DECnet event logging for any system may fail after
Nov 9th 2021. Events are time-stamped when they are generated with a 2-byte field holding
the number of half julian days since Jan-1 1977. The spec (Network Management 4.0.0, page
170/171) implies that these 2 bytes should be treated as a signed value (0 - 32767) which
will overflow on Nov 9th 2021. If the code treats it as unsigned, then we?re good for
another 44 years. I wrote most of the RSX and Ultrix event logging code but I don?t
remember if that field was treated as signed or unsigned. Phase V fixed the problem
allowing the time stamp to go well past the year 9999.
John.
10:26 p.m.
I had a look at this a few years ago; here is what I remember:
Tops-10 and Tops-20 clearly share a certain amount of common code.? In
the monitor, a number of comments show that the DECnet-36 transport was
developed in user mode under Tops-10 and, once stable, ported to monitor
mode and thence to Tops-20.? From there, you have a certain amount of
divergence in the form of conditional assembly.
The BUGHLT in question (COM911) still appears under a Tops-10
conditional.? The routine, NXM, is used to compute a time stamp for an
event block.? Internally, Tops-20 has a maximum possible date of
September 27th, 2217; it looks like Tops-10 may have the same limit.
The routine takes this internal date and converts it into the number
Julian half days, the number of seconds into the current half day and
the number of milliseconds into the current second. Tops-10 will not
allow the overflow.? The Tops-20 conditional uses internal monitor
routines (which are '2217 clean') to do the calculation and will not crash.
The error logging in Tops-20 uses the internal format and, as far as I
am aware, couldn't care less about any of the above.? I would assume
that the stamping is used to package an error for consumption by other
non-Tops-20 components, but I haven't chased any further on that.
Additional work was done on the timestamp code in the PANDA monitor,
apparently by Ralph Gorin.? It handles the time of day as a proper fixed
point binary fraction and appears correct.? I don't know how many times
I have seen this done wrong (QSRADM comes to mind).
In other areas, Tops-10 and Tops-20 share no common code for DECnet.?
The DAP library is completely Tops-20 specific.? This had a date problem
that I fixed with some help from Johnny.? It still has a bug that will
cause it to crash when handling certain files from Tops-10 (of all
places).? FAL is also completely different; far more integrated into
Galaxy.? After I put the ANONYMOUS transfer support into FAL, I put all
of it aside to turn to something else.? I'll look at it again when I get
back to it.
I think Paul has made a reasonable observation that timestamps being
wrong shouldn't make DECnet gronk.?? Yet this is precisely what Tops-10
is going to do with itself.? The code appears to date from 1983, so
maybe that was a reasonable assumption.? Many utilities from Tops-10
aren't even Y2K compliant, including login.
------------------------------------------------------------------------
On 12/27/20 2:56 PM, Paul Koning wrote:
Ignoring the spec and treating that field as unsigned is certainly a reasonable thing to
do.
That said, I don't see any reason why "timestamps will be wrong" translates
to "DECnet won't work".
paul
> ------------------------------------------------------------------------
> On Dec 27, 2020, at 12:30 PM, John Forecast <john at forecast.name> wrote:
> It?s not just a DECnet-10/20 problem. DECnet event logging for any system may fail
after Nov 9th 2021. Events are time-stamped when they are generated with a 2-byte field
holding the number of half julian days since Jan-1 1977. The spec (Network Management
4.0.0, page 170/171) implies that these 2 bytes should be treated as a signed value (0 -
32767) which will overflow on Nov 9th 2021. If the code treats it as unsigned, then we?re
good for another 44 years. I wrote most of the RSX and Ultrix event logging code but I
don?t remember if that field was treated as signed or unsigned. Phase V fixed the problem
allowing the time stamp to go well past the year 9999.
>
> John.
>> ------------------------------------------------------------------------
>> On Dec 27, 2020, at 11:46 AM, Robert Armstrong <bob at jfcl.com> wrote:
>>
>> This topic came up on the alt.sys.pdp10 list
>>
>> https://groups.google.com/g/alt.sys.pdp10/c/ZttQxHZGEJQ
>>
>> Apparently DECnet-10 won?t work past November 9th 2021, which isn?t that far
away. Personally I?d never heard this before and had no idea, and since I know there are
a few 36 bit emulations on HECnet that are obviously using DECnet I thought I?d pass it
along.
>>
>> TOPS20 isn?t explicitly mentioned, but I?m guessing that it has the exact same
issue. That?d mean no DECnet on 36 bit systems after next year! Unless, of course, you
want to start playing games with the date (which I hate doing)?
>>
>> Bob
1217
days inactive
1222
days old
28 comments
9 participants
participants (9)
-
bob＠jfcl.com -
bqt＠softjar.se -
john＠forecast.name -
jr_brady＠fastmail.com -
paulkoning＠comcast.net -
roll＠stupi.com -
steve＠davidson.net -
tommytimesharing＠gmail.com -
tony.nicholson＠computer.org