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

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Old title:
  "AFTER MIGRATION TO MQ 9.2, MQPUT1 RESPONSE TIMES MAY TAKE 10
  SECONDS TO COMPLETE"
  .
  After migration to MQ 9.2 an application experiences a response
  time of 10 seconds for PUT calls.  Time gap symptoms can be seen
  for example in CICS AUX trace such as this entry > AP abcd MQTRU
  ENTRY - APPLICATION-REQUEST - MQPUT1 -> TIME- <> AP abcd MQTRU
  EXIT - APPLICATION-REQUEST - MQPUT1. Development finds this
  occurs due to an error remaking a cluster subscription for a
  'stale' QMGR object. Cluster objects can go stale if they've
  not been used for a long time.  A code defect causes this
  subscription to be made for the wrong object. The MQOPEN
  processing subsequently waits for a maximum of 10 seconds to
  see if the subscription has been created properly, but due to
  the subscription having been made for the wrong object, it will
  always end up waiting the full 10 seconds.
  .
  ** PH38014 fixes a similar 10-second delay on a full repository.
  .
  Additional symptoms and keywords:
  If the puts to cluster queues are being done by channels,
  messages might build up on remote transmission queues
  (xmitq).  If enough incoming channels are affected, that can
  cause contention for adapter or dispatcher TCBs in the CHIN job.
  There might also be contention for latches in the BUFFPOOL.
  These points of contention can affect other processing,
  including outgoing channels.
  .
  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
  .
  Another symptom was that messages built up on
  SYSTEM.QSG.TRANSMIT.QUEUE when IGQ(ENABLED) was
  used.  The messages were targeted for cluster
  queues, and the IGQ thread (IGQAGN00) had
  10-second delays in CSQMZLOO during MQPUT
  processing.
  

Local fix

• ALTER CHANNEL for the cluster receiver channels will allow the
  subscription to be made correctly, even if the ALTER is only
  done to the DESCR field.
  .
  Before the PTF is applied, it is best to do this command at
  least every 5 days as one path of this problem can allow the
  problem to happen again after 6 days.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 2 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: If a cluster object hasn't been used    *
  *                      for more than 30 days, then attempts to *
  *                      open it on partial repositories may     *
  *                      result in 10 second delays. Depending   *
  *                      on the type of the cluster object, the  *
  *                      delays may persist for later MQOPEN     *
  *                      calls.                                  *
  ****************************************************************
  Partial cluster repositories use subscriptions to keep track of
  cluster objects. The full repositories publish new definitions
  for the objects when required. If an object hasn't been used for
  over 30 days, then attempts to open the object may result in the
  cluster subscriptions being remade.
  
  A defect in the code causes these cluster subscriptions to be
  remade incorrectly. The open processing then waits for the
  subscription to complete, but since the subscription was remade
  incorrectly, it results in a 10 second wait.
  

Problem conclusion

• The code has been changed to correctly remake cluster
  subscriptions for cluster objects.
  

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:

  UI74363

Modules/Macros

• CSQMZLOO CSQXRRMF
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R200 PSY UI74363

     UP21/04/01 P F103

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.