A fix is available
APAR status
Closed as program error.
Error description
Error DescriptionÏ The 0C4s in CSQXSGET are the follow-on problems from the abends in the WSAS address space and are occuring during clean-up processing. An async consume TCB is going through end-of-task processing. CSQMEOTC has been invoked and has invoked CSQADELT to delete conversion tables etc.. Before invoking CSQADELT, CSQMEOTC sets R13 to the address of CSQBSRV's working storage in the BLOA (CSQBSRV_WS). The prolog in CSQXSGET (CSQVLSM9) detects that there is a stack header block (XSTKH; indicated by 'CSQA' in the first word of the save-area) and addresses the stack header (16 bytes prior to the save-area). It then picks up the address of the stack parm block, XSPM. However, the address is in another BLOA which has been released (due to the TCB which attached the async consume TCB ending), hence the 0C4 occurs.
Local fix
Local FixÏ none
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: The application address space abends * * with S0C4-00000011 when the using * * async-consume. * * This problem can occur when async- * * consume is not used properly (i.e. * * stopping the async-consume thread * * and the disconnect step is not done) * * or an abend occurs in the application * * address space whilst an async-consume * * thread is active. * * This problem can occur when WebSphere * * Application Server is abending. * **************************************************************** * RECOMMENDATION: * **************************************************************** A control thread is started and connects to MQ. As part of this a BLOA control block is allocated, containing a space for stack storage. When the control thread starts the async-consume thread with MQCTL-MQOP_START, a new BLOA control block is allocated for the async-consume thread. However this one contains a pointer back to the control threads BLOA, in order to be able to use it's connection when doing MQAPI calls. It also shares the control threads BLOA's stack storage. In the case where the async-consume thread is left running after the control thread has gone through end of task processing, for instance if the application address space is abending, the async-consume thread is left with pointers to the control threads BLOA, which has now been freed. Any attempt to access it will cause an 0C4.
Problem conclusion
The code was changed to correctly terminate the async consume thread with abend 5C6-00C20009 when the control thread goes through end of task processing whilst the async consume thread is still active. 010Y 100Y CSQBDSC CSQBSRV CSQMDALL CSQMEOTC
Temporary fix
Comments
APAR Information
APAR number
PM70109
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
010
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2012-08-02
Closed date
2012-11-27
Last modified date
2013-02-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK83774 UK83775
Modules/Macros
CSQBDSC CSQBSRV CSQMDALL CSQMEOTC
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:
04 February 2013