Twice a year, different regions around the world change the local time and clocks between Summer Time or Daylight Saving 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/OS. Please refer to article 46173 for Datacom products running on z/VSE.

First, these instructions pertain to the running MUF. If using a primary MUF/Shadow MUF pair, it is recommended to shutdown the Shadow MUF (using the EOJ console command) and then restart it after the system time has been changed.

Time change ahead to DST

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, or when the 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 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:

1. Logging and Recovery that spans the time change
2. PXX reporting that is based on particular time values
3. 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 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/AD 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.

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.

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. If the SYSOUT MUF Startup Option is used instead of the PXX, nothing special needs to be done.

Applications That Retrieve Date/Time from the MUF

Applications running 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 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 Datacom/AD and Datacom/DB.

1. Stop all online and batch activity against the MUF or use the QUIESCE operator console command: /F mufjob,QUIESCE TXN
   Responses:
   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.) 
2. Spill your Log Area (LXX) using the DBUTLTY SPILL or SPILLOPT command as usual.
3. Print and clear the PXX file as desired.
4. Issue STATUS command to display current time in the MUF: /F mufjob,STATUS. You can optionally issue the /D T console command to display the system time in the SYSLOG.
5. Reset the time in your operating system according to your procedures.
6. Reset the time in the MUF using the TIME_SYNC operator console command: /F mufjob,TIME_SYNC
   Response:
   DB01325I - CONSOLE COMPLETE, TIME_SYNC
7. Issue STATUS command to display changed current time: /F mufjob,STATUS, and the optional /D T command.
8. Print and clear the PXX file once again, as desired.
9. Resume normal MUF operation, or use the QUIESCE operator console command to restore functionality: /F mufjob,QUIESCE OFF
   Response:
   DB02910I- MUF QUIESCE OFF ENDED, TXN WAS IN EFFECT
10. Reset the time in CICS regions and other applications, then continue normal operations.

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 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:

Datacom/DB Version 15.1 Database and System Administration Guide, in the section "Maintenance using Console Commands."

As always, please contact Broadcom support for Datacom if you have further questions.

* * *