27 Dec
2020
27 Dec
'20
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.