A fix is available
APAR status
Closed as program error.
Error description
Customer observed high usage of SSD blocks in ESQA associated with WMB. It occurs when a thread invokes CSQMLOCT to locate an data-conversion table, and CSQMLOCT finds that there is another thread already trying to load the data-conversion table (in this case the conversion table is for 5123 to/from 1047, which does not actually exist). CSQMLOCT allocates a ROB to wait for the data-conversion table to be loaded, and then suspends on the ROB, which results in CSQVSRX allocating a pause-element (SSD). However, after CSQMLOCT has been resumed it does not release the ROB, which results in the ROB storage and the pause-element token being leaked. . Additional keywords: SP245 KEY0 Subpool 245 Key 0
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 8 * * Release 0 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: Leak of ROB control blocks and their * * associated Pause Element's when the * * queue manager loads conversion tables. * * For long running applications, the * * leak can lead to a build of SSD control * * blocks in ESQA, leading to shortages of * * common storage. * * * * In some cases abend 5C6-00E50079 can * * also occur in CSQMCNVT. * **************************************************************** * RECOMMENDATION: * **************************************************************** When an application attempts a conversion for which no suitable conversion table is loaded, it queues a request to the conversion task to load the table. If multiple applications require the same table, only one request is queued, and the other tasks are suspended until the first task resumes them, however the ROBs used to suspend these additional tasks are not freed, leading to the ROBs being leaked. These ROB's also have associated Pause Elements, and consequently these are also not freed, leading to a build up of SSD control blocks in common storage if the application is long running. If STOP QMGR MODE(FORCE) is issued while a task is suspended waiting for a conversion table to be loaded, a timing window exists where a ROB can be freed prior to being resumed, leading to abend 5C6-00E50079 in CSQMCNVT.
Problem conclusion
CSQMLOCT is changed to correctly free the ROBs associated with additional tasks waiting for a table to be loaded, and to prevent the ROB used by the initial task being freed prior to being resumed during STOP QMGR MODE(FORCE) processing. MQMSGPROP/K 000Y CSQALOCT CSQMCNVT CSQMLOCT CSQXLOCT
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI37390
Reported component name
WMQ Z/OS 8
Reported component ID
5655W9700
Reported release
000
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2015-03-19
Closed date
2015-04-27
Last modified date
2015-07-01
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI27084
Modules/Macros
CSQALOCT CSQMCNVT CSQMLOCT CSQXLOCT
Fix information
Fixed component name
WMQ Z/OS 8
Fixed component ID
5655W9700
Applicable component levels
R000 PSY UI27084
UP15/06/03 P F506 ¢
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.
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
01 July 2015