PH67368: OUTBOUND SHARED CHANNEL RECOVERY DOES NOT COMPLETE

APAR status

• Closed as program error.

Error description

• User reports recovery for a shared outbound channel is
  unsuccessful (CSQX477E CSQXSUPR Channel channel-name is active,
  transmission queue queue-name in use on ???? ). Development
  finds a defect where MQ does not correctly clean up during
  peer-recovery after loss of connectivity to a CF structure where
  the queue manager still retains partial connectivity to XCF.
  

Local fix

• Ensure a highly-redundant configuration is in place (i.e.
  multiple CFs) for the structure, allowing for system-managed
  rebuilds that facilitate MQ recovery.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 3 Modification 0 and Release 4       *
  *                 Modification 0.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: "CSQX477E CSQXSUPR Channel channel-name *
  *                      is active, transmission queue           *
  *                      queue-name in use on ????" is issued    *
  *                      for shared sender channels that had     *
  *                      been running on a peer queue manager    *
  *                      that lost connectivity to both the      *
  *                      application structure holding the       *
  *                      transmission queue, and the admin       *
  *                      structure, and then terminated.         *
  *                      The shared channel cannot be restarted  *
  *                      until the queue manager where it was    *
  *                      previously running is restarted and     *
  *                      able to connect to the structures       *
  *                      again.                                  *
  ****************************************************************
  A shared sender channel was running on a queue manager in a
  Queue Sharing Group when the system lost connectivity to the
  Coupling Facility hosting both the application structure that
  contained the transmission queue and the admin structure.
  
  A peer queue manager with connectivity attempted to rebuilt the
  admin structure, and then perform Peer Level Recovery (PLR) for
  the failed application structure connection, however this failed
  because the original queue manager was still active, and the
  connection was incorrectly deleted.
  
  After the original queue manager was stopped, the peer
  successfully rebuilt the admin structure entries for the failed
  queue manager, however as the application structure connection
  had been deleted, PLR was not retried.
  
  When the shared channel attempted to restart, the transmission
  queue still showed it was open on the failed queue manager, and
  so the channel was not able to start successfully.
  This persisted until the original queue manager was able to
  restart with connectivity to the CF restored.
  

Problem conclusion

• When PLR for a connection fails because of missing admin
  structure entries, the connection will be left in a 'failed
  persistent' state, which will cause PLR to be reattempted when a
  peer queue manager subsequently connects to the application
  structure.
  In addition, PLR will be automatically retried for failed
  persistent connections to application structures, following
  successful admin structure rebuild.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UO07821 UO07822

Modules/Macros

• CSQEPRAD CSQESTE
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels