There are two categories of common scenarios, based on setting the UTC adjustment factor forward or backward, regardless of method (via Sysplex Timer settings, or z/OS SET CLOCK command).
Considerations and Possible Procedures Regarding DB2 and ASG-TMON for DB2 when Changing the UTC (formerly known as GMT) Adjustment Factor
Setting the UTC adjustment factor forward:
Case 1: I cannot recycle TMON for DB2.
Case 2: I can recycle TMON for DB2.
Data Considerations:
Data logged by TMON for DB2 is managed by time stamps obtained via STCK (which is not adjusted for UTC). The UTC adjustment factor is calculated at monitor startup and is used for data calculations as well as managing logged records. Therefore the integrity and usability of logged data is questionable if you do not cycle the monitor (calculations made using STCK times may result in errant data, including logged records, exceptions, filtering).
Setting the UTC adjustment factor backward:
Data Considerations: None
Case 1: I cannot recycle TMON for DB2.
Case 2: I can recycle TMON for DB2.
Data Considerations:
Data logged by TMON for DB2 is managed by time stamps obtained via STCK (which is not adjusted for UTC). The UTC adjustment factor is calculated at monitor startup and is used for data calculations as well as managing logged records. Therefore the data logged during the overlapping (adjustment) time will be unreliable or lost if you cannot cycle the monitor:
Lost data. Time stamps are crucial to the system clock (STCK) fields used for keying data records. If records are logged with overlapping time stamps, the data in the TMON for DB2 collection files may become inaccessible (some displays display data based on time stamps). Setting the system clock back without allowing TMON for DB2 to recalculate the UTC adjustment can cause new records to be logged with time stamps earlier than those for existing records and errant data calculations to occur for derived fields. The data files then may become unusable and must be reinitialized, at which point all their records are lost.
Unreliable data. TMON for DB2 may report twice on the same time period and data may be invalid. Although you may be able to access and report on the data, reports for some time periods would combine data from two different intervals into one set of summary statistics. In addition, since the UTC adjustment is no longer correct, much of the derived data may be invalid until the monitor is cycled (calculations made using STCK times will result in errant data, including logged records, exceptions, filtering).
For more information on Adjusting the System Clock, please review the Release Notes
Data Considerations (none if monitor started after the time adjustment period has elapsed):
Data logged by TMON for DB2 is managed by time stamps obtained via STCK (which is not adjusted for UTC). The UTC adjustment factor is calculated at monitor startup and is used for data calculations as well as managing logged records. Although the UTC adjustment may be correct, data logged during the overlapping (adjustment) time will be unreliable or lost if you do not wait for the time period adjusted before restarting the monitor:
Lost data. Time stamps are crucial to the system clock (STCK) fields used for keying data records. If records are logged with overlapping time stamps, the data in the TMON for DB2 collection files may become inaccessible (some displays display data based on time stamps). Setting the system clock back can cause new records to be logged with time stamps earlier than those for existing records. The data files then may be unusable and must be reinitialized, at which point all their records are lost.
Unreliable data. TMON for DB2 may report twice on the same time period. Although you may be able to access and report on the data, reports for some time periods would combine data from two different intervals into one set of summary statistics.