A fix is available
APAR status
Closed as program error.
Error description
You are running CICS Transaction Server 4.1 and notice the region is using 100% of the CPU. Transaction CEX2 was executing, over and over. We learned from the dump that the CICS clock was out of sync with the MVS clock. Looking at the message log we can see the MVS clock was set backwards by about 46 sesconds: . 00.00.00---- THURSDAY, 14 FEB 2013 ---- 00.00.00 +DFHIC0801 APPLID CICS time altered from 24.00.000 to 00.00.486 - date 14/02/13 . Because of this time change, and CICS not being in sync with the system time, the CEX2 transaction, that should run every 30 seconds, was now getting kicked off immediately, taking up all the CPU. . They had AUTORESETTIME=NO. AUTORESETTIME=yes or issuing a CEMT PERFORM RESET would have corrected the situation. But there is an option AUTORESETTIME=IMMEDIATE, which is not full proof. It requires a new task to be kicked off, in order to take effect. This APAR will address this odd case, where a new transaction does not get kicked off at midnight, when the immediate option is specified for AUTORESETTIME. . Additional Symptom(s) Search Keyword(s): KIXREVxxx
Local fix
issue CEMT PERFORM RESET
Problem summary
**************************************************************** * USERS AFFECTED: All. * **************************************************************** * PROBLEM DESCRIPTION: AUTORESETTIME=IMMEDIATE interpreted as * * YES in specific circumstances. * **************************************************************** * RECOMMENDATION: . * **************************************************************** The AUTORESETTIME=IMMEDIATE parameter will synchronize the CICS internal clock with the MVS clock after the latter has been altered. However, this only occurs if DFHAPIN is driven when a CICS user task is attached. It is quite usual to adjust the MVS clock backwards or forwards one hour consistent with daylight saving time but in the reported problem, the MVS clock was moved backwards circa 50s at just before MVS midnight. Had a CICS user task been attached then a full resync would have occurred to sync the CICS clock with the MVS clock. . DFHAPTIM, the Interval Control Midnight Task program ran at CICS midnight but this is a system task that doesn't drive DFHAPIN. DFHAPTIM contains code to sync the MVS and CICS clocks but a path exists where if it is driven within a 30 minute window either side of MVS midnight then it will do a DFHIC reset as if AUTORESETTIME=YES was coded. This will cause a DFHIC reset but the CICS internal clock is not synced with the MVS clock. This may have the unintended consequence for scheduled tasks whose Interval Control Elements ( ICE's ) expire in ( say ) 30 seconds in that they start immediately.
Problem conclusion
DFHAPTIM has been modified so that it will treat AUTORESETTIME=YES and AUTORESETTIME=IMMEDIATE as both requiring a full reset in this circumstance.
Temporary fix
********* * HIPER * ********* FIX AVAILABLE BY PTF ONLY
Comments
APAR Information
APAR number
PM83790
Reported component name
CICS TS Z/OS V4
Reported component ID
5655S9700
Reported release
600
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt
Submitted date
2013-02-27
Closed date
2013-07-03
Last modified date
2013-08-02
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
PM89639 UK95612 UK95613
Modules/Macros
DFHAPTIM
Fix information
Fixed component name
CICS TS Z/OS V4
Fixed component ID
5655S9700
Applicable component levels
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"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"4.1","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
29 October 2021