Setting clocks back

Here are two recommended methods for adjusting the time for Fall or when the system time needs to be set earlier than its current setting. One method involves restarting your system while the other does not.

IPL Method

Checklist for setting clock backwards in time: Ensure that BRMS operations have halted and none are scheduled to start. Run command DSPPFM FILE(QUSRBRM/QA1ANET2) and ensure that there are no records in the file.
  1. Ensure that BRMS operations have halted and none are scheduled to start.
  2. Run command DSPPFM FILE(QUSRBRM/QA1ANET2) and ensure that there are no records in the file. If there are records, then updates have not been synchronized yet. Allow the records to synchronize to all systems.
  3. Ensure that no BRMS operations are occurring on any system in the network, such as saves, movement or maintenance.
  4. Issue the PWRDWNSYS RESTART(*NO) command and put the system into manual mode.
  5. Wait almost an hour (allow for the amount of time to IPL also) and start the IPL.
  6. At the Date/Time screen, change the system time 1 hour backwards, and continue the IPL.
  7. When all systems have been set, resume BRMS operations.

    Example: Clocks will be set at 2 a.m. and will be going back 1 hour. At 2 a.m., issue the PWRDWNSYS command. Wait almost one hour. Start the IPL of the system. When the system comes back up, set the clock to 2 a.m. (and whatever minutes have passed). This prevents the repetition of the 1 a.m. - 2 a.m. hour on your system, and ensures that all system journals and BRMS have no problems with duplicated time stamps or time stamps that are out of sequence with real time.

If necessary, nightly system backups (STRBKUBRM) can be run even though not all systems have been reset as long as the following are true:
  1. The target system volume record is more than 1 hour old.

    Example: The last time volume X was updated was when it was moved this morning. Under these circumstances, an update for volume X from a system with a one hour earlier time will still be accepted on a system with a one hour later system time, and an update from a system with a later time will still be accepted on a system with an earlier system time because there is more than 1 hour difference between the time the save and the move were done. If the difference between the updates would be less than the 1 hour time difference on the systems, problems could result and the wrong update could be ignored.

  2. The system owns plenty of scratch media (so it will not need to use DDM to 'borrow' media from other systems). During the time period that clocks are being reset, it is best to avoid operations that involve the update of a record on another system.
  3. Do not run other BRMS operations, such as movement or maintenance or use WRKMEDBRM Option 2 on a volume that is not owned by the system that you are working on.
  4. Resume normal BRMS operations only after all systems have been reset, and the last 1 hour of repeated time has passed on every system in the network.

Non-IPL Method

The general recommendation is to use the IPL Method as stated above. This protects all time stamp dependent operations on your system as well as BRMS. However, if this is not possible due to operation schedules, you must carefully plan your BRMS activities so that only the system that owns a piece of media will try to update it during the time that system clocks are not yet all reset and the hour is being repeated.
Note:
  1. Do not perform any BRMS activities during the period of resetting clocks, and during the one hour of repeated time. If you must start backups during the repeated hour, ensure that the system owns enough scratch media for the backups, and that no other update operation will occur on that media during the repeated time period.
  2. If you repeat a period of time by setting the clocks backwards, and during that period, you cause the same volume to be updated, those updates might not be synchronized correctly. BRMS relies upon time stamps on the records to order the records in the file and decide if an update should occur or not.
  3. Save jobs will synchronize an update to the volume information about all network systems to show that the volume is active and owned by the saving system. If one of the other systems had a record for that volume that appeared to be more recent (because that system did not yet have its clock reset), that system would throw away the update record, and synchronize its view of the volume to the other network systems, causing an otherwise valid update to be ignored. It would be possible for BRMS to then overwrite such a tape, and the integrity of your system recovery plan would be compromised.
  4. On the day that times will be changed, you should ensure that while you are doing your nightly saves, no other update activity is occurring for the same volume on another system. The best way to avoid this is to ensure that you have sufficient expired media owned by each system for the backups during this time change period (so that systems will not try to 'borrow' another system's media). Also make sure maintenance, movement, WRKMEDBRM opt 2, and all other update activity do not occur. That way, updates to media records will only be initiated by save activities from systems which already own the volumes.