[HECnet] Future problems?

[Paul_Koning at Dell.com]

> On Jul 15, 2016, at 9:57 AM, Johnny Billquist <bqt at softjar.se> wrote:
> 
> On 2016-07-15 10:49, Johnny Eriksson wrote:
>>> Either way, I believe this field was expanded to be interpreted as
>>> unsigned later than your code and documentation, meaning it will work a
>>> while longer. However, I doubt that the TOPS-10 code have been updated
>>> for that. Something for you to do?
>> 
>> As I said, the text indicates that the (monitor) code stops working in
>> 2021, but the code does in fact allow one more bit, no change needed here.
>> 
>> The thing to wonder about is a piece of (ehum) software called NML.
> 
> Trying to figure out if there are any time information in NML. Maybe I'm missing what you mean by NML here. Network Management? For which the protocol is called NICE?

NML is "network management listener", the daemon (to use the Unix term) for the NICE protocol.  NCP (network control program) is the client.

The issue you're talking about here is actually a design issue in DECnet, specifically the time stamp field of a network event in the event protocol.  It clearly says that the half-day field is a 15-bit integer, and yes, that stops in October 2021.  Not 2621, of course; that's a typo in the Phase III spec, the one you quoted, but it's fixed in the Phase IV spec.
> 
>> Written in the wonderful language BLISS.  (sarcasm)
> 
> I'm not sure I think it's all that bad... But Ive not done extensive work in it. But reading through it, after a while you adjust, and then it works for me.

The language isn't the issue here, though.  It's the DECnet protocol spec (not the implementations) that has the problem.  A simple fix would be to extend the existing 2 byte field to be 16 bits unsigned, not 15.  That would carry us to 2066.

>>> There is a similar issue with FAL, where the date field was also
>>> extended to be unsigned. RSX only got these updated in 1999 in the code.
>>> I'm sure VMS also have this. But for other OSes, I have no idea.

I don't see that in the spec.  The spec has a "date and time extended attributes" field, which contains the date/time as an ASCII string with a 2 digit year field.  That would go to 2069 or so without problem, assuming the OS handles such dates.  VMS can, I believe; PDP-11 operating systems vary depending on how they encode dates.  RSTS goes up to 2035, for example, but RSX and RT are different.

	paul