15 Jul
2016
15 Jul
'16
11:51 a.m.
When browsing the Tops-10 sources I stumbled onto this (d36com.mac):
NMXTIM:
IFN FTOPS10,<
MOVE T1,DATE## ;GET CURRENT UDT (IN DAYS,,FRACTION)
MOVE T2,TIME## ;GET CURRENT TIME (IN JIFFIES SINCE MIDNIGHT)
LSH T1,-^D17 ;TRUNCATE TO NUMBER OF HALF DAYS.
SUBI T1,124210_1 ;CONVERT DAYS SINCE 1858 TO DAYS SINCE 1977
MOVE T3,[^D60*^D60*^D12]
IMUL T3,TICSEC## ;SECONDS SINCE HALF-DAY
TRNE T1,1 ;IS THIS THE SECOND HALF OF A DAY?
SUB T2,T3 ;YES, RECORD SECONDS SINCE HALF-DAY
IDIV T2,TICSEC## ;CONVERT JIFFIES INTO SECONDS.
IMULI T3,^D1000 ;CONVERT TO NUMBER OF MILLISECONDS*TICSEC
IDIV T3,TICSEC## ;CONVERT TO NUMBER OF MILLISECONDS.
SKIPL T2 ;MAKE SURE WE HAVE A POSITIVE NUMBER OF SECONDS
TDNE T1,[XWD -1,600000] ;MAKE SURE NO DATE OVERFLOW
BUG.(HLT,COM911,D36COM,SOFT,<The date is past 9 November 2021>,,<
Cause: The 2 byte julian half-day field in an event message is limited
to 9 november 2021. The routine above has calculated the julian
half-day, and has found that it overflowed.
I doubt very much that the date itself has really gone past 2021.
Probably someone smashed an AC or the routine to get the time
from the monitor is returning junk.
)
RET
;END IFN FTOPS10
This made me search for some documentation, and I found aa-k181a-tk
which said, amongst other things:
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 2621
(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.
Some observations/questions:
* The code in Tops-10 actually checks for the half day value beeing
not more than 16 bits, i.e. it will not trigger until 2066. This
means that I will consinder it a typical case of SEP when it does.
* I have no idea what will happen when the date goes past 9-Nov-2021,
i.e. when the sixteen bit field gets the sign bit set and possibly
some software somewhere goes belly up. Maybe we should try to do a
controlled test?
* Will this be/become a problem? What to do about it?
--Johnny
15 Jul
15 Jul
10:38 a.m.
Isn't the documentation wrong, since it says 2621?
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?
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.
Johnny
On 2016-07-15 09:51, Johnny Eriksson wrote:
When browsing the Tops-10 sources I stumbled onto this
(d36com.mac):
NMXTIM:
IFN FTOPS10,<
MOVE T1,DATE## ;GET CURRENT UDT (IN DAYS,,FRACTION)
MOVE T2,TIME## ;GET CURRENT TIME (IN JIFFIES SINCE MIDNIGHT)
LSH T1,-^D17 ;TRUNCATE TO NUMBER OF HALF DAYS.
SUBI T1,124210_1 ;CONVERT DAYS SINCE 1858 TO DAYS SINCE 1977
MOVE T3,[^D60*^D60*^D12]
IMUL T3,TICSEC## ;SECONDS SINCE HALF-DAY
TRNE T1,1 ;IS THIS THE SECOND HALF OF A DAY?
SUB T2,T3 ;YES, RECORD SECONDS SINCE HALF-DAY
IDIV T2,TICSEC## ;CONVERT JIFFIES INTO SECONDS.
IMULI T3,^D1000 ;CONVERT TO NUMBER OF MILLISECONDS*TICSEC
IDIV T3,TICSEC## ;CONVERT TO NUMBER OF MILLISECONDS.
SKIPL T2 ;MAKE SURE WE HAVE A POSITIVE NUMBER OF SECONDS
TDNE T1,[XWD -1,600000] ;MAKE SURE NO DATE OVERFLOW
BUG.(HLT,COM911,D36COM,SOFT,<The date is past 9 November 2021>,,<
Cause: The 2 byte julian half-day field in an event message is limited
to 9 november 2021. The routine above has calculated the julian
half-day, and has found that it overflowed.
I doubt very much that the date itself has really gone past 2021.
Probably someone smashed an AC or the routine to get the time
from the monitor is returning junk.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
)
RET
;END IFN FTOPS10
This made me search for some documentation, and I found aa-k181a-tk
which said, amongst other things:
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 2621
(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.
Some observations/questions:
* The code in Tops-10 actually checks for the half day value beeing
not more than 16 bits, i.e. it will not trigger until 2066. This
means that I will consinder it a typical case of SEP when it does.
* I have no idea what will happen when the date goes past 9-Nov-2021,
i.e. when the sixteen bit field gets the sign bit set and possibly
some software somewhere goes belly up. Maybe we should try to do a
controlled test?
* Will this be/become a problem? What to do about it?
--Johnny
3395
days inactive
3395
days old
1 comments
2 participants
participants (2)
-
bqt＠softjar.se -
bygg＠cafax.se