IT17605: Browser client MQGETs or async consumers do not see their message until the end of their wait interval

APAR status

• Closed as program error.

Error description

• If multiple client browser MQGETs are waiting for a message,
  with SHARECNV>0 then only one of them returns immediately from
  the MQGET.  The others wait within their MQGET until their
  WaitInterval is finished, and then their MQGET returns to the
  application with the message.
  
  The message should have been made available to the other
  application(s) immediately.  That is, their MQGET calls should
  have returned immediately, not after their WaitInterval had
  expired.
  
  The same effect is seen when using async consume MQ APIs (MQCB,
  MQCTL) and using a wait interval.
  
  After this, if another message arrives, then again one of the
  waiting browser MQGETs will return immediately, but the others
  will not see it till later.  In each case, even though all
  waiting browse MQGETs were eligible to receive the message
  immediately, only one of them received it immediately.  The
  others received it later.
  

Local fix

• Set attribute SHARECNV of the server connection channel in use
  to 0, SHARECNV(0).
  

Problem summary

• ****************************************************************
  USERS AFFECTED:
  Applications performing browsing MQGETs from client programs
  connected via SHARECNV>0 channels, and using a WaitInterval.
  Also applications using asynchronous consume APIs and using a
  WaitInterval.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  The list of asynchronous browsing waiters within the queue
  manager was re-ordered to try to ensure fair division of work
  between them.  However, upon moving the first browsing waiter to
  the end of the list, the loop then immediately ended because the
  MQ code did not remember that there were other waiters in the
  list.  Therefore the other waiters were not considered eligible
  for posting to see that message immediately.
  

Problem conclusion

• The coding error has been fixed so that the loop will continue,
  and consider all waiters in the case where the first one has
  been re-ordered in the list.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v7.5       7.5.0.8
  v8.0       8.0.0.7
  v9.0 CD    9.0.3
  v9.0 LTS   9.0.0.2
  
  The latest available maintenance can be obtained from
  'WebSphere MQ Recommended Fixes'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
  
  If the maintenance level is not yet available information on
  its planned availability can be found in 'WebSphere MQ
  Planned Maintenance Release Dates'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
  ---------------------------------------------------------------
  

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:

Fix information

• Fixed component name

  WEBSPHERE MQ 7.

• Fixed component ID

  5724H7240

Applicable component levels