Setting up DFSMSrmm common time support

Before DFSMSrmm common time support (UTC), also known as GMT, is enabled, all dates and times are stored in the DFSMSrmm control data set in local time. When the control data set is shared, and the sharing systems are set to run in different time zones, the local dates and times in the control data set could be from any of your systems. When you display information or extract records, you need to be aware of how the records were created, on which system, and where they might have been updated in order to interpret the dates and times shown. The same consideration also applies for records created or updated prior to enabling common time support because DFSMSrmm assumes they are times local to the system running the DFSMSrmm subsystem and converts the values based on that assumption.

When you enable common time support, DFSMSrmm maintains the records in the control data set in common time. Most date and time fields are paired together to enable an accurate conversion to and from common time and between different time zones. In some cases, DFSMSrmm has date fields in control data set records, and there is no associated time field. For these date fields, DFSMSrmm uses an internal algorithm that approximates conversion between time zones based on the time zone offsets involved.

Attention: Using the SET system command with either the DATE or the TIME keyword, or both, or replying to message IEA888A to run the system on future or past dates can affect the way that DFSMSrmm calculates local times. In order to get the correct results from DFSMSrmm processing when you need to test with future or past dates, you should alter the TOD clock and keep the time zone offset as before.

To enable common time support, perform these tasks:

Ensure all systems in the RMMplex have toleration maintenance installed or are at the current z/OS release, and all applications dependent on the correct date and time information from DFSMSrmm are updated to support the new time zone support if required. DFSMSrmm subcommand output remains in local time, so most applications do not need to change unless they are to exploit the availability of the time zone offset.
Ensure the system time of day (TOD) clock is set to GMT on all systems in the RMMplex. It is common practice for the system to use local time based either on the TIMEZONE value in the CLOCKxx member of parmlib or from an external time source.
Run the EDGUTIL utility with UPDATE with the UTC(YES) operand on the CONTROL statement of the SYSIN file to enable common time support. See Creating or updating the control data set control record.

When common time support is enabled, any newly recorded dates and times are stored in common time and any existing records are converted to common time as they are updated by DFSMSrmm processing. Note: You will continue to see dates and times in local time because DFSMSrmm converts from common time to your local time.

When you use TSO subcommands in batch TMP or in native TSO, the TSO subcommands return data in your local time. It is important to specify dates and times as local time values when using subcommands in this environment.

For REXX variables and the DFSMSrmm ISPF dialog, you have the option of returning the date in any selected time zone so that you can, when needed, view data in times local to other systems managed by DFSMSrmm.

For the REXX environment, you can optionally set SYSAUTH.EDGTZ to your selected time zone offset so that subcommands return dates and times in your selected time zone. You can also include the TZ operand on ADD and CHANGE subcommands, when required, to indicate the time zone for dates and times specified on the subcommand.
For ISPF, the DFSMSrmm dialog has the ability for each user to select their own time zone value or run using the existing systems local time. The dialog exploits the SYSAUTH.EDGTZ setting and the TZ subcommand operand to make use of different time zones simple and straightforward for the user. The user operates completely in their selected time zone when reading returned data and when making changes to DFSMSrmm information. You can also change the setting during an ISPF session to select a new value for the next dialog interactions.

The DFSMSrmm application programming interface always returns values in local time. In addition, a SFI indicates the time zone offset used so that any application dependent either on the SFI or XML values can make its own time conversions based on the time zone offset.

The report extract data set contains date and time values in the local time of the running system. The extract header record includes a field that lists the time zone offset.

Use the RMM LISTCONTROL CNTL subcommand or the CONTROL dialog to see whether DFSMSrmm common time support is enabled.