A fix is available
APAR status
Closed as program error.
Error description
The basic problem is that this region went SOS for UDSA because UDSA is fragmented so badly. But then the CICS region got stuck there because the tasks started needing 1 4K page of below-the-line kernel stacks (KESTK24E) for various things but CDSA is also totally out of pages. So the tasks holding all of the UDSA couldn't move because they couldn't get below-the-line stack storage. But then they have DTIMOUT, so these tasks started getting abend AKEG after hanging for 1 minute. Then that made the tasks want to put out a message (like DFHPG0001) to report that problem. But one of the modules for putting out a message also needs an SMODE 24 stack. And so it hangs again and AKEG's again 60 seconds later. This repeats itself as the task percolates the slow-moving AKEG's back from stack to stack. Eventually one of the tasks percolated an AKEG back to the DFHKETA stack level. But then there was an abend0C4 in DFHKETA (addressed in APAR PK39507 ) because it assumes that there will be a prior stack. Since there is no stack level to percolate that 0C4 error back to, DFHKERPC decides to bring CICS down with a KTCB_PERCOLATE_ERROR. But then the default QR KTCB task tries to call DFHAPDM to terminate domain, but that module needs a SMODE 24 stack and so the QR TCB just goes away and CICS is left there to hang.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All. * **************************************************************** * PROBLEM DESCRIPTION: CICS went SOS in the UDSA and then * * hung. * **************************************************************** * RECOMMENDATION: * **************************************************************** In the reported problem, a CICS system was short of below the line storage and eventually hung. . UDSA was badly fragmented but various tasks were requesting 4k pages of below the line kernel stack storage (KESTK24E) which was unable to be satisfied. The CDSA was fully allocated so below the line storage had been exhausted for CICS use. The tasks eventually timed out with AKEG abends but in doing so, CICS attempted to issue DFHPG0001 messages to report the problem. To do this, CICS module DFHKETI required below the line stack storage and CICS went into a permanent SOS condition. Keywords: short-on-storage msgDFHSM0131 DFHSM0131 SM0131 0131
Problem conclusion
DFHKETI now has SMODE 31 specified so that it will not require storage from the KESTK24E subpool.
Temporary fix
********* * HIPER * ********* FIX AVAILABLE BY PTF ONLY
Comments
APAR Information
APAR number
PK44403
Reported component name
CICSTS 3.X Z/OS
Reported component ID
5655M1500
Reported release
400
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt
Submitted date
2007-05-03
Closed date
2007-06-07
Last modified date
2007-07-09
APAR is sysrouted FROM one or more of the following:
PK39513
APAR is sysrouted TO one or more of the following:
UK25848 PK48557
Modules/Macros
DFHKETI
Fix information
Fixed component name
CICSTS 3.X Z/OS
Fixed component ID
5655M1500
Applicable component levels
R400 PSY UK25848
UP07/06/12 P F706
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.1","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.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
09 July 2007