PH46414: MQ Z/OS :MQRC=2082 MQOPEN ERROR DUE TO FAILURE TO WAIT UP TO 10 SECONDS TO ALLOW ALL FULL REPOSITORIES TO RESPOND

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• For a QALIAS pointing to a new cluster queue, 2082
  MQRC_UNKNOWN_ALIAS_BASE_Q is received the first time the queue
  is opened. The second time, the MQOPEN works. Similarly, 2085
  MQRC_UNKNOWN_OBJECT_NAME occurs the first time a cluster queue
  is opened directly.
  
  In order for the problem with "MQRC 2082 Unknown alias base
  queue" to occur, it is necessary for the queue manager where
  the queue is being opened to be in more than one cluster. When
  the unknown queue is opened for the first time, subscription
  requests are sent to all full repositories for all clusters in
  which the queue manager is present. The queue manager then
  waits for acknowledgement of the subscription. This wait will
  initially be for one second. After this initial one-second
  wait, the ongoing MQOPEN processing will check to see if the
  subscription request has been acknowledged by a full
  repository. If no response has been received in this time then
  it will continue to wait for a maximum of 10 seconds before
  eventually reporting MQRC_CLUSTER_RESOLUTION_ERROR.
  If however, any of the full repositories acknowledge one of the
  subscription requests, then MQOPEN processing will proceed and
  we will check if the requested queue has been inserted into the
  cluster cache as a result of an update from one of the full
  repositories. If the FR that initially responds to the
  subscription request has a definition for the queue within its
  cluster then the MQOPEN will succeed. If a full repository that
  does not host any instances of the queue within its cluster is
  the first to respond and the FR that does host instances the
  queue does not respond during the initial one second wait then
  we will fail to open the queue and the problem reported by the
  customer can occur.
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 1 Modification 0 and                 *
  *                 Release 2 Modification 0 and                 *
  *                 Release 3 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: MQRC=2085 (MQRC_UNKNOWN_OBJECT_NAME) or *
  *                      MQRC=2082 (MQRC_UNKNOWN_ALIAS_BASE_Q)   *
  *                      is returned from an MQOPEN of a         *
  *                      clustered queue that is being opened    *
  *                      for the first time on a clustered Queue *
  *                      Manger even though the queue exists in  *
  *                      the cluster. This occurs when the Queue *
  *                      Manager is part of multiple clusters    *
  *                      and the clustered queue only exists in  *
  *                      a subset of the clusters.               *
  ****************************************************************
  MQRC=2085 (MQRC_UNKNOWN_OBJECT_NAME) or MQRC=2082
  (MQRC_UNKNOWN_ALIAS_BASE_Q) is returned from an MQOPEN of a
  clustered queue that is being opened for the first time on a
  clustered Queue manager even though the queue exists in the
  cluster. This occurs when the Queue Manager is part of multiple
  clusters and the clustered queue only exists in a subset of the
  clusters.
  
  MQ is failing to wait up to 10 seconds for a cluster
  subscription to a clustered queue to be acknowledged by a full
  repository that has knowledge of the location of the clustered
  queue. In this case only the clustered subscriptions for the
  clustered queue in a cluster where the clustered queue does not
  exist has been acknowledged by a full repository.
  

Problem conclusion

• The code has been changed so that when clustered subscriptions
  for a clustered queue have been created as part of the first
  MQOPEN of a clustered queue, MQ will correctly wait up to 10
  seconds for a clustered subscription to be acknowledged by a
  full repository that has knowledge of the location of the
  clustered queue. Alternatively, MQ will stop waiting if all
  clustered subscriptions are acknowledged but no information
  about the clustered queue is published to the Queue Manager
  where the MQOPEN was attempted, this is a valid case where the
  queue does not exist in the cluster.
  

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:

  UI91036 UI91037 UI91038

Modules/Macros

• CSQMZLOO
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R100 PSY UI91935

     UP23/06/16 P F306

• R200 PSY UI91934

     UP23/06/16 P F306

• R300 PSY UI91933

     UP23/06/16 P F306

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.