13 Nov
2024
13 Nov
'24
4:24 p.m.
Hi,
It has been mentioned elsewhere and maybe a while back too but I'm not quite sure when
DECnet (VAX/VMS 7.3) started serving up jewels like:
%%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%%
Message from user DECNET on TUPILE
DECnet event 4.10, circuit up
From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64
Circuit UNA-0
Regards
Keith
13 Nov
13 Nov
6:31 p.m.
The problem is in the network management spec. From the Phase IV spec, an event message
contains an "event time" encoded as follows:
EVENT TIME Is the source node date and time of event
processing. Consists of:
JULIAN SECOND MILLISECOND
HALF DAY
where:
JULIAN HALF DAY (2) : B Number of half days
since 1 Jan 1977 and
before 9 Nov 2021
(0-32767). For
example, the morning
of Jan 1, 1977 is 0.
SECOND (2) : B Second within current
half day (0-43199).
MILLISECOND (2) : B Millisecond within
current second
(0-999). If not
supported, high order
bit is set, remainder
are clear, and field
is not printed when
formatted for output.
Note "before 9 Nov 2021". The obvious fix is to disregard the
"0-32767" comment, which tells us to treat it as a 15-bit value, and make it 16
bits instead. I did that in DECnet/E, and in PyDECnet. I suspect VMS could be patched to
do the analogous fix, but I have no idea how to do that.
paul
On Nov 13, 2024, at 10:24 AM, Keith Halewood
<Keith.Halewood(a)pitbulluk.org> wrote:
Hi,
It has been mentioned elsewhere and maybe a while back too but I’m not quite sure when
DECnet (VAX/VMS 7.3) started serving up jewels like:
%%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%%
Message from user DECNET on TUPILE
DECnet event 4.10, circuit up
From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64
Circuit UNA-0
Regards
Keith
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
7:50 p.m.
This was "fixed" in RSX as well with the 4.8 release of DECnet-11M and
4.6 of DECnet-11M-PLUS. Done in the same way, which will allow it to
work correctly until 2065.
It is documented in the release notes for RSX.
I would hope a similar fix has been done for VMS, but I don't know if
that happened, and if that was also made available for the VAX version.
Johnny
On 2024-11-13 18:31, Paul Koning wrote:
The problem is in the network management spec. From
the Phase IV spec,an event message contains an "event time" encoded as follows:
EVENT TIME Is the source node date and time of event
processing. Consists of:
JULIAN SECOND MILLISECOND
HALF DAY
where:
JULIAN HALF DAY (2) : B Number of half days
since 1 Jan 1977 and
before 9 Nov 2021
(0-32767). For
example, the morning
of Jan 1, 1977 is0.
SECOND (2) : B Second within current
half day (0-43199).
MILLISECOND (2) : B Millisecond within
current second
(0-999). If not
supported, high order
bit is set, remainder
are clear, and field
is not printed when
formatted for output.
Note "before 9 Nov 2021". The obvious fix is to disregard the
"0-32767" comment, which tells us to treat it as a 15-bit value, and make it 16
bits instead. I did that in DECnet/E, and in PyDECnet. I suspect VMS could be patched to
do the analogous fix, but I have no idea how to do that.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 13, 2024, at 10:24 AM, Keith Halewood
<Keith.Halewood(a)pitbulluk.org> wrote:
Hi,
It has been mentioned elsewhere and maybe a while back too but I’m not quite sure when
DECnet (VAX/VMS 7.3) started serving up jewels like:
%%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%%
Message from user DECNET on TUPILE
DECnet event 4.10, circuit up
From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64
Circuit UNA-0
Regards
Keith
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se 
6:50 p.m.
Depends on the implementation. Nov 9, 2021 on VMS, Ultrix and probably some others. RSX
is good until 2065.
John.
On Nov 13, 2024, at 10:24 AM, Keith Halewood
<Keith.Halewood(a)pitbulluk.org> wrote:
Hi,
It has been mentioned elsewhere and maybe a while back too but I’m not quite sure when
DECnet (VAX/VMS 7.3) started serving up jewels like:
%%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%%
Message from user DECNET on TUPILE
DECnet event 4.10, circuit up
From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64
Circuit UNA-0
Regards
Keith
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se <mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
7:26 p.m.
The statement in the DECnet spec that julian half-day is 15 bits is an obvious bug with an
obvious fix; clearly RSX and others have made that fix. VMS needs to do likewise.
paul
On Nov 13, 2024, at 12:50 PM, John Forecast
<john(a)forecast.name> wrote:
Depends on the implementation. Nov 9, 2021 on VMS, Ultrix and probably some others. RSX
is good until 2065.
John.
On Nov 13, 2024, at 10:24 AM, Keith Halewood
<Keith.Halewood(a)pitbulluk.org> wrote:
Hi,
It has been mentioned elsewhere and maybe a while back too but I’m not quite sure when
DECnet (VAX/VMS 7.3) started serving up jewels like:
%%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%%
Message from user DECNET on TUPILE
DECnet event 4.10, circuit up
From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64
Circuit UNA-0
Regards
Keith
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se <mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
7:53 p.m.
I would not call it a bug. It was initially defined that way. However,
RSX officially decided to start treating it as an unsigned 16-bit value
with the last releases, and documented this.
And it's a change that do make sense.
But if others have not applied the same update, then it makes sense that
they would zero the value if it have the high bit set.
Johnny
On 2024-11-13 19:26, Paul Koning wrote:
The statement in the DECnet spec that julian half-day
is 15 bits is an
obvious bug with an obvious fix; clearly RSX and others have made that
fix. VMS needs to do likewise.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 13, 2024, at 12:50 PM, John Forecast
<john(a)forecast.name
<mailto:john@forecast.name>> wrote:
Depends on the implementation. Nov 9, 2021 on VMS, Ultrix and
probably some others. RSX is good until 2065.
John.
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se On Nov 13, 2024, at 10:24 AM, Keith Halewood
<Keith.Halewood(a)pitbulluk.org <mailto:Keith.Halewood@pitbulluk.org>>
wrote:
Hi,
It has been mentioned elsewhere and maybe a while back too but I’m
not quite sure when DECnet (VAX/VMS 7.3) started serving up jewels like:
%%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%%
Message from user DECNET on TUPILE
DECnet event 4.10, circuit up
From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64
Circuit UNA-0
Regards
Keith
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
8 p.m.
I believe I now have a reasonable set of VMS 7.3 patches to look through. Nothing sticks
out on a cursory scan suggesting a DECnet patch but we live in hope.
Failing that....
Is all of this likely to be in EVL, presumably it's the process propagating the
events?
One would hope that the problem is in the creation of the 16 bit value masked to 15 bits
and that its interpretation downstream will be the full 16 bit value.
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 13 November 2024 18:53
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet event date/time on VAX/VMS
I would not call it a bug. It was initially defined that way. However, RSX officially
decided to start treating it as an unsigned 16-bit value with the last releases, and
documented this.
And it's a change that do make sense.
But if others have not applied the same update, then it makes sense that they would zero
the value if it have the high bit set.
Johnny
On 2024-11-13 19:26, Paul Koning wrote:
The statement in the DECnet spec that julian half-day
is 15 bits is an
obvious bug with an obvious fix; clearly RSX and others have made that
fix. VMS needs to do likewise.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
On Nov 13, 2024, at 12:50 PM, John Forecast
<john(a)forecast.name
<mailto:john@forecast.name>> wrote:
Depends on the implementation. Nov 9, 2021 on VMS, Ultrix and
probably some others. RSX is good until 2065.
John.
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se
On Nov 13, 2024, at 10:24 AM, Keith Halewood
<Keith.Halewood(a)pitbulluk.org <mailto:Keith.Halewood@pitbulluk.org>>
wrote:
Hi,
It has been mentioned elsewhere and maybe a while back too but I’m
not quite sure when DECnet (VAX/VMS 7.3) started serving up jewels like:
%%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%% Message
from user DECNET on TUPILE DECnet event 4.10, circuit up From node
29.109 (TUPILE), 1-JAN-1977 00:00:53.64 Circuit UNA-0 Regards Keith
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se> To unsubscribe send an email
tohecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se> To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
8:09 p.m.
On 2024-11-13 20:00, Keith Halewood wrote:
I believe I now have a reasonable set of VMS 7.3
patches to look through. Nothing sticks out on a cursory scan suggesting a DECnet patch
but we live in hope.
Good luck...
Failing that....
Is all of this likely to be in EVL, presumably it's the process propagating the
events?
I would basically assume that this is at least a problem on the
receiving end. When receiving the event, it will check for reasonable
values, and if it's not, it just zeroes it.
The generating side might also have checks, but we can't say for sure in
this scenario.
Any intermediate propagation would probably not do anything with the data.
One would hope that the problem is in the creation of
the 16 bit value masked to 15 bits and that its interpretation downstream will be the
full16 bit value.
I think the receiving side is definitely catching it here. But there is
a somewhat simple way to check/test.
Have an up to date RSX machine for testing. We know that this system
will do 16 bit unsigned processing. Set a sink from RSX to VMS, and see
what dates you get from that. This will tell if you VMS receiving side
is catching values and clearing the date when it's out the expected range.
Then on the VMS side, set a sink towards RSX, and see if dates come
across correctly or not in that direction. That will tell you if the
generation of events are catching values with the high bit set or not.
Johnny
K
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: 13 November 2024 18:53
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: DECnet event date/time on VAX/VMS
I would not call it a bug. It was initially defined that way. However, RSX officially
decided to start treating it as an unsigned 16-bit value with the last releases, and
documented this.
And it's a change that do make sense.
But if others have not applied the same update, then it makes sense that they would zero
the value if it have the high bit set.
Johnny
On 2024-11-13 19:26, Paul Koning wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
The statement in the DECnet spec that julian
half-day is 15 bits is an
obvious bug with an obvious fix; clearly RSX and others have made that
fix. VMS needs to do likewise.
paul
On Nov 13, 2024, at 12:50 PM, John Forecast
<john(a)forecast.name
<mailto:john@forecast.name>> wrote:
Depends on the implementation. Nov 9, 2021 on VMS, Ultrix and
probably some others. RSX is good until 2065.
John.
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se On Nov 13, 2024, at 10:24 AM, Keith Halewood
<Keith.Halewood(a)pitbulluk.org <mailto:Keith.Halewood@pitbulluk.org>>
wrote:
Hi,
It has been mentioned elsewhere and maybe a while back too but I’m
not quite sure when DECnet (VAX/VMS 7.3) started serving up jewels like:
%%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%% Message
from user DECNET on TUPILE DECnet event 4.10, circuit up From node
29.109 (TUPILE), 1-JAN-1977 00:00:53.64 Circuit UNA-0 Regards Keith
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se> To unsubscribe send an email
tohecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se> To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
8:20 p.m.
By "bug" I meant "specification bug". The author of the DNA NetMan
spec messed up here. Yes, VMS faithfully follows that bad design.
The bugfix amounts to fixing the text of the spec, then changing the implementations to
match the corrected text. I don't know if the former has ever been done but obviously
a number of DECnet implementations acted as if had been. :-)
paul
On Nov 13, 2024, at 1:53 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
I would not call it a bug. It was initially defined that way. However, RSX officially
decided to start treating it as an unsigned 16-bit value with the last releases, and
documented this.
And it's a change that do make sense.
But if others have not applied the same update, then it makes sense that they would zero
the value if it have the high bit set.
Johnny
On 2024-11-13 19:26, Paul Koning wrote:
The statement in the DECnet spec that julian
half-day is 15 bits is an obvious bug with an obvious fix; clearly RSX and others have
made that fix. VMS needs to do likewise.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se On Nov 13, 2024, at 12:50 PM, John Forecast
<john(a)forecast.name <mailto:john@forecast.name>> wrote:
Depends on the implementation. Nov 9, 2021 on VMS, Ultrix and probably some others. RSX
is good until 2065.
John.
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se On Nov 13, 2024, at 10:24 AM, Keith Halewood
<Keith.Halewood(a)pitbulluk.org <mailto:Keith.Halewood@pitbulluk.org>> wrote:
Hi,
It has been mentioned elsewhere and maybe a while back too but I’m not quite sure when
DECnet (VAX/VMS 7.3) started serving up jewels like:
%%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%%
Message from user DECNET on TUPILE
DECnet event 4.10, circuit up
From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64
Circuit UNA-0
Regards
Keith
_______________________________________________
HECnet mailing list --hecnet(a)lists.dfupdate.se <mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se <mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
8:58 p.m.
Well. Bad design is not the same as "bug" either. ;-)
I would suspect the author had some reason (good or bad) for defining it
the way it was.
I think extending it to unsigned 16 bits is a very straight forward and
obvious way to fix this.
But to be honest, I think the whole format is completely broken to begin
with. Either just specify it as seconds (or days) after some epoch, or
have separate fields for each component. Julian half-days? Who on earth
came up with that idea?
The formula is just horrific:
JULIAN =
(3055*(MONTH+2)/1OO-(MONTH+10)/13*2-91+(1-(YEAR-YEAR/4*4+3)/4)*(MONTH+10)/13+DAY-1+(YEAR-1977)*365+(YEAR-1977)/4)*2
Johnny
On 2024-11-13 20:20, Paul Koning wrote:
By "bug" I meant "specification
bug". The author of the DNA NetMan spec messed up here. Yes, VMS faithfully follows
that bad design.
The bugfix amounts to fixing the text of the spec, then changing the implementations to
match the corrected text. I don't know if the former has ever been done but obviously
a number of DECnet implementations acted as if had been. :-)
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 13, 2024, at 1:53 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
I would not call it a bug. It was initially defined that way. However,RSX officially
decided to start treating it as an unsigned 16-bit value with the last releases, and
documented this.
And it's a change that do make sense.
But if others have not applied the same update, then it makes sense that they would zero
the value if it have the high bit set.
Johnny
On 2024-11-13 19:26, Paul Koning wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se The statement in the DECnet spec that julian
half-day is 15 bits is an obvious bug with an obvious fix; clearly RSX and others have
made that fix. VMS needs to do likewise.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se On Nov 13, 2024, at 12:50 PM, John Forecast
<john(a)forecast.name <mailto:john@forecast.name>> wrote:
Depends on the implementation. Nov 9, 2021 on VMS, Ultrix and probably some others. RSX
is good until 2065.
John.
> On Nov 13, 2024, at 10:24 AM, Keith Halewood <Keith.Halewood(a)pitbulluk.org
<mailto:Keith.Halewood@pitbulluk.org>> wrote:
>
> Hi,
> It has been mentioned elsewhere and maybe a while back too but I’m not quite sure
when DECnet (VAX/VMS 7.3) started serving up jewels like:
> %%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%%
> Message from user DECNET on TUPILE
> DECnet event 4.10, circuit up
> From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64
> Circuit UNA-0
> Regards
> Keith
> _______________________________________________
> HECnet mailing list --hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se>
> To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se <mailto:hecnet@lists.dfupdate.se>
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
9:02 p.m.
(I should point out that it is Julian half-days since Jan 1, 1977)
Johnny
On 2024-11-13 20:58, Johnny Billquist wrote:
Well. Bad design is not the same as "bug"
either. ;-)
I would suspect the author had some reason (good or bad) for defining it
the way it was.
I think extending it to unsigned 16 bits is a very straight forward and
obvious way to fix this.
But to be honest, I think the whole format is completely broken to begin
with. Either just specify it as seconds (or days) after some epoch, or
have separate fields for each component. Julian half-days? Who on earth
came up with that idea?
The formula is just horrific:
JULIAN =
(3055*(MONTH+2)/1OO-(MONTH+10)/13*2-91+(1-(YEAR-YEAR/4*4+3)/4)*(MONTH+10)/13+DAY-1+(YEAR-1977)*365+(YEAR-1977)/4)*2
Johnny
On 2024-11-13 20:20, Paul Koning wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
By "bug" I meant "specification
bug". The author of the DNA NetMan
spec messed up here. Yes, VMS faithfully follows that bad design.
The bugfix amounts to fixing the text of the spec, then changing the
implementations to match the corrected text. I don't know if the
former has ever been done but obviously a number of DECnet
implementations acted as if had been. :-)
paul
On Nov 13, 2024, at 1:53 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
I would not call it a bug. It was initially defined that way.
However,RSX officially decided to start treating it as an unsigned
16-bit value with the last releases, and documented this.
And it's a change that do make sense.
But if others have not applied the same update, then it makes sense
that they would zero the value if it have the high bit set.
Johnny
On 2024-11-13 19:26, Paul Koning wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se The statement in the DECnet spec that julian
half-day is 15 bits is
an obvious bug with an obvious fix; clearly RSX and others have made
that fix. VMS needs to do likewise.
paul
> On Nov 13, 2024, at 12:50 PM, John Forecast <john(a)forecast.name
> <mailto:john@forecast.name>> wrote:
>
> Depends on the implementation. Nov 9, 2021 on VMS, Ultrix and
> probably some others. RSX is good until 2065.
>
> John.
>
>> On Nov 13, 2024, at 10:24 AM, Keith Halewood
>> <Keith.Halewood(a)pitbulluk.org
>> <mailto:Keith.Halewood@pitbulluk.org>> wrote:
>>
>> Hi,
>> It has been mentioned elsewhere and maybe a while back too but I’m
>> not quite sure when DECnet (VAX/VMS 7.3) started serving up jewels
>> like:
>> %%%%%%%%%%% OPCOM 13-NOV-2024 15:15:13.82 %%%%%%%%%%%
>> Message from user DECNET on TUPILE
>> DECnet event 4.10, circuit up
>> From node 29.109 (TUPILE), 1-JAN-1977 00:00:53.64
>> Circuit UNA-0
>> Regards
>> Keith
>> _______________________________________________
>> HECnet mailing list --hecnet(a)lists.dfupdate.se
>> <mailto:hecnet@lists.dfupdate.se>
>> To unsubscribe send an email tohecnet-leave(a)lists.dfupdate.se
>> <mailto:hecnet-leave@lists.dfupdate.se>
>
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> <mailto:hecnet@lists.dfupdate.se>
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
> <mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
10:18 p.m.
On Nov 13, 2024, at 2:58 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
Well. Bad design is not the same as "bug" either. ;-)
It is to me, and I worked in that group.
I would suspect the author had some reason (good or
bad) for defining it the way it was.
I think extending it to unsigned 16 bits is a very straight forward and obvious way to
fix this.
But to be honest, I think the whole format is completely broken to begin with. Either
just specify it as seconds (or days) after some epoch, or have separate fields for each
component. Julian half-days? Who on earth came up with that idea?
The formula is just horrific:
JULIAN =
(3055*(MONTH+2)/1OO-(MONTH+10)/13*2-91+(1-(YEAR-YEAR/4*4+3)/4)*(MONTH+10)/13+DAY-1+(YEAR-1977)*365+(YEAR-1977)/4)*2
It probably comes from a desire to do things with 16 bit elements.
That formula looks painful because the Julian/Gregorian calendar is. The definition of
the value is simply days since epoch, times two plus 1 if it's afternoon. The point
of half-days is to fit the time of day (in seconds) in 16 bits rather than 17.
RT-11 does it vaguely like this: days since epoch and time in seconds, but the difference
is that they do use whole days and 17 bit time.
paul
10:33 p.m.
On Nov 13, 2024, at 4:18 PM, Paul Koning
<paulkoning(a)comcast.net> wrote:
FWIW, for decades now I have told younger engineers that they can close out a bug report
with the status "works as designed" only if the design is correct. And the
design is correct only if they are willing to stand in front of a room full of customers
to explain why it is.
By that simple test, what we have here is a bug.
paul
On Nov 13, 2024, at 2:58 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
Well. Bad design is not the same as "bug" either. ;-)
It is to me, and I worked in that group.
11:34 p.m.
On 2024-11-13 22:33, Paul Koning wrote:
By that definition, we still have a bug. Changing to unsigned 16 bits
only gives us a few more years...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 13, 2024, at 4:18 PM, Paul Koning
<paulkoning(a)comcast.net> wrote:
FWIW, for decades now I have told younger engineers that they can close out a bug report
with the status "works as designed" only if the design is correct. And the
design is correct only if they are willing to stand in front of a room full of customers
to explain why it is.
By that simple test, what we have here is a bug. On Nov 13, 2024, at 2:58 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
Well. Bad design is not the same as "bug" either. ;-)
It is to me, and I worked in that group.
13 Nov
13 Nov
11:33 p.m.
On 2024-11-13 22:18, Paul Koning wrote:
:-)
It could still have been done so much cleaner.
On Nov 13, 2024, at 2:58 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
Well. Bad design is not the same as "bug" either. ;-)
It is to me, and I worked in that group. I would
suspect the author had some reason (good or bad) for defining it the way it was.
I think extending it to unsigned 16 bits is a very straight forward and obvious way to
fix this.
But to be honest, I think the whole format is completely broken to begin with. Either
just specify it as seconds (or days) after some epoch, or have separate fields for each
component. Julian half-days? Who on earth came up with that idea?
The formula is just horrific:
JULIAN =
(3055*(MONTH+2)/1OO-(MONTH+10)/13*2-91+(1-(YEAR-YEAR/4*4+3)/4)*(MONTH+10)/13+DAY-1+(YEAR-1977)*365+(YEAR-1977)/4)*2
It probably comes from a desire to do things with 16 bit elements. That formula looks painful because the
Julian/Gregorian calendar is. The definition of the value is simply days since epoch,
times two plus 1 if it's afternoon. The point of half-days is to fit the time of day
(in seconds) in 16 bits rather than 17.
I haven't really tried to break up and understand that full expression.
I sortof wonder how they actually manage to deal with the different
number of days in the months, as well as leap years, but I guess that
would be a reason for the complexity of it.
But still - why *half* days??? Would that be so that they can express
time during the day as seconds in a 16-bit word, since a full day is a
bit more than can be represented in 16 bits?
Anyway, it really is not a way that I think is very nice.
RT-11 does it vaguely like this: days since epoch and
time in seconds, but the difference is that they do use whole days and 17 bit time.
And what about RSTS/E? Don't that one do something like day*1000+year?
I really do prefer what RSX have. And I guess the first point of
problems will be the year 10000. But of course, there are other things
that will break long before that, which are also date related. :-(
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
18 Nov
18 Nov
12:59 a.m.
I would point out that sometimes things just 'happen' and it is
difficult to anticipate how long something is going to be used or even
if that ever occurred to anyone. So sometimes what got picked was very
often 'good' for machines of limited memory and CPU of the time.
One example that comes to my mind is the date format used on DECtapes
before 1975, which had a representation ((Y-1964)*12.+M-1)*31.+D-1,
where "Y" is the year, "M" is the month (1-12), and "D" is
the day of
the month (1-31). However, the field itself used to store the date was
12 bits. Why 12 bits? One assumes PDP-8, but I really can't recall why.
Yet it ran out in 1975 and had to be widened to 15 bits. Where to find
the space? In short, the 3 bits got scrounged up.
Bit 35 of the first 66 words (0 through 65) of the directory block
contains the high order three bits of the 15-bit creation date of each
file on the DECtape. The high order three bits of the 15-bit creation
date for file 1 are contained in bit 35 of words 0, 22, and 44. Word 44
contains the first (most significant) digit, word 22 contains the second
and word 0 contains the third.
The bits for file 2 are in 1, 23, 45, etc.
If you were to look at this from the design perspective, then it's a bug
with a solution that is only somewhat short of horrifying ...
At WPI, when we were going through this madness on Tops-10, well, we CS
types just sat up and clapped our hands in wonderment. We thought it,
"a fine hack", but what did we know?
From my perspective, even in the 1980's if I caught anyone trying to
bum a bit or two like that on Tops-20 or anything else I worked on, I
put a stop to it. It's just not worth it when you overflow the field.
And dates are hairy. There's just no two ways about it. We humans
define things for our convenience and don't change until we do change
and it makes for a lot of special cases.
------------------------------------------------------------------------
It could still have been done so much cleaner.
------------------------------------------------------------------------
I would suspect the author had some reason (good or bad) for
defining it the way it was.
I think extending it to unsigned 16 bits is a very straight forward
and obvious way to fix this.
But to be honest, I think the whole format is completely broken to
begin with. Either just specify it as seconds (or days) after some
epoch, or have separate fields for each component. Julian half-days?
Who on earth came up with that idea?
The formula is just horrific:
JULIAN =
(3055*(MONTH+2)/1OO-(MONTH+10)/13*2-91+(1-(YEAR-YEAR/4*4+3)/4)*(MONTH+10)/13+DAY-1+(YEAR-1977)*365+(YEAR-1977)/4)*2
------------------------------------------------------------------------
It probably comes from a desire to do things with 16 bit elements.
20 Nov
20 Nov
10:27 p.m.
On Nov 17, 2024, at 6:59 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
I would point out that sometimes things just 'happen' and it is difficult to
anticipate how long something is going to be used or even if that ever occurred to anyone.
So sometimes what got picked was very often 'good' for machines of limited
memory and CPU of the time.
One example that comes to my mind is the date format used on DECtapes before 1975, which
had a representation ((Y-1964)*12.+M-1)*31.+D-1, where "Y" is the year,
"M" is the month (1-12), and "D" is the day of the month (1-31).
However, the field itself used to store the date was 12 bits. Why 12 bits? One assumes
PDP-8, but I really can't recall why.
Yet it ran out in 1975 and had to be widened to 15 bits. Where to find the space? In
short, the 3 bits got scrounged up.
I remember that because we encountered that issue in college, and I found the cause and
created a patch that I then sent to DEC.
It isn't because of the PDP-8. The reason is that in DOS-11, where that format
originates, the sign bit meant "contiguous file" and the next 3 bits were for
the open count. At least that's what the documentation said, I don't know if DOS
actually used that. RSTS did not so it seemed safe to grab those 3 bits. Making it 16
bits was considered not so safe because that might make DOS think the file is contiguous,
which would make it read (or write!) the wrong data.
paul
1
days inactive
8
days old
17 comments
5 participants
participants (5)
-
John Forecast -
Johnny Billquist -
Keith Halewood -
Paul Koning -
Thomas DeBellis