A fix is available
APAR status
Closed as program error.
Error description
Immediately following the setting backward by 1 hour of the z/OS system clock (in support of a change from Daylight Saving Time to Standard Time) EXEC CICS START commands that specify an explicit time (using the TIME parameter) that is less than 1 hour into the future beyond EIBTIME, will start immediately. . Here is a trace entry that shows this happening: . START TRANSID('FIC2' AT X'800523E0') TIME(32500 AT X'298417D8') TASK-62996 TCB-QR /008F81A0 RET-80082436 TIME-04:24:10 4-0000 0032410C 0111310F E3D9D5F1 0062996C 0010 00000000 00000000 0000000E 06000000 . The above trace entry shows pieces of an AP E160 trace entry that is produced when Trace Component EI is set to level 1-2. It shows an EXEC CICS START command. Data Area 4 traces the EIB. The 1st word of that, 0032410C, is EIBTIME. This EIBTIME is 03:24:10. The TIME-04:24:10 in the 2nd line shows that at least part of CICS considers the time to be 04:24:10. And the TIME(32500) on the 1st line shows that the EXEC CICS START command is specifying a time of 03:25:00. . At time of this START command z/OS considered the local time to be 03:24:10 . But parts of CICS, since no EXEC CICS or CEMT PERFORM RESET has been done following the setting backwards of the system clock, think the local time is 04:24:10. So while the TIME parameter of 03:25:00 is in the future with respect to EIBTIME and, therefore, the application program, it is in the past with respect to part of CICS. That is why the START is actioned immediately. . Prior to some recent CICS APARs, in this interval between a setting backwards by 1 hour of the system clock, and an EXEC CICS or CEMT PERFORM RESET, EIBTIME would not contain the changed z/OS local time. Instead it would continue to be set by CICS as if the system clock change had not happened. So in the example above prior to the recent CICS APARs, even though the changed z/OS local time is 03:24:10, the trace entry time would be 4:24:10 and EIBTIME would be 4:24:10 and therefore the TIME specified on the START would be 4:25:00. . CICS/TS 3.2 APAR PK48346 changed CICS so that EIBTIME is updated with the up-to-the-second correct z/OS local time following an EXEC CICS ASKTIME. . CICS/TS 3.2 APAR PM26742 and CICS/TS 4.1 APAR PM26726 changed CICS so that EIBTIME is updated with the up-to-the-second correct z/OS local time from the beginning of the task, without an EXEC CICS ASKTIME having to be issued. . Let's say that at local time 2AM, the z/OS system clock is changed backwards so that the new local time is 1AM. Without PM26742 or PM26726 applied, at 1:59:59 (prior to the change) a new task's EIBTIME would be setup as 01:59:59. And then 2 seconds later (after the change and the new local time is 01:00:01), a new task's EIBTIME would be setup as 02:00:01. . But with either of those APARs applied, at 1:59:59 (prior to the change) a new task's EIBTIME would be setup as 01:59:59. And then 2 seconds later (after the change and the new local time is 01:00:01), a new task's EIBTIME would be setup as 01:00:01.
Local fix
Do CEMT PERFORM RESET as quickly as possible following the z/os sytem clock time change.
Problem summary
**************************************************************** * USERS AFFECTED: All. * **************************************************************** * PROBLEM DESCRIPTION: Tasks started by a START command where * * the START TIME is in the future start * * immediately. * **************************************************************** * RECOMMENDATION: * **************************************************************** In the reported problem, a daylight saving change ( clock back one hour ) was made to an MVS clock. However no PERFORM RESET was issued by a CICS task ( running on the same MVS ) to resync the MVS clock and the CICS clock held in CSA field CSATODP. The recommendation is this is done immediately. As a consequence, the CICS system became overloaded with work. A task obtained its initial time from EIBTIME. It then issued a START command to run itself again in one minutes time. EIBTIME is initialized by an MVS TIME macro within DFHAPIN and would have reflected the changed MVS time so the START command would have been for just under an hour in the past, ( rather than one minute ahead ). However, Interval Control ( DFHICP ) uses the CICS clock ( CSATODP ) and so did not reflect the change to the MVS time because no RESETTIME had been issued. As a consequence, the STARTED task started immediately and the process repeated itself. The task was a heavy user of statistics and caused a spike of work to SMF.
Problem conclusion
CICS task attach logic has been amended such that if a new AUTORESETTIME parameter of IMMEDIATE is coded then the CICS internal clock ( in CSATODP ) will get reset immediately when DFHAPIN detects a mismatch between the MVS and CSATODP times. The following documentation change will be made: The CICS Transaction Server for z/OS Version 3 Release 2 System Definition Guide (SC34-6813-04) will be updated, the description for AUTORESETTIME will have an additional option of IMMEDIATE added, as a consequence, it will now read as follows: . AUTORESETTIME The AUTORESETTIME parameter specifies the action CICS should take for automatic time changes. AUTORESETTIME= IMMEDIATE|NO|YES -- Valid values are as follows: IMMEDIATE CICS will issue 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. NO CICS issues message DFHAP1500 to indicate that a CEMT -- PERFORM RESET command is required to synchronize the CICS time-of-day with the system time-of-day. . YES CICS issues a PERFORM RESET command to synchronize the CICS time-of-day with the system time-of-day if, at the next local midnight, the CICS time-of-day differs from the system time-of-day by more than 30 minutes; for example, setting clocks forward or back to adjust for summer and winter time. . The CICS Transaction Server for z/OS Version 3 Release 2, Data Areas manual (GC34-6863-04 ) will be updated, as follows: The CSA will have 2 new fields added to byte CSAICIND thus: .... 1... CSAICIMM IMMEDIATE specified on AUTORESETTIME .... .1.. CSAICRIP Reset in progress Dsect TCADY ( the System TCA ) will have a new field added to byte TCAAPFLG thus: .... 1... TCATSUSP DFHAPIN suspend Dsect SIT ( System Initialization Table ) will have a new field added to byte SITMISC thus: ..1. .... SITICARI AUTORESETTIME=IMMEDIATE TEMPORARY FIX: ,
Temporary fix
FIX AVAILABLE BY PTF ONLY
Comments
APAR Information
APAR number
PM52172
Reported component name
CICSTS V3 Z/OS
Reported component ID
5655M1500
Reported release
500
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt
Submitted date
2011-11-15
Closed date
2012-04-27
Last modified date
2012-09-18
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK78322 PM73143
Modules/Macros
DFHAPIN DFHAPTIM DFHCSAD DFHCSAPS DFHPASY DFHPASYA DFHPASYM DFHPASYT DFHSIA1 DFHSIT DFHSIT$$ DFHSITPS DFHSIT6$ DFHTCA DFHTCAPS
GC34686304 | SC34681304 |
Fix information
Fixed component name
CICSTS V3 Z/OS
Fixed component ID
5655M1500
Applicable component levels
R500 PSY UK78322
UP12/05/05 P F205
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.2","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.2","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
18 September 2012