Twice a year, different regions around the world change their local time and clocks between Summer Time or Daylight Savings Time (called DST) and Standard Time. This article addresses the changes needed and the process used for CA Datacom/AD and CA Datacom/DB.
This applies to the CA Datacom products running on z/OS. Please refer to KB000046173 for CA Datacom products running on z/VSE.
When the time changes forward to DST, an hour of time is lost. This change has no impact on CA Datacom systems. When the Multi-User Facility (called MUF) is recycled, or when the CA Datacom TIME_SYNC command is issued, the new time is reflected immediately. You can enter the TIME_SYNC command after the time has changed.
When the time is set back to Standard Time, an hour of time is repeated. For example, while in DST, systems will process from 01.00 until 02.00, and typically the clock is reset to 01.00 and times from 01.00 to 02.00 will take place once again.
As with the change to DST, you can use the CA Datacom TIME_SYNC command after reverting to Standard Time to reset the time in the MUF.
For the change from DST back to Standard Time, there are three areas of concern:
See below for procedures to reset the time back to Standard Time from DST.
The concern here with CA Datacom products is performing a recovery using log records from this overlapping hour of time. This applies to both CA Datacom/AD and CA Datacom/DB when using the MUF Startup Option LOGRCV NO or LOGRCV YES. There is no concern for CA Datacom/AD users who do not use logging and have the MUF Startup Option LOGRCV NEVER.
CA Datacom stores records in the Log Area/Recovery Area (LXX/RXX) with both an external date-time and a store clock value. Since LXX processing does not allow a date-time step down, special care must be taken in RESTART or RECOVERY processing if performed across the time change boundary. For example, recovery should not process tapes with data that spans the time change boundary; recovery may need to be run twice -- once with the RXX from prior to the time change and a second time with the RXX from after the time change.
On z/OS, when the time is changed backwards, the external time stored in the log records is not incremented further until the new time "catches up." The store clock time, however, changes steadily during and across MUF executions. Since version 14.0, the RESTART process by default uses the store-clock time instead of the date-time value.
At the end of DST, the PXX would be sensitive to a time step down. If the time is being set to the past and important data exists in the PXX, the PXX should be printed and cleared both before and after the TIME_SYNC command is used. This is because DBUTLTY does not print PXX data once a step down in time is encountered in the file. If the SYSOUT MUF Startup Option is used in place of the PXX, nothing special needs to be done.
Applications that run across the time change boundary that are sensitive to dates/times and which obtain date information from the MUF (such as SQL timestamps inserted into a data record) should be reviewed for possible modifications or scheduling around the time change.
For example, users of the CA Datacom/DB Accounting Facility for performance snapshots or job chargeback during the overlapping hour might need to follow a special procedure during this time. In some cases, it may be appropriate to do an ACCT SPILL or ACCT CLOSE followed by a backup, extract, or report on the accumulated Accounting table data and then a process to delete or archive the data. This would need to be done prior to bringing the MUF down or issuing the TIME_SYNC command in the following procedures.
These procedures apply to all currently supported z/OS versions of CA Datacom/AD and CA Datacom/DB (15.x, 14.x), as well as unsupported 12.0 systems.
When resetting the time back to Standard time from DST, many firms elect to stop processing for the repeated hour, either by letting the machine sit idle, or by doing an IPL at the end of the fallback hour. In these cases, if the CA Datacom MUF is not running (clean shutdown EOJ), when it is eventually started in the "new" Standard Time, then nothing special needs to be done.
For further information about the QUIESCE and TIME_SYNC console commands, please refer to the following guides:
As always, please contact CA Technologies support for CA Datacom if you have further questions.