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 Datacom/AD and Datacom/DB.
This applies to the Datacom products running on z/VSE. Please refer to article 46307 for Datacom on z/OS.
Release: 12.0 and 11.0
When the time changes forward to DST, an hour of time is lost. This change has no impact on 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.
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, 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.
The concern here with Datacom products is performing a recovery using log records from this overlapping hour of time. This applies to both Datacom/AD and Datacom/DB when using the MUF Startup Option LOGRCV NO or LOGRCV YES. There is no concern for Datacom users who do not use logging and have the MUF Startup Option LOGRCV NEVER.
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.
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 . This is because DBUTLTY does not print PXX data once a step down in time is encountered in the file.
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 rescheduling around the time change.
For example, users of the 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.
These procedures apply to all currently supported z/VSE versions of Datacom/AD and Datacom/DB.
As always, please contact Broadcom support for Datacom if you have further questions.