PH63317: BROWSE-LOCKED UNCOMMITTED MESSAGES IN SHARED QUEUE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Uncommitted messages remained in a shared queue, IPPROCS and
  OPPROCS are zero, there is no unresolved unit of work and
  recycling queue manager does not fix the problem.
  
  The uncommitted messages are actually a browse-locked message.
  These are messages which are got with MQGET option MQGMO_LOCK
  while browsing a queue. While a message is browse locked, it is
  stored on the uncommitted get queue CF list header for the
  QMGR. The message in the CF list structure has metadata
  associated with it which allows it be moved back to the
  original put CF list header when the lock is released. The lock
  on the message is removed when the browse cursor moves on or
  when the queue is closed, and at this point, the message should
  be moved back to the original put queue CF list header.
  
  The MSTR joblog shows many CSQ3201E messages for a job
  processing the queue before the DISPLAY QSTATUS which shows the
  queue as having UNCOM(YES). CSQ3201E are usually issued as a
  result of a job receiving an MVS CANCEL. If the job was in the
  process of browsing and locking a message from queue when the
  CANCEL took affect, then this would drive recovery in the QMGR
  which attempts to unlock the message and move it back to the
  original list header.
  
  There are timing windows where a locked message is not unlocked
  correctly. These timing windows look to be exclusive to
  applications which browse a shared queue locking each message
  in turn. In this scenario, MQ has to both lock the newly
  browsed message, and also unlock the previously browsed
  message. There are timing windows where if an application
  abends (say due to a CANCEL) after locking a new message then
  recovery will unlock the previously browsed message, but not
  the newly browsed message. This leaves the message locked after
  the application ends.
  
  This is not the correct behavior.
  

Local fix

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: Messages are left uncommitted on shared *
  *                      queues following the cancel of an       *
  *                      application browsing the queue with the *
  *                      MQGMO_LOCK GMO option.                  *
  *                                                              *
  *                      DISPLAY QSTATUS(Q1) shows a non-zero    *
  *                      CURDEPTH and UNCOMM(YES).               *
  *                                                              *
  *                      In some instances abend 5C6-00C510AF    *
  *                      can occur in CSQEMULK on subsqeuent     *
  *                      MQGET requests using the same queue     *
  *                      handle.                                 *
  ****************************************************************
  During the browse of a message on a shared queue with the
  MQGMO_LOCK option, the located message is locked by being moved
  to the uncommitted get list header. If the application task
  abends after this move takes place, but before the cursor is
  updated to reflect this, recovery processing incorrectly unlocks
  the previously locked message (if any) instead of the newly
  located message, leaving the newly located message locked and
  unable to be found by MQGET processing. In cases where the
  previously locked message is incorrectly unlocked, this can lead
  to subsequent MQGET requests for the same queue handle to abend
  5C6-00C510AF in CSQEMULK.
  

Problem conclusion

• CSQEMGEB and CSQEMGEK are updated to update the internal cursor
  value when moving the located message to the uncommitted get
  list header, so that subsequent recovery processing will
  correctly unlock it.
  

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:

  UO04400 UO04401

Modules/Macros

• CSQEMGEB CSQEMGEK
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R300 PSY UO04401

     UP25/09/13 P F509

• R400 PSY UO04400

     UP25/09/13 P F509

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.