PI60172: STORAGE LEAK CAUSING HIGH CPU IN CHIN ASID DUE TO FRAGEMENTION.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• CHIN address space (asid) consuming CPU in storage
  obtain processing for subpool 0 key 8.  The storage in
  subpool  0 key 8 was fragmented, many DQEs and FQEs
  in the VSM report.
  The cause of the fragmentation appears to be a
  leak of XSCS control blocks.
  These represent shared channel status, and you
  can see in the trace that they are not always
  being freed properly for SVRCONN channels.
  
  The control blocks are small, so the storage
  leak itself may not cause shortage of storage
  issues. However, the fragmentation results in the
  increased CPU consumption seen by the customer.
  
  .
  
  Since the local lock is held for these storage
  requests, you can also see some contention for
  that lock in the chinit. This can contribute
  to the issues with messages backing up on xmit
  queue and not being committed.
  
  
  Additional Symptom(s) Search Keyword(s):
  Since the local lock is held for these storage
  requests, you can also see some contention for
  that lock in the chinit. This can contribute
  to the issues with messages backing up on xmit
  queue and not being committed.
  .
  SP0 KEY8 LOCL
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 8 *
  *                 Release 0 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: High CPU usage in the channel initiator *
  *                      address space due to storage leak of    *
  *                      XSCS control blocks when using SVRCONN  *
  *                      channels with the SHARECNV channel      *
  *                      attribute greater than zero and         *
  *                      connected to an INDISP(GROUP) shared    *
  *                      listener. Key 8, SubPool 0 storage      *
  *                      shows many FQEs and DQEs containing     *
  *                      the XSCS eyecatcher.                    *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  When using SVRCONN with a non-zero SHARECNV channel attribute,
  and connected to an INDISP(GROUP) shared listener; upon channel
  termination, an internal XSCS control block may not be correctly
  freed. Over time, the accumulation of these small blocks may
  cause additional overhead when allocating or freeing storage.
  This may manifest itself as increased CPU consumption in the
  channel initiator address space.
  

Problem conclusion

• Processing has been amended to ensure all XSCS blocks are
  freed.
  000Y
  CSQXRMSS
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UI38720

Modules/Macros

• CSQXRMSS
  

Fix information

• Fixed component name

  WMQ Z/OS 8

• Fixed component ID

  5655W9700

Applicable component levels

• R000 PSY UI38720

     UP16/07/06 P F607

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.