PH38014: AFTER MIGRATION TO MQ 9.2 MQOPEN, MQPUT AND MQPUT1 FOR CLUSTER OBJECTS MIGHT TAKE 10 SECONDS TO COMPLETE ON FULL REPOSITORIES

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Old title:
  "AFTER MIGRATION TO MQ 9.2 CICS TRANSACTIONS TAKE A LONG TIME TO
  COMPLETE (SYMPTOMS EXTERNALLY SIMILAR TO PH34589)"
  .
  When opening a cluster queue for PUT, resolution is performed
  after which a queue manager (either local or remote) will be
  chosen based on the result of the cluster workload management
  algorithm. In the event that (a) the local qmgr is chosen, and
  (b) it is a full repository, then this issue may occur in some
  cluster configurations. Because, by design, full repositories
  do not have subscriptions for their own local qmgr objects,
  when the above resolution/lookup process is performed, this
  results in (ten) 1 second waits for the subscription to resolve
  that relates to the cluster qmgr object.
  .
  Additional symptoms and keywords:
  .
  A receiver (RCVR) channel putting to a cluster queue might
  receive error:
  CSQX208E CSQXRESP Error receiving data,
      channel <channel-name>
      connection <connection-name>
      (queue manager <queue-manager-name>)
      TRPTYPE=TCP RC=00000480 reason=00000000
  

Local fix

• Similar to the local fix for PH34589, issuing an ALTER CHANNEL
  for the queue manager's CLUSRCVR will allow the condition to be
  temporarily circumvented. In the case where PH34589 is already
  APPLIED, then ALTER CHANNEL will prevent the issue from
  occurring for 54 days (i.e. 2 subscription lifetimes). In the
  case where PH34589 is not APPLIED, then the same local fix will
  only circumvent the condition for 6 days.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 2 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: When opening or putting to a cluster    *
  *                      queue on a full repository queue        *
  *                      manager, in some scenarios, the MQAPI   *
  *                      call may take 10 seconds.               *
  *                                                              *
  *                      This problem may manifest as messages   *
  *                      building up on other cluster queue      *
  *                      managers' cluster transmission queues.  *
  ****************************************************************
  Partial cluster repositories use cluster subscriptions to keep
  track of cluster objects. The full repositories then publish new
  definitions for the objects when required. Cluster queue
  managers will sometimes be required to make new cluster
  subscriptions to rarely updated objects.
  
  A code defect results in full repository queue managers making
  cluster subscriptions in scenarios where they are unable to
  complete. This results in a 10 second delay while waiting for
  the subscription to resolve.
  

Problem conclusion

• The code has been corrected to prevent full repository queue
  managers from making unnecessary cluster subscriptions, removing
  the 10 second delays.
  

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:

  UI76152

Modules/Macros

• CSQMZLOO
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R200 PSY UI76152

     UP21/07/19 P F107 ¢

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.