PI47136: WMQ: XMS APPLICATIONS GET MESSAGES WITH A DELAY

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• XMS applications IBM MQ V8 get messages with a delay of several
  seconds.
  The messages are read from a shared queue with
  DEFREADA(NO) (default read-ahead).
  
  When several clients trying to get messages from the queue
  read-ahead streaming is started for the queue, but the client
  issue an MQGET with MQGMO_SYNCPOINT. During MQGET processing by
  one of the clients the message in question is located in the CF
  and is moved to the uncommitted get-list. MQGET processing then
  detects that read-ahead streaming is taking place and a
  notification must be sent that the next message is transactional
  The message is therefore moved back from the uncomitted get-list
  to the put-list, and the MQGET is failed with
  lpiRC_TRANSACTIONAL_NEXT. The CHIN detects the
  lpiRC_TRANSACTIONAL_NEXT and reissues the MQGET after
  setting lpiCBDO_ALLOW_NEXT_TRANSACTIONAL.
  The MQGET does not return the message as it is on the
  uncommitted get-list due to another client being in the
  the process of retrieving it,only for the MQGET to
  also fail withlpiRC_TRANSACTIONAL_NEXT.
  This sequence continues for some time until there is
  a window in which an MQGET is issued with
  piCBDO_ALLOW_NEXT_TRANSACTIONAL
  when there is not another client in the process of
  getting the message.
  .
  Additional Keywords:
  response time performance delayed
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 8 *
  *                 Release 0 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Applications getting messages from a    *
  *                      shared queue using a client connection  *
  *                      encounter delays getting messages when  *
  *                      multiple applications are consuming     *
  *                      from the same shared queue.             *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  A client application using a channel with SHARECNV > 0 to
  consume messages from a queue causes the chinit to register a
  callback to detect when messages arrive on the queue. When
  messages arrive they can be eligible for streaming to the
  client, if they do not require any syncpoint operation to occur.
  When a message arrives that would require a syncpoint operation
  (for example when consuming messages with MQGMO_SYNCPOINT), the
  chinit stops streaming, sends a notification to the client and
  waits until the client is ready to receive the message. During
  this processing the message is briefly moved to the uncommitted
  get queue before being returned to the queue while the
  notification is sent.
  When there are multiple client applications consuming from the
  queue, it is possible that when the initial client is ready
  to consume the message, another client has moved it to the
  uncommitted get queue and so the initial client cannot find it.
  This causes the initial client to restart the process of
  locating and returning the message.
  This contention between multiple getters can in some cases
  result in delays of several seconds before any of the
  getters are able to successfully consume the message.
  

Problem conclusion

• CSQEMGET is changed to no longer move the message to the
  uncommitted get queue when called from a client application
  requesting transactional notification and getting messages with
  MQGMO_SYNCPOINT, and consequently prevents the reported
  contention for the message from occurring.
  000Y
  CSQEMGET
  CSQE197N
  CSQIMGES
  CSQMGET
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UI32242

Modules/Macros

• CSQEMGET CSQE197N CSQIMGES CSQMGET
  

Fix information

• Fixed component name

  WMQ Z/OS 8

• Fixed component ID

  5655W9700

Applicable component levels

• R000 PSY UI32242

     UP15/11/11 P F511 ¢

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.