PH71769: MQ Z/OS: CSQSERVICE1 WITH A STAND-ALONE JMS APP MAY RESULT IN DUPLICATE PROCESSING OF MESSAGES OR LONG RUNNING UOWS

APAR status

• Closed as program error.

Error description

• CSQSERVICE1 was implemented due to the abends described at that
  link. When it was set for a SVRCONN channel used by a
  stand-alone JMS application using a JMS message listener,
  multiple unexpected symptoms were observed:
  
  - Long-running transactions, as indicated by CSQJ160I and
  CSQR026E messages in the MSTR job log for Units of Work
  (UOWs) in the CHIN
  - Queues with committed work for extended periods, which
  appears as UNCOM(YES) in the output of the IBM MQ command
  DISPLAY QSTATUS(queue-name) ALL
  - Messages being backed out to the queue after the application
  believes the associated transaction was committed.
  - MQMD.BackoutCount for messages increasing
  - Reprocessing of the backed-out messages resulting in
  messages with duplicate data being put to down-stream queues.
  

Local fix

• Remove the CSQSERVICE1 parameter from the Description field of
  the SVRCONN channel definition.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 4 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: When a z/OS queue manager is configured *
  *                      with the CSQSERVICE1 service identifier *
  *                      on a SVRCONN channel, a stand-alone JMS *
  *                      application using a JMS Message         *
  *                      Listener and XA transactions            *
  *                      experiences incorrect transactional     *
  *                      behaviour. Messages obtained from a     *
  *                      queue via the JMS Message Listener are  *
  *                      not correctly committed as part of the  *
  *                      XA transaction. Instead, they remain as *
  *                      uncommitted work in the conversation    *
  *                      context's native unit of work. When the *
  *                      JMSSession is closed, the channel       *
  *                      initiator ends the conversation and the *
  *                      queue manager backs out the unresolved  *
  *                      transactional work.                     *
  ****************************************************************
  The JMS Message Listener uses an asynchronous consume mechanism
  rather than the standard MQGET API to retrieve messages. When
  the CSQSERVICE1 XA mode is active, the queue manager must switch
  from the conversation's control block context to a dedicated XA
  transaction context in order to associate in-syncpoint work with
  the correct XA transaction, but this is not being done correctly
  for this environment.
  

Problem conclusion

• Processing is amended to correctly process messages when
  obtained through the asynchronous consume mechanism.
  

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:

  UO08319

Modules/Macros

• CSQMCPRH
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels