When the z/OS system clock is set back, such as for 1 hour for Daylight Saving Time, you are advised to use this new function to automatically re-synchronize the clock in your CICS regions with the z/OS system clock. Without this, if your CICS Transaction Server for z/OS (CICS TS) regions run applications that do EXEC CICS STARTs or EXEC CICS DELAYs or EXEC CICS POSTs that specify a TIME (rather than an INTERVAL), and that time is calculated from EIBTIME plus some amount of time, then those STARTs and DELAYs and POSTs will expire immediately if the CICS time does not match the z/OS time. This can cause various problems like application loops and excessive SMF data recording that can cause the CICS region to become unresponsive.
Synchronize the CICS time with the z/OS time immediately whenever you alter the system date or time-of-day in the MVS TOD clock while a CICS region is running. APARs PM61466 (4.2), PM52109 (4.1), and PM52172 (3.2) add a new IMMEDIATE option to the AUTORESETTIME System Initialization Parameter (SIT). If you do not have a process in place to guarantee that a manual CEMT PERFORM RESET or EXEC CICS PERFORM RESETTIME command will be done immediately after altering the MVS TOD clock, then apply the PTF for your release of CICS below and set AUTORESETTIME=IMMEDIATE to pick up the new functionality and automatically synchronize the CICS time with the z/OS time:
- CICS TS 4.2 - PTF UK78430 for APAR PM61466
- CICS TS 4.1 - PTF UK77263 for APAR PM52109
- CICS TS 3.2 - PTF UK78322 for APAR PM52172
If you do not code AUTORESETTIME=IMMEDIATE and the z/OS time is changed, the CICS time stays the same (unless you reset it manually with CEMT PERFORM RESET or EXEC CICS PERFORM RESETTIME). If an application does an EXEC CICS START, an EXEC CICS DELAY, or an EXEC CICS POST command with a specific TIME that is calculated from the EIBTIME, CICS Interval Control might use the wrong time. For a START, if the z/OS time is set back 1 hour, but the CICS time is not reset, the task might start immediately. For example, if you have an application that does a START with a TIME that is about 1 minute into the future from the z/OS time perspective, that TIME is about 59 minutes into the past from the CICS perspective (since no PERFORM RESET has been done yet), so the task starts immediately. Depending on your applications, this could continue over and over, causing a loop that could lead to problems like excessive SMF110 records being written or a WAIT101. If the z/OS time is set forward 1 hour, tasks might not start until the TIME specified plus 1 hour.
If you use a product like BMC Mainview for CICS or use the EIBTIME plus some amount of time to repeatedly set a specific TIME on a START, DELAY, or POST, you need to enable the new option on the AUTORESETTIME startup system initialization table (SIT) parameter by specifying AUTORESETTIME=IMMEDIATE.
The APARs mentioned above add the IMMEDIATE option to the AUTORESETTIME parameter, but the APARs do not change the default. This is why you must specify AUTORESETTIME=IMMEDIATE if you do not issue a manual PERFORM RESET right after you change the z/OS time. The CICS TS product documentation has been updated to list the IMMEDIATE option:
CICS issues a PERFORM RESET command to synchronize the CICS time-of-day with the system time-of-day if, at the next task attach, the CICS time-of-day differs from the system time-of-day.
For CICS TS V5.1 (and later), the default is AUTORESETTIME=IMMEDIATE. No APARs are required for CICS TS 5.1 (and later) to enable the SIT parameter.
CICS/TS CICS TS CICS Transaction Server