PI62682: WMQ HIGH ECSA MEMORY CONSUMPTION DUE TO LARGE NUMBER OF CLIENT CONNECTION INSTANCES

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• High ECSA memory usage is due to the large number of instances
  of client channel AA.TO.BBBBB. The dump shows thousands of
  instances of the channel.
  ECSA control blocks are still in-use. The ECSA control blocks
  are not being released on the free-chain for the CHIN.
  

Local fix

• 1. Setting MAXINST on the SVRCONN and SHARECNV=1 can be used to
   put a limit on the number of conversations, and therefore ECSA,
   being used by this channel (note that each conversation has its
   own set of control blocks from ECSA).
  .
  2. Recycle the CHIN (the queue-manager does not need to be
   recycled).
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 8 *
  *                 Release 0 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Following a peak in channel connections *
  *                      SP231 ECSA usage for the queue manager  *
  *                      remains high until the channel          *
  *                      initiator is restarted.                 *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  A peak in channel connections caused an increase in the number
  of ACEs (and related control blocks) required and resulted in
  subpool 231 ECSA usage by the queue manager growing to
  accomodate these control blocks.
  When the channels ended, the ACEs were added to a free chain in
  the MCLB associated with the channel initiator address space.
  These ACEs are available for reuse by future ACE requests from
  the channel initiator, however the storage cannot be used to
  satisfy ACE requests from other address spaces connected to the
  queue manager.
  In addition, because the ACE storage remains allocated, it is
  not eligible to be freed by storage contraction processing.
  The ECSA storage for these ACEs (and related control blocks)
  remains allocated and reserved for use by the channel initiator
  address space until the channel initiator is stopped.
  

Problem conclusion

• CSQMCPRH is changed to limit the number of ACEs that can be
  added to the MCLB free chain. In normal operation it is expected
  that ACEs will continue to use the free chain, however following
  a peak in connections ACEs that are no longer required will be
  deallocated rather than added to the free chain when the free
  chain has reached the limit. ACEs deallocated in this way will
  be eligible for reuse by any address space connected to the
  queue manager, not just the channel initiator, and the storage
  containing the ACEs will be eligible for storage contraction
  processing.
  000Y
  CSQIRECP
  CSQMCPRH
  CSQMCSTR
  

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:

  PI65901 UI39748

Modules/Macros

• CSQIRECP CSQMCPRH CSQMCSTR
  

Fix information

• Fixed component name

  WMQ Z/OS 8

• Fixed component ID

  5655W9700

Applicable component levels

• R000 PSY UI39748

     UP16/08/25 P F608 ¢

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.