🚀 go-pugleaf

Way back around MPE XL 1.0, I wrote what I think was the first ever clock
utility for MPE XL  (It was called CLOCKXL, got moderate distribution, and
worked up until 3.0, I think -- I never went back in to see why it 'broke'
at that time.)  When I wrote this utility, I was in the field, and did it
because 'it needed to be done'.

When I transferred to the division (CSY) in '89, I actually had several
interesting conversations with those who owned the relevant code about why
setting the clock is forbidden on an up-and-running system.  The crux of the
argument is thus:

   - Setting the clock forward is OK.
   - Because timestamps in log files (both system and IMAGE, at the least)
     contain the LOCAL time, resetting the clock can cause transactions to
     be out-of-sync in the log file.  This is not good.
   Solution:  Do not allow system clock to be reset while system is up.

Now, the astute reader has no doubt realized that the solution does nothing
to address the problem.  You shut down your system, reboot, reset the system
clock back one hour, and your timestamps are out of sequence, exactly as if
you had done this while the system was running.  It just requires more time
and effort to shoot yourself in the foot.

The most correct solution would be to use GMT timestamps for all logfiles.
This would also probably simplify multi-system transactions that span time
zones.  DCE will provide some timing services that address these kind of
issues; in the meantime, it's up to application programmers to consider the
effect of these kind of things, and code accordingly.

In MPE/iX 5.0, a CI-level command or utility (I'm not sure which) is being
provided to reset the system clock.  It works, I am told, by either speeding
up or slowing down the system clock until it gets to the 'new' time -- thus,
there is no 'jumping' of the time either forward or backward.  This, hopefully,
will put an end to the semi-annual frustration caused by the lack of such a
utility.

Another piece of our MPE heritage gone forever.  Sigh.   :)

Mike Yawn
Commercial Systems Division

NOT speaking for HP, officially or otherwise.