Time Change Considerations for OPS/MVS
Article ID: 27523
Updated On:
Products
Issue/Introduction
Review this document when changing the time on a system where OPS/MVS is installed.
Environment
Component:
Resolution
The following is the recommended procedure for changing the time with OPS/MVS:
- Stop OPS/MVS
- Change the clocks
- Restart OPS/MVS.
If this is not possible or not preferred, then you can use the distribution library '.RULES (TIMECHNG)' and '.SAMPLES (TIMECHNG)'. These are designed to bring down all the TOD and ASOSMAPI processes and restart them post clock change.
The impact on OPS/MVS during a time change centers on the firing of TOD (time of day) rules. Obviously, one solution is to shutdown the product, and then restart it after the time change has occurred. However, many sites would prefer to leave the product running. For this scenario, a disabling and then re-enabling of the active TOD rules is all that is required. To accomplish this, OPS/MVS supplies a sample rule called 'TIMECHNG', which also calls an OPS/REXX program by the same name. You can find this rule in the
distributed 'OPS.SAMPLE.RULES' file for all currently supported releases. The OPS/REXX program is provided in the distributed OPS.SAMPLES.
The TIMECHNG rule is a TOD rule which should be scheduled to run a few minutes before the actual time change occurs. The rule expects that a global variable called GLOBAL0.TIMECHNG be defined. This global variable must contain the dates of the time changes using the YYYYMMDD format. It can contain the dates for several years; for example:
- 20141102
- 20150308
- 20140309
- 20131103
- 20130310
- 20131103
There is logic in the rule that will update the value of this global variable by removing each 'time change' date as it first occurs. This prevents the rule from firing again during the 'fallback' time change. The updating of the GLOBAL0.TIMECHNG occurs after the rule determines if it should call the TIMECHNG OPS/REXX.
The TIMECHNG OPS/REXX does the disabling and re-enabling of all OPS/MVS time of day rules. It uses a variable called maxsecs that is set to 120. This value represents the maximum time in seconds that REXX will wait for the time change to occur. The program will automatically detect when the time change has completed. Thus, if it is completed before the wait interval, the program will continue to process. You can change this value of 120 if you need more time or don't need as much time to accomplish the time change.
The flow of the TIMECHNG REXX is as follows. First, it will create a list of the all the currently active TOD rules and then disable them. Dynamic TOD rules* are also disabled. It will wait for the time change to occur during the maximum time set by the maxsecs variable. Then, the saved list of TOD rules will be re-enabled. Dynamic TOD rules are not re-enabled.
It is expected that the OSF servers will not be very busy so that the TIMECHNG REXX will get executed in a timely manner. Both the rule and the OPS/REXX are well documented in their respective libraries.
The new dates set in 2014 for beginning and ending daylight saving time affect OPS/MVS the same way as previous time changes. TOD rules need to be taken into consideration. Once the time changes, you need to be aware that any TOD rules that kicked off during the fallback time will run again. Similarly, any TOD rules that would have been missed during a spring forward time will be bypassed. If you previously used the TIMECHNG rule/rexx, you will have to update the GLOBAL0.TIMECHNG variable with the new dates.
*A dynamic TOD rule is created within another rule (usually a MSG rule). Its purpose is to create a subsequent TOD event for the rule being fired. For example, a dynamic TOD rule is
embedded within a MSG rule that will fire 'x time' after a given message:
REGION = MSG.JOBNAME /* GET THE REGION NAME OF MESSAGE */
/* Queue the text of the dynamic TOD rule to the EDQ */
queue ")TOD *+30 MINS "
Note: See AOF Rules User Guide for Dynamic TOD rule examples if needed.
Feedback
