Making Date and Time Changes

Date changes

Changing the system date (QDATE) on a system in a BRMS network is not recommended.  Changing to a future date, may cause volumes to be expired prematurely even if it is being used on other systems in the network.  Changing to a previous date may have less of an impact but is still not recommended.

If the date needs to be changed for testing purposes, the system should be removed from the BRMS network before the date is changed. Consult Removing a System from My BRMS Network for information about this task.

Time changes

IBM i has automatic provisions to adjust the system time for seasonal time changes. Users must now adjust the system time (and UTC offset) by way of the QTIMZON system value. Some QTIMZON values will automatically adjust the system time for seasonal time changes when the date and time configured for seasonal time changes in the time zone arrives.

The IBM i information center has details on all of these changes. For specific inquiries regarding the operating system and seasonal time changes, contact IBM i Support.

If a QTIMZON system value is used that does not automatically adjust the system time for seasonal time changes, the following procedures should be used to account for seasonal time changes.

How to change the system clock for seasonal time changes with BRMS

(Springing forward and Falling back...)

Customers have asked, what implications this twice yearly adjustment to system time has for a BRMS network? The answer is that there is a very important reliance on the timestamp in each record for synchronization around a BRMS network.

Here are two recommended methods for adjusting the time for Fall (Setting Clocks Back) and Spring (Setting Clocks Ahead). One method involves an additional IPL of your system while the other does not:

Checklist for setting clock backwards in time:

1. Ensure that BRMS operations have halted and none are scheduled to start.
2. DSPPFM on QA1ANET2 in QUSRBRM 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:00 AM and will be going back 1 hour. At 2:00 AM, 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:00 AM (and whatever minutes have passed). This will prevent the repetition of the 1 to 2 AM hour on your system, and will ensure 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 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.
   • For example, the last time volume X was updated was by movement 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 that 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 have to 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, like 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.

Setting clocks back if an IPL cannot be performed

The general recommendation is as stated in the checklist above (this protects all time stamp dependent operations on your system, not just BRMS). However, if this is not possible due to operation schedules, then carefully plan your BRMS activities so that only the system that owns a piece of media will try to update it (do not run movement network-wide, for example) during the time that system clocks are not yet all reset and the hour is being repeated.

Ideally, do not perform any BRMS activities during the period that you are 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.

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 may not end up being 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.

For example, save jobs will synchronize an update to the volume information on 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.

So, 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 option 2, and all other update activity does not occur. That way, updates to media records will only be initiated by save activities from systems which already own the volumes.

Setting clocks ahead

Setting clocks forward in the spring does not present any special problems. Make sure that all updates in the BRMS database have flowed to all other systems before changing the system time.

1. DSPPFM on QA1ANET2 in QUSRBRM and ensure that there are no records in the file. If there are records, then updates have not synchronized yet. Allow the records to synchronize to all systems.
2. Ensure that no BRMS operations are occurring on any system in the network, such as saves, movement or maintenance.
3. Hold the jobq Q1ABRMNET in the Q1ABRMNET subsystem. (Use the WRKJOBQ command.)
4. Change the clocks forward on all systems using the CHGSYSVAL SYSVAL(QTIME) command.
5. When all system's clocks have been set, release the Q1ABRMNET jobq and resume BRMS operations.