A fix is available
APAR status
Closed as program error.
Error description
Customer has a QSG where member CSQ1 is active, and member CSQ2 is dormant. There is an XA client which is issuing an XA Recover. As the Qmanager is in a queue-sharing group it needs to find indoubt URs from all queue-managers in the group. As CSQ2 is not active, CSQ1 does this by reading the logs of CSQ2, which results in CSQ2's BSDS being dynamically allocated etc. CSQ1 then returns a number of URIDs for the XA Recover. However, the number of indoubt URs exceeds the size of the buffer given on the XA Recover (15 in this case). The XA Recover is then issued again to obtain the remaining indoubt URs. However, the queue-manager returns the same set of URIDs. This then results in the high CPU and CSQ2's BSDS etc being continually allocated/deallocated as the XA Recover is issued over and over by the client. . Additional keywords: performance loop looping
Local fix
n/a
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 8 * * Release 0 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: High CPU and/or IO when a transactional * * client issues xa_recover at the qsg * * scope and there are more indoubt XID's * * than will fit in the buffer provided by * * the client. * * Depending on the state of the other * * queue managers in the qsg, message * * IGD104I may also be written to JESYSMSG * * repeatedly. * **************************************************************** * RECOMMENDATION: * **************************************************************** A transaction client connected to a queue manager with GROUPUR enabled using the qsg name and then issued xa_recover with the TMSTARTRSCAN flag set to get a list of indoubt XIDs. CSQMXARH detected that the client was connected at qsg scope and called CSQMCIGI to get a list of indoubt XIDs for all queue managers in the QSG, before copying the XIDs back to the client's buffer, until the buffer was full. The client processed the XIDs in the buffer and then reissued xa_recover without TMSTARTRSCAN to get the next batch of XIDs. However, CSQMXARH incorrectly determined that this was not a continuation of the earlier scan and called CSQMCIGI again before returning the same XIDs as the previous call. This led to the client continually reissuing the xa_recover call and receiving the same XIDs over and over. Each time CSQMCIGI is called, the BSDS for inactive queue managers was allocated and deallocated, leading to the repeated IGD104I messages in JESYSMSG.
Problem conclusion
CSQMXARH is changed to correctly continue the scan from the next XID to be returned. 000Y CSQMXARH
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI64757
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
2016-06-24
Closed date
2016-06-29
Last modified date
2016-08-02
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI39035
Modules/Macros
CSQMXARH
Fix information
Fixed component name
WMQ Z/OS 8
Fixed component ID
5655W9700
Applicable component levels
R000 PSY UI39035
UP16/07/28 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.
[{"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:
02 August 2016