A fix is available
APAR status
Closed as program error.
Error description
ABEND 5C6 - 00C511CE S=00000C17 occurred due to Admin Structure full: 16:04:18.53 IEA794I SVC DUMP HAS CAPTURED: 365 DUMPID=010 REQUESTED BY JOB (JOB1 ) DUMP TITLE=CSQ1,ABN=5C6-00C511CE,S=00000C17,C=R3600.701. CFM -CSQEWUOW,M=CSQGFRCV,LOC=CSQELPLM.CSQEWUOW+00001250 And then issued STOP Server command, SVCDUMP, TDUMP and CEEDUMP. SLIP TRAP C=0C4 with QMGR region was matched. 16:07:45.54 IEA794I SVC DUMP HAS CAPTURED: 440 DUMPID=012 REQUESTED BY JOB (JOB1 ) DUMP TITLE=SLIP DUMP ID=C0C4 16:07:57.94 IEA794I SVC DUMP HAS CAPTURED: 455 DUMPID=013 REQUESTED BY JOB (JOB1 ) DUMP TITLE=COMPON=WEBSPHERE Z/OS,COMPID=5655N0200, ISSUER=BBORMCDP,ERRNO=C9C20008 After ABEND0C4, AppServer still hung. Finally AppServer was terminated by FORCE command. After that, tried to stop QMGR, but it went into hang. The codepath leads to the 0C4 in CSQWVCOL, which occurs due to recovery for the 5C6 abend incorrectly leaving the address of an SKB in the queue manager address space set in the EB if there was no previous SKB in the application address space associated with the EB. Additional Symptom(s) Search Keyword(s):
Local fix
n/a
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 0 Modification 1 and Release 1 * * Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: Abend 0C4 occurs in CSQWVCOL when * * WebSphere Application Server issues MQI * * requests using a private context, after * * an earlier attempt to commit work done * * under the same context abended in MQ's * * RRS prepare exit. * **************************************************************** * RECOMMENDATION: * **************************************************************** Following an abend in MQ's RRS prepare exit (for example, due to the admin structure filling), CSQ3RRXF is called to recover from the abend. CSQ3RRXF failed to correctly restore the SKB associated with the context ACE, instead leaving EBSKB pointing to an SKB in the queue manager address space. The recoverable work under the context was successfully backed out, and WebSphere Application Server attempted to issue further MQI requests using the same context (for example MQBACK when being stopped). CSQMCPRH detected that EBSKB was still set, and assuming it pointed to a valid SKB in the application address space, did not allocate an SKB in the application address space. When it subsequently attempted to call CSQWVCOL, CSQWVCOL attempted to get stack storage using the SKB, however as the SKB was in the wrong address space this led to an attempt to access invalid storage and the reported 0C4.
Problem conclusion
CSQ3RRXF is changed to correctly restore EBSKB following an abend in MQ's RRS exits. 010Y 100Y CSQARIB CSQ3RRXF
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI28079
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
010
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2014-10-21
Closed date
2014-11-26
Last modified date
2015-02-03
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
PI29147 UI23441 UI23442
Modules/Macros
CSQARIB CSQ3RRXF
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
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":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
03 February 2015