Time to turn back the clocks
By Terry Eagan
Whenever you reset your system clock to an earlier time (for example, sites in several time zones turn back the clock by 1 hour this month), you must not allow updating activity to Model 204 or System 1032 files until the new time is later than the time-stamp of the last file update prior to resetting the system clock. (Note that a timestamp applies to System 1032 only if a journal file is active for a given dataset being updated. However, the concept also applies to system-updated attributes such as date/time of entry.)
Enforcing a time lag prevents problems with recovery, if a hardware/software system crash occurs during the window of "overlap" time. For example:
Because Model 204 copies a pre-image of any page about to be updated since the last checkpoint time, any pages that were updated after 1:05 in the original online are assumed to be already logged to the checkpoint dataset. (If rollback is required, it is probably incomplete).
In System 1032's case, the example posts later sequential checkpoints using the now earlier time-stamp. This creates an ambiguous situation during a rollback attempt.
During restart/ recovery processing, journal and checkpoint logic assumes EOF, if an earlier time-stamp is encountered, thus causing incomplete rollback (and subsequent roll-forward).
To ensure data integrity, take the following steps when turning back the system clock:
Note: Do not allow updating of Model 204 BATCH204 jobs during the overlap time.
Contact CCA Webmaster Copyright 2008
