[HECnet] Future problems?

[Johnny Billquist]

On 2016-07-15 16:53, Paul_Koning at Dell.com wrote:
>
>> 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.

Right. As I thought then.  And I've only found timestamps in the event 
logging.

>>> 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.

I was responding to the "(sarcasm)" comment.
This in itself obviously have nothing to do with the time stamp issue as 
such.

>>>> 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.

RSX itself will probably break down in the year 34668.
But various libraries and other stuff will break down long before then. 
At V4.6, I think most things were checked for clearance until 2155. A 
few things (I believe mostly DECnet related) will hit some problems 
before then.

DAP will hit problems in 2070. (Depending on OS, you might have problems 
already today)
The Network Management Protocol in RSX will fail in th year 2066, as 
noted in this thread (yes, RSX treats the values as a 16-bit unsigned 
value).

FLX accessing DOS tapes will "fail" at 2035.
FLX accessing RT-11 disks will "fail" at 2099.

All else in RSX is currently guaranteed to work until at least 2099, and 
most things to 2155. But in reality most of them will work beyond that too.

	Johnny