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

[Thomas DeBellis]

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