Hello.  We have had some trouble with the clocks on our two machines and we
are looking for validation of our assumptions about what occurred and
suggestions about what the potential impact has been.

We discovered that the hardware clock offset from GMT was incorrect on our
two machines.  On the first machine the offset was 26hours and 15minutes
(e.g., 18hours and 15minutes into the future from what it should be since
the offset should be 8hours West for PST).  On the second machine the offset
was 6hours and 45minutes (e.g., 1hour and 15minutes into the past from what
it should be since the offset should be 8hours West for PST).  These errors
were due to the incorrect use of the SETCLOCK command to change the time for
both daylight/standard changes and for Y2K test changes.  In the case of
both machines the software clock was correct (e.g., consistent with the
clock on the wall).  We discovered this problem because a timestamp in a
database record was being generated by two different programs, one using the
software clock and one using the hardware clock.  The results were that
timestamps created by reading the software clock were consistent with the
clock on the wall, but the timestamps created by reading the hardware clock
were 18hours and 15minutes into the future.

HPRC outlined the following steps to correct the problem:

1. Use SETCLOCK with the timezone parameter to set the time to 8hours West
from GMT.
2. Use SETCLOCK with the cancel parameter to cancel any ongoing correction
caused by the first step.
3. Use SETCLOCK with the date/time parameter to set the software clock to
8hours West from GMT.

Although these steps succeeded in correcting the problem, they were
unfortunately taken at noon under a normal system load (e.g., without
stopping any system or user processing).  We are left to determine what
damage as been done.  First of all, we need to understand what occurred to
the clocks in the 10 minutes that it took to perform these steps.

On the first machine (26hours and 15minutes):

1. HW CLOCK corrected to 8hours; SW CLOCK moved 26hours and 15minutes offset
from GMT (18hours and 15minutes in the future), and then begins to slow down
2. HW CLOCK no change; SW CLOCK slow down stopped
3. HW CLOCK no change; SW CLOCK moved to 8hours offset from GMT

During the time it took to perform these steps, any timestamps that use the
SW clock were off by 18hours and 15minutes.  This includes:

1. Image logging (Corrected by doing a backup of the database and
re-starting logging)
2. Job scheduler (JMS3000 from DESIGN3000, Inc.) (Jobs that were launched
out of sequence and at the wrong time will need to be re-searched)
3. Application Programs (All timestamps will need to be researched for
impact)
4. System processes (console logging?)(It is unknown what effect this had
and what corrections need to be taken)

On the second machine (6hours and 45minutes):

1. HW CLOCK corrected to 8hours; SW CLOCK moved 8hours offset from GMT, and
then begins to slow down
2. HW CLOCK no change; SW CLOCK slow down stopped
3. HW CLOCK no change; SW CLOCK moved to 8hours offset from GMT

During the time it took to perform these steps, there could only be
timestamps that are misleading due to the clock slowing down.  Therefore, we
do not anticipate any impact to this machine.