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/VSE. Please refer to TEC1312225 for CA Datacom products running on z/OS.
Time change ahead to DST
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, the new time is reflected immediately. See below for procedures to set the time ahead from Standard Time to DST.
Time change back to Standard Time
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 that time from 01.00 to 02.00 will take place once again.
In order to revert to Standard Time, CA Datacom users have to recycle their MUF or accept that the MUF date-time would be wrong from the point of the time change until the region was next recycled.
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.
Logging and Recovery
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.
PXX Time-Based Reporting
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.
Applications That Retrieve Date/Time from the MUF
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 re-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 in the following procedures.
Time Change Procedures (changing from Standard Time to DST, or returning to Standard Time from DST)
These procedures apply to all currently supported z/VSE versions of CA Datacom/AD and CA Datacom/DB.
As always, please contact CA Technologies support for CA Datacom if you have further questions.