PH63443: 10 SECONDS DELAY IN THREADS WHEN QUERYING THE CLUSTER CACHE WHILE CLUSTER REPOSITORY GARBAGE COLLECTION IS RUNNING

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The root cause of the problem is thus a timing window between
  cluster repository garbage collection and a DISPLAY QCLUSTER or
  DISPLAY QUEUE CLUSINFO command which results in garbage
  collection getting delayed by 10 seconds. This can result in
  various delays to other threads, including threads which try to
  query the cluster cache and those which require a lock on the
  cluster repository cache mutex.
  .
  Additional keywords/symptoms:
  MQOPEN, MQPUT or MQPUT1 takes 10 seconds
  

Local fix

• A workaround for this problem would be to ensure that no
  DISPLAY QCLUSTER or DISPLAY QUEUE(...) CLUSINFO commands are
  issued during cluster maintenance garbage collection
  

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: MQOPEN, MQPUT and MQPUT1 API calls      *
  *                      could be delayed by up to 10 seconds if *
  *                      a DISPLAY QCLUSTER() or DISPLAY QUEUE() *
  *                      CLUSINFO command runs at the same time  *
  *                      as cluster maintenance garbage          *
  *                      collection is running.                  *
  ****************************************************************
  CSQMFEQ is called for DISPLAY QCLUSTER() and DISPLAY QUEUE()
  CLUSINFO command processing. There is a bug in the logic in
  CSQMFEQ which serialises with cluster maintenance garbage
  collection. If CSQMFEQ runs at the same time as cluster
  maintenance garbage collection, then the cluster maintenance
  task can be delayed for 10 seconds. The cluster maintenance task
  being delayed can result in delays to other threads which
  require querying the cluster cache.
  

Problem conclusion

• The logic in CSQMFEQ which serialises with cluster maintenance
  garbage collection has been corrected.
  

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:

  UI98972 UI98973

Modules/Macros

• CSQMFEQ
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R300 PSY UI98973

     UP24/11/16 P F411

• R400 PSY UI98972

     UP24/11/16 P F411

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.