A fix is available
APAR status
Closed as program error.
Error description
When "Channel start" commands are added in CSQ4INPX definition, there are CSQX477E when CHIN restarts which means Channel is active. At V710 (and V701 after PM46019), CSQXADPM (Check_connections) will always fail any MQGETs with MQRC_CONNECTION_QUIESCING, 2202, when the CHIN is being stopped, which results in the problem seen here (previously the MQGET would have failed with MQRC_GET_INHIBITED and rriSendData would have detected that the channel was being put into an inactive state and hence it would not have started when the CHIN was restarted). This problem with CSQX037E with MQRC=2202 being issued when the CHIN is being stopped followed by channels being unexpectedly started when the CHIN is restarted, causing the CSQX477E messages. Additional Symptom(s) Search Keyword(s): CSQX477E, CSQX037E, 2202, CHIN, double start on a channel at startup CSQX514E CSQ1 CSQXRCTL Channel CSQ1.TO.CSQ2 is active on CSQ1
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 0 Modification 1 * **************************************************************** * PROBLEM DESCRIPTION: On CHINIT termination active channels * * end issuing message CSQX037E with * * MQRC=2202 (MQRC_CONNECTION_QUIESCING) * * For cluster channels this will cause * * message reallocation and CHINIT may * * take a long time to terminate. * **************************************************************** * RECOMMENDATION: * **************************************************************** At V701 CSQXADPM Check_Connection will return MQRC_CONNECTION_QUIESCING, 2202 when doing an MQGET on the transmission queue if the CHINIT is quiescing. rriSendData doesn't specifically react to that return code and ends up in the default case, which causes the channel status to be set to RETRY and error message CSQX037E to be issued. If the channel is a cluster sender then message reallocation will be done, which is futile given that all channels are being stopped. If a lot of messages are involved then CHINIT termination may take some time.
Problem conclusion
rriSendData now detects if the MQGET on the transmission queue has failed with MQRC_CONNECTION_QUIESCING, and if the CHINIT is terminating will set the channel status to CLOSING. 010Y CSQXRMTR
Temporary fix
Comments
APAR Information
APAR number
PI13179
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
010
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2014-03-06
Closed date
2014-07-10
Last modified date
2014-09-03
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI19566
Modules/Macros
CSQXRMTR
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
R010 PSY UI19566
UP14/08/30 P F408
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:
03 September 2014