A fix is available
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 number
PI65901
Reported component name
MQ Z/OS V9
Reported component ID
5655MQ900
Reported release
000
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-07-14
Closed date
2016-09-23
Last modified date
2016-11-02
APAR is sysrouted FROM one or more of the following:
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.
[{"Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.0"}]
Document Information
Modified date:
10 September 2020