A fix is available
APAR status
Closed as program error.
Error description
The z/OS system hung, and an IPL was required. A standalone dump showed that many jobs, including *MASTER*, DMPSRV, CONSOLE, OMVS, JES2, and user jobs such as brokers, were in an ENQ wait for resource NAME=MAJOR=NETMAGDB (a resource for a 3rd party product). The ENQ was held by a broker job that was going through MEMTERM processing due to an ABENDS40D. . The dump of the *MASTER* address space showed that the TCB for memterm processing for the ENQ owner was waiting in MQ. SYSTRACE of the *MASTER* address space showed that the MEMTERM TCB was in a loop of WAIT, STORAGE RELEASE, and STORAGE OBTAIN every second. The WAIT PSW was in CSQ3RRSX+x'185C' (UK94940) in routine SETDIE. It was called from EBACTL_RETRY2 to wait for 1 second at a time for EBACTL to be turned on for a thread for the broker job. The TCB for that thread was alrady gone. . The MQ change team found that the code added by PM75418 can cause memterm processing to hang indefinitely. Presumably the fact that memterm processing hung prevented subsequent memterm processing by z/OS from releasing the NETMAGDB ENQ. . Additional Symptom(s) Search Keyword(s): hang MQ NETMAGDB looping ABEND40D S40D ABEND 40D SAD
Local fix
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: After applying the PTF for PM75418, * * UK91873 / UK91874, MEMTERM processing * * for an address space connected to MQ is * * hanging. * * The LPAR may potentially become * * unresponsive. * **************************************************************** * RECOMMENDATION: * **************************************************************** The connected address space has experienced abends, and has then been MEMTERM'ed with S40D. During MEMTERM processing, context services has invoked CSQ3RRSX for END_CONTEXT processing. The ACE associated with the context has EBACTL set off, indicating that it is in MQ code. CSQ3RRSX therefore waits for EBACTL to be set back on. However, EBACTL will never get set back on as the address space that it was running under has been MEMTERM'ed.
Problem conclusion
The code was changed to not wait for EBACTL to be turned back on if the connected address space has been MEMTERM'ed, preventing the hang from occurring. 010Y 100Y CSQARIB CSQMCLMT CSQMCTXE CSQMCTXS CSQ3AAES CSQ3AMT3 CSQ3RRSF CSQ3RRSI CSQ3RRSM CSQ3RRSR CSQ3RRSX CSQ3RRXF CSQ5CONN CSQ5MONR
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI20391
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
010
Status
CLOSED PER
PE
YesPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2014-06-19
Closed date
2014-07-10
Last modified date
2014-08-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI19493 UI19494
Modules/Macros
CSQARIB CSQMCLMT CSQMCTXE CSQMCTXS CSQ3AAES CSQ3AMT3 CSQ3RRSF CSQ3RRSI CSQ3RRSM CSQ3RRSR CSQ3RRSX CSQ3RRXF CSQ5CONN CSQ5MONR
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 August 2014