Home/ Questions/Q 8824695
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T06:41:52+00:00

We are currently implementing a WMQ cobol client on iseries. The MQ client version

  • 0

We are currently implementing a WMQ cobol client on iseries.
The MQ client version is 7.1.

The program is set MQPMO_SYNCPOINT, is not multithread and the commit control definition are set qccording to the informations provided here :

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/topic/com.ibm.mq.doc/fg13800_.htm

When a MQput is issued the message appears in the queue but is not commited when the global commit is issued.

So my question is :

Do I have to install a QMGR on my iseries in order to be able to use IBM i external syncpoint manager.

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Short answer – yes.

    The Infocenter page referenced does not make it very clear that what is documented on that page is how the Queue Manager performs the role of Transaction Coordinator. Normally when performing in this role all of the XA coordination is performed by the queue manager. However, by configuring the QMgr according to the instructions on the linked page, it can delegate the XA coordination to the native IBM i commitment control.

    For clients to use XA capabilities, you must either have purchased a full WMQ Server license and used the entitled XA client component delivered with it, or you would have to have downloaded a fresh copy of WMQ client sometime after the 4 October 2011 announcement which removed the license cost for that component.

    Once you have an XA client (either paid or a recent free version) then you still must provide a way for the XA transaction manager to talk to the QMgr. For example, if using WebSphere Application Server, it acts as the transaction coordinator and uses the client’s channel to reconnect with MQ and reconcile any outstanding transactions after a failure. In the solution described in the question, the queue manager doesn’t have any connection to the transaction coordinator and so when it receives a transactional commands either resolves them within its own XA context or optimizes them to single-phase commit.

    Best solution based on what little information is gleaned from the question is that a QMgr on the iSeries box, configured as per the linked Infocenter page and running alongside the application and the native IBM i commitment control, would address all of these requirements. In addition, the application could run in bindings mode which is more reliable and faster than talking to the QMgr over the network.

    • 0