PI65901: 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 IBM MQ for z/OS Version 9 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:                                              *
  * none                                                         *
  ****************************************************************
  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.
  

Temporary fix

Comments

APAR Information

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

  PI62682

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

  UI41028

Modules/Macros

• CSQIRECP CSQMCPRH CSQMCSTR
  

Fix information

• Fixed component name

  MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R000 PSY UI41028

     UP16/10/14 P F610 ¢

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.