|
The basic problem is a limitation in the A990 Time of Day (TOD) clock in that it only keeps track of years with two digits of accuracy and does not support or know about century changes.
To compensate for this deficiency the ReadA990Clock and WriteA990Clock routines (which are used by the CLOCK program to read and write times to the TOD clock) use one of the "alarm" registers on
the clock chip to record the Century. When the clock rolls over to a new century the register used by the A990Clock routines is not incremented and a bad time and date is reported.
Warning: Anyone programing the TOD clock directly using the .WTC and .RTC assembly language instructions will need to account for the century change as the TOD clock does not support it.
There are no plans at present to fix the TOD clock chip as this anomaly does not affect the system time of the running system in any way. However, we have made a software
patch available to the A990Clock routines which eliminates the problem. You may also use the procedure described below which will circumvent the problem.
What follows is an explanation of what you could expect to see, what the scenario is that causes it, and how to prevent the problem.
At midnite on Dec 31, 1999, the TOD clock does not rollover to the year 2000 correctly. After midnite on Dec 31, 1999, the TOD clock (using the CLOCK program) will report:
Aug Jan 18, 1902 33:22:28 am
If the TOD clock is subsequently set to a valid date in or after the year 2000 then everything works normally.
The simple workaround for this problem is to make sure the TOD clock is reset via the CLOCK program, using the system time, after the year 2000 rollover occurs.
The impact of this problem should be minor. Since the system clock (TBG) is much more accurate than the TOD clock, it has always been recommended that the TOD clock be synchronized to the system
time periodically. The only scenario where the TOD clock problem would cause concern is if:
- The year 2000 rollover occurs, and
- The TOD clock is not reset, and
- The system is rebooted, and
- The system time is set from the TOD clock on bootup.
In this case, the CLOCK program will return the following error:
Error -1 when setting the system time; returning that value in $return1.
and the system time will revert to April 1, 1983.
If you are running 6.2 or 6.21 RTE-A, you can schedule a CRON job to execute at 12:00:01 Jan 1 to reset the TOD clock. We actually recommend you reset the TOD clock on a more regular basis (like
once a day) but you could do this as infrequent as once a year with cron. This CRON job would simply run the CLOCK program as follows:
CLOCK set
If you are using 6.1 or earlier, you can time schedule the following program nightly at 12:01 AM to reset the TOD clock from the system time. This is recommended, and would eliminate the problem.
ftn7x,l,s
program settod(3,99),
c This program simply schedules "CLOCK" to set the A990
c Time-Of-Day clock from the system time. This program is
c time scheduled to run every midnite to sync the two.
c
c The TBG is more accurate that the TOD, thus we reset the TOD
c every night.
c
implicit integer (a-z)
integer*2 error,param(5)
c
ERROR=FmpRunProgram('XQ,clock,a990,set',param,clock)
if (error.ne.0) then
write(1,*) ' Error scheduling CLOCK ','Error is ' ,error
stop
endif
end
Then time schedule SETTOD as follows: (This should be done from the welcome file at bootup)
at 12:1:1:01 am 24 h settod
(Note: SR# 5003373456 has been submitted for this problem.)
Software patch:
To obtain a software patch to fix the CLOCK program, see the technical support page article "A990 TOD Patch (uuencode)" which contains the patch and instructions on how to install it.
|