PI30689: QMGR HIGH STORAGE USAGE WITH MESSAGE CSQY222E WHEN USING A SHARED QUEUE WITH MQGET BROWSE FOLLOWED BY A DESTRUCTIVE MQGET

Obtain the fix for this APAR.

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 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.