A fix is available
APAR status
Closed as program error.
Error description
The high CPU usage is due to a tight loop in CSQXBPQY. You can see from the dump that the loop is in code which is attempting to run the chain of active storage buffers for the current dispatcher. However, the pointer to the current buffer being processed is on the free buffer chain. . The issue is caused by a buffer being moved to the free chain by another TCB while it was the current buffer being examined on this dispatcher. The result of this is that the CSQXBPQY starts processing the free chain rather than the active chain, and so never reaches the expected end of chain value. . Once this process is looping, all other channels running on the same dispatcher are unable to run. Therefore this issue can effect other other workload impact. . In the SYSTRACE for the CHIN, you will see the following: Note: There will be many EXT 1005. In the DUMP that was looked at, there were 936 "EXT 1005". . DSP 00000000_3D6075DE 00000000 477E1338 477E23CC 0 CSQXBPQY UK73196 + x'746' in CSQXBPQY+0 07850000 80000000 EXT 1005 00000000_3D607610 00001005 0 CSQXBPQY UK73196 + x'778' in CSQXBPQY+0 07851000 80000000 0 EXT 1005 00000000_3D6075DA 00001005 0 CSQXBPQY UK73196 + x'742' in CSQXBPQY+0 07850000 80000000 0 DSP 00000000_3D6075DA 00000000 477E1338 477E23CC 0 CSQXBPQY UK73196 + x'742' in CSQXBPQY+0 07850000 80000000 EXT 1005 00000000_3D6075DA 00001005 0 CSQXBPQY UK73196 + x'742' in CSQXBPQY+0
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 0 Modification 1 and Release 1 * * Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: High CPU caused by a loop in module * * CSQXBPQY in the channel initiator * * address space. * **************************************************************** * RECOMMENDATION: * **************************************************************** Under rare circumstances, when a buffer is being allocated and the code is scanning the chain of available buffers, another task may manipulate the current entry moving it to from the free to the active chain. This prevents the original scan from detecting the end of the list and the code to scan for an available buffer will loop.
Problem conclusion
Buffer query code in CSQXBPQY will now take a lock on the pool of buffers when scanning the chain to prevent an entry from moving while being processed. 010Y 100Y CSQXBPQY
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PM92253
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
010
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2013-07-02
Closed date
2013-07-31
Last modified date
2013-10-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK96303 UK96304
Modules/Macros
CSQXBPQY
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
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":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
04 October 2013