A fix is available
APAR status
Closed as program error.
Error description
After the shared sender channel went into retry state, and then DB2 went down, MQC1CHIN detected that the channel needed retrying, and got ready to do so. Internally it changed the local state of the channel to STARTED and then tried to read the channel status entry from DB2. However, as DB2 was down the retry processing was stopped, leaving the local status entry with a status of STARTED. That shouldn't normally be a problem, and channels with such a state will be retried after 1 minute. When this happens, the channel initiator checks the processid (i.e. XPWA address) to see if the process is active. If so, no retry will be performed. However, in this case the processid was 'old' (i.e. associated with the XPWA from the last time the channel tried to connect to the partner), but it may have been reused by another channel, or by an internal process. If this is the case then the channel will remain in the retry state although no retrying will actually be performed.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 1 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: Shared Sender Channel may not get * * restarted after DB2 unavailability. * **************************************************************** * RECOMMENDATION: * **************************************************************** A shared channel is in retry state because the partner qmgr is not available. While it is in retry state, DB2 becomes unavailable. Retry processing attempts to restart the channel. However, as DB2 is unavailable the channel is left in STARTING state in the local status entry. While in this state, the XPWA control block that was previously used for the shared channel is reused for another channel. This prevents the channel retry processing from attempting to restart the channel, even when DB2 becomes available again, although the shared status of the channel shows RETRYING. Additional keywords: CSQX483E
Problem conclusion
CSQXRIFN has been changed to put the CHANNEL into RETRY state when DB2 is not available. 100Y CSQXRIFN
Temporary fix
Comments
APAR Information
APAR number
PM55973
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
100
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2012-01-16
Closed date
2012-03-23
Last modified date
2013-10-24
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK77036
Modules/Macros
CSQXRIFN
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
R100 PSY UK77036
UP12/04/21 P F204
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.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
24 October 2013