15 Jul
2016
15 Jul
'16
12:49 p.m.
Isn't the documentation wrong, since it says 2621?
... copy/paste/transcription error on my part. The file clearly
says 2021. Copied sort of by hand from a .pdf file...
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)
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.
Time for some experimentation.
Johnny
--Johnny
15 Jul
15 Jul
3:57 p.m.
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?
There always is. Let me know if you want some assistance.
By the way, I'm going up to Stockholm next week. Vacation time, so I'll
be there a few weeks. We should sync up...
Johnny
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.
Time for some experimentation. 
4:53 p.m.
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.
paul
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.
7:10 p.m.
On Jul 15, 2016, at 12:59 PM, Johnny Billquist <bqt
at softjar.se> wrote:
...
FLX accessing DOS tapes will "fail" at 2035.
That figures, because the RSTS date format was taken from DOS-11. I assume you meant
magtape; DECtape runs into trouble in 2002 because there the date is only 15 bits (the
sign bit is used to mark a contiguous file).
paul
8:13 p.m.
On 2016-07-15 19:10, Paul_Koning at Dell.com wrote:
I'm not even sure if FLX under RSX can access DOS DECtapes... I think
FLX only supports DOS magtape format. For disks, it only deals with
RT-11 format, I think. I didn't even know that there was a DOS-11 disk
format, but thinking about it, it would seem obvious there should be one.
Johnny
On Jul 15, 2016, at 12:59 PM, Johnny Billquist
<bqt at softjar.se> wrote:
...
FLX accessing DOS tapes will "fail" at 2035.
That figures, because the RSTS date format was taken from DOS-11. I assume you meant
magtape; DECtape runs into trouble in 2002 because there the date is only 15 bits (the
sign bit is used to mark a contiguous file).
8:17 p.m.
On Jul 15, 2016, at 2:13 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2016-07-15 19:10, Paul_Koning at Dell.com wrote:
I'm not even sure if FLX under RSX can access DOS DECtapes... I think FLX only
supports DOS magtape format. For disks, it only deals with RT-11 format, I think. I
didn't even know that there was a DOS-11 disk format, but thinking about it, it would
seem obvious there should be one.
Yes, there is, different from everything else as far as I know. I think the DECtape
format is faintly related. Some DOS manuals may give some clues, but I've never
looked into it or had any exposure to DOS disk file system internals.
paul
On Jul 15, 2016, at 12:59 PM, Johnny Billquist
<bqt at softjar.se> wrote:
...
FLX accessing DOS tapes will "fail" at 2035.
That figures, because the RSTS date format was taken from DOS-11. I assume you meant
magtape; DECtape runs into trouble in 2002 because there the date is only 15 bits (the
sign bit is used to mark a contiguous file).
3083
days inactive
3083
days old
6 comments
3 participants
participants (3)
-
bqt＠softjar.se -
bygg＠cafax.se -
Paul_Koning＠Dell.com