Review this document when changing the time on a system where OPS/MVS is installed.
The following is the recommended procedure for changing the time with 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:
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
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.