A fix is available
APAR status
Closed as program error.
Error description
A running channel failed while the queue manager was not able to communicate with DB2. SYSTEM.QSG.CHANNEL.SYNCQ could not be updated with the channel's status change. The channel was unable to be adopted by another member of the Queue Sharing Group ( QSG ) because the SYNCQ indicated that the channel was still running. Messages on the queue manager whose connection to DB2 was unavailable: CSQ5019I CSQ3 CSQ5DISC Disconnected from DB2 DB21 CSQ5019I CSQ3 CSQ5DISC Disconnected from DB2 DB22 CSQ5003A CSQ3 CSQ5CONN Connection to DB2 using DB2G pending, no active DB2 +CSQX483E CSQ3 CSQXSUPR DB2 not available +CSQX259E CSQ3 CSQXRESP Connection timed out, channel <channel>, connection <connection id> (queue manager <queue manager>) TRPTYPE=TCP +CSQX599E CSQ3 CSQXRESP Channel <channel> ended abnormally Messages on another queue manager in the QSG: +CSQX476E CSQ1 CSQXRESP Channel <channel> is active on CSQ3, shared status entry found
Local fix
None until the DB2 connection is available.
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: After a shared receiver channel ends on * * a queue manager that has lost * * connectivity to DB2, it cannot be * * restarted until that queue manager * * reconnects to DB2, even if the channel * * could run on other queue managers in * * the QSG. An attempt to restart the * * channel fails with CSQX476E 'Channel in * * use' * **************************************************************** * RECOMMENDATION: * **************************************************************** If a shared receiver channel stops while the queue manager it runs on is unable to access DB2, the shared status entry for the channel is not updated to reflect that the channel is no longer running on that queue manager. When an attempt is made to restart the channel on a different queue manager in the QSG, channel adoption processing will attempt to adopt the channel. However if the original queue manager still has no access to DB2, channel adoption fails and the channel cannot start. This is shown by message CSQX476E.
Problem conclusion
Channel adoption processing has been changed, to allow it to cope with connectivity loss to DB2 on some of the queue managers in a queue sharing group. This allows the channel to successfully start in this scenario. 010Y 100Y CSQXRCMS CSQXRCSI
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI05681
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-11-06
Closed date
2014-02-11
Last modified date
2014-04-02
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI15014 UI15015
Modules/Macros
CSQXRCMS CSQXRCSI
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:
02 April 2014