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 TEC1641034 for CA Datacom products running on z/VSE.
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, 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.
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 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:
- Logging and Recovery that spans the time change;
- PXX reporting that is based on particular time values;
- Applications that retrieve date/time from the MUF.
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.
In 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.
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 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.
Time Change Procedures (returning to Standard Time from DST)
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.
- Stop all online and batch activity against the MUF or use the QUIESCE operator console command:
F mufjob,QUIESCE TXN
DB02901I - MUF QUIESCE TXN STARTING
DB02903I - MUF QUIESCE TXN FLUSHING PIPELINE
DB02904I - MUF QUIESCE TXN ENDED, IN EFFECT
(Note: Consider using QUIESCE REQUEST if appropriate.)
- Spill your Log Area (LXX) using the DBUTLTY SPILL or SPILLOPT command as usual.
- Print and clear the PXX file as desired.
- Reset the time in your operating system according to your procedures.
- Reset the time in the MUF using the TIME_SYNC operator console command:
DB01325I - CONSOLE COMPLETE, TIME_SYNC
- Print and clear the PXX file once again, as desired.
- Resume normal MUF operation, or use the QUIESCE operator console command to restore functionality:
F mufjob,QUIESCE OFF
DB02910I- MUF QUIESCE OFF ENDED, TXN WAS IN EFFECT
- Reset the time in CICS regions and other applications, then continue normal operations.
For further information about the QUIESCE and TIME_SYNC console commands, please refer to the following guides:
CA Datacom/DB Version 14.02 Database and System Administration Guide, in the section “Introduction › Maintenance using Console Commands › MUF Startup Options and Console/Console-Like Commands”
CA Datacom/DB Version 15.0 Database and System Administration Guide, in the section “Maintenance using Console Commands”
CA Datacom/DB Version 15.1 Database and System Administration Guide, in the section “Maintenance using Console Commands”
As always, please contact CA Technologies support for CA Datacom if you have further questions.