[HECnet] Future problems?
Johnny Billquist
bqt at softjar.se
Fri Jul 15 01:38:29 PDT 2016
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.
>> )
> 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
>
--
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
More information about the Hecnet-list
mailing list