PM55973: WMQ V710 QSG SHARED SENDER CHANNEL RETRY STATUS IMPACTED BY DB2 OUTAGE

Obtain the fix for this APAR.

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 is sysrouted FROM one or more of the following:

  PM54309

• 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.