15 Jul
2016
15 Jul
'16
6:59 p.m.
On 2016-07-15 16:53, Paul_Koning at Dell.com wrote:
Right. As I thought then. And I've only found timestamps in the event
logging.
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.
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
On Jul 15, 2016, at 9:57 AM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2016-07-15 10:49, Johnny Eriksson wrote:
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. 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. 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. >> 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.