A fix is available
APAR status
Closed as program error.
Error description
High CPU in the CHIN job is observed. It started after a RESOLVE CHANNEL command was done for an indoubt cluster channel that had been receiving CSQX507E channel is in-doubt. A CHIN trace has repetitive entries: Entry 15:28:53.371106 rrxReadSync Entry 15:28:53.371107 CSQXSEM Semaphore Processing Exit 15:28:53.371107 CSQXSEM Semaphore Processing Entry 15:28:53.371108 CSQXSEM Semaphore Processing Exit 15:28:53.371109 CSQXSEM Semaphore Processing Entry 15:28:53.371109 MQGET Get Message Entry 15:28:53.371110 CSQXSRVR Service Requester Exit 15:28:53.371119 CSQXSRVR Service Requester Exit 15:28:53.371120 MQGET Get Message Entry 15:28:53.371121 MQGET Get Message Entry 15:28:53.371122 CSQXSRVR Service Requester Exit 15:28:53.371205 CSQXSRVR Service Requester Exit 15:28:53.371206 MQGET Get Message Exit 15:28:53.371207 rrxReadSync The MQGET is for SYSTEM.CHANNEL.SYNCQ. The records being returned alternate between two messages with the same cluster channel name but different transmission queue names. There is an issue with channel sync records and multiple cluster transmit queues if a REFRESH CLUSTER command is issued while the cluster sender channel is indoubt. This can result in multiple indoubt sync records on the SYSTEM.CHANNEL.SYNCQ with different transmit queues in the records. In this case, during the RESOLVE CHANNEL command, if the cluster channel definition has a different transmit queue than an indoubt sync record, a loop condition may occur when the SYNCQ is being read. Note that a REFRESH CLUSTER should be used in rare circumstances. Additional Symptom(s) Search Keyword(s): Performance CSQXRSYN
Local fix
If the loop occurs, a CSQ4SUTL utility may be provided that will help clear bad records from SYSTEM.CHANNEL.SYNCQ.
Problem summary
**************************************************************** * USERS AFFECTED: All users of IBM MQ for z/OS Version 9 * * Release 0 Modification 0 and Release 1 * * Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: Errors occur when using CSQUTIL to * * switch the transmit queue used by a * * CLUSSDR channel. These can include: * * - duplicate syncq records * * - loops when resolving indoubt clussdr * * channels * * - incorrect indoubt resolution for * * clussdr channels * **************************************************************** When CSQUTIL is used to issue the SWITCH CHANNEL command in order to make a pending xmitq switch for a cluster sender channel active, it causes the transmit queue name to be updated in sync records on SYSTEM.CHANNEL.SYNCQ, and in the channel initiators live copies of these records. However, when the channel is indoubt, the indoubt record on the sync queue is not updated, leading to a loop if RESOLVE CHANNEL is used to resolve the indoubt state. In addition, a chaining error when updating the live sync record can cause the live sync record to be lost in some circumstances, leading to duplicate records being created for the channel, and in the case of indoubt channels, the resolution of the indoubt state being performed incorrectly.
Problem conclusion
When switching cluster transmit queue using CSQUTIL, any indoubt records for the channel are now updated, and the chaining error when processing the live record is corrected.
Temporary fix
Comments
APAR Information
APAR number
PH07185
Reported component name
IBM MQ Z/OS V9
Reported component ID
5655MQ900
Reported release
000
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2019-01-11
Closed date
2019-02-07
Last modified date
2019-03-01
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI61201 UI61202
Modules/Macros
CSQMCTQS CSQXRSYN
Fix information
Fixed component name
IBM MQ Z/OS V9
Fixed component ID
5655MQ900
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":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
01 March 2019