A fix is available
APAR status
Closed as program error.
Error description
WMQ for z/OS Ver.7.1.0 suffers a progressive increase of WMQ storage until message CSQY222E is issued. Dump obtained shows a high allocation in subpool 229, Key 7, with a high allocation for CFM Threads Ops and CFM Threads Qs: L PHB 7EE1FC08 CFM Thread Ops F RM(197) SP229 K7 Cl12 132032K L PHB 7EE1FC80 CFM Thread Qs F RM(197) SP229 K7 Cl12 154488K The problem occurs due to eTRQ (eTRQs) control blocks not being released when a shared queue is used.
Local fix
No Local Fix.
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 1 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: Storage leak of ETRO/ETRQ control * * blocks leads to increased storage usage * * in the queue manager address space. * * Over time the accumulation of leaked * * storage can lead to performance * * degradation or exhaustion, and could * * cause abnormal queue manager * * termination. * **************************************************************** * RECOMMENDATION: * **************************************************************** During the browse of a message on a shared queue with the MQGMO_LOCK option, a eTRO control block (trop) is created to represent the browse lock operation on the queue. If the application subsequently gets the browse locked message out of syncpoint, the trop is initially converted to a get trop, and removed from the browse lock chain. When the get operation completes and the message is returned, the trop should be deleted, however it is incorrectly convered back into a browse lock trop and added back to the browse lock chain for the ETRQ associated with the queue. This leads to both the eTRO and eTRQ being orphaned/leaked. Over time the number of orphaned eTRO/eTRQ control blocks will grow, leading to increased storage usage (as reported by CSQY221I), and eventually a short on storage (SOS) condition (as reported by CSQY222E).
Problem conclusion
CSQETHDP is changed to correctly delete the ETRO in this situation, preventing both the ETRO and ETRQ being orphaned. 100Y CSQESYNC CSQETHDP CSQE197N
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI30689
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
100
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2014-12-03
Closed date
2015-02-23
Last modified date
2015-05-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
PI35070 UI25362
Modules/Macros
CSQESYNC CSQETHDP CSQE197N
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
R100 PSY UI25362
UP15/04/17 P F504 ¢
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.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
04 May 2015