|
An old note...
:I would also like to get some information on what could make a DTSS server
:come up after a power fail and think it is actually 1 day short of a full
:year ahead. The customer was down due to a power failure for a couple
:hours. When the system came back up, it thought the date was 10-FEB-1997
:instead od 11-FEB-1996. This happened on a VAX station 4000-60 running VMS
:V6.1 and DECnet/OSI V5.8.
This sort of skewed time stuff is fairly common on OpenVMS VAX,
particularly if a SET TIME has not been issued lately, and/or if
system disks are being shuffled around, or if something else causes
the BBW time to get `out-of-synch' with the time saved in the system
image.
The VAX TOY (time of year) clock has a circa 400 day window of
validity, and OpenVMS needs to pull the year out of the system image
during bootstrap to "complete" the time calculation -- SET TIME keeps
the TOY and the system image set to values that will properly reproduce
the correct time on reboot based on the the running system time, and
this means the SET TIME command needs to be issued occasionally, and
particularly sometime in January.
|
| The TOY clock is implemented on nearly every VAX with a BB_WATCH.
This means that the OS takes the year, throws it away to get the seconds since
the beginning of a base year, gives it to another VMS kernel module which
adds in some arbitrary years, and stores that in the BB_WATCH. If you go to
get the time from the BB_WATCH and it has been more than 50 days into the
year without setting the time, which writes a value into the system image
and a new delta time into the BB_WATCH, you end up with a delta time computation
that is correct, BUT it won't fit in a 32 bit integer, so the delta time
can't be passed back to the other VMS kernel module that adds in the base
year from the system image.
As I recall, there is only one VAX that actually has a "hardware" TOY clock,
the VAX-11/780. I think that it does actually use a 32 bit counter. All the
rest of the VAX systems either didn't have a clock (VAX-11/730) or they used
a BB_WATCH. BB_WATCHes were much cheaper than all alternatives because they
were being made by the millions for personal computers.
What is interesting is that people argue that it has to be this way because
this is what the VAX architecture specifies. But the same VAX architecture
specified, note the past tense, that there would be packed decimal instructions
and a bunch of other instructions that are now optional in the hardware and
optional for the O/S or runtime to emulate.
The further irony is that all "hardware architecture" implementing the TOY clock
is all VMS code. This is a case of VMS taking a shotgun and pointing it at its
and its customer's feet and every year pulling the trigger. The reason that
this is done is that there is a law that says that the trigger on the gun
must be pulled every year, so that makes all the injuries ok; the injuries
can be avoided if you follow the proper procedure and jump just as the trigger
is pulled.
However, if you think that VMS was stupid, Digital UNIX preserved the TOY clock
onto the MIPS box and then onto Alpha. Six months before DU first shipped,
I asked that this be changed, but they said that it wasn't possible. VMS had
a window of 30 days before shipping V1, and Jim Kauffman, et al, made and
tested a solution that took into account the fact that DU was not going to
set the BB_WATCH to the actual date, but to a delta from the beginning of the
year.
|