WebSphere MQ for iSeries can use native OS/400 commitment control as an external syncpoint coordinator. Thread-independent (shared) connections are not allowed with commitment control. See the iSeries: Backup and Recovery Guide, SC41-5304 for more information about the commitment control capabilities of OS/400.
To start the OS/400 commitment control facilities, use the STRCMTCTL system command. To end commitment control, use the ENDCMTCTL system command.
STRCMTCTL LCKLVL(*ALL) CMTSCOPE(*JOB)
WebSphere MQ for iSeries is also able to perform local units of work containing only updates to WebSphere MQ resources. The choice between local units of work and participation in global units of work coordinated by OS/400 is made in each application when the application calls MQPUT, MQPUT1, or MQGET, specifying MQPMO_SYNCPOINT or MQGMO_SYNCPOINT, or MQBEGIN. If commitment control is not active when the first such call is issued, WebSphere MQ starts a local unit of work and all further units of work for this connection to WebSphere MQ will also use local units of work, regardless of whether commitment control is subsequently started. To commit or back out a local unit of work, you use MQCMIT or MQBACK respectively in the same way as other WebSphere MQ products. The OS/400 commit and rollback calls such as the CL command COMMIT have no effect on WebSphere MQ local units of work.
If you wish to use WebSphere MQ for iSeries with native OS/400 commitment control as an external syncpoint coordinator, you must ensure that any job with commitment control is active and that you are using WebSphere MQ in a single-threaded job. If you call MQPUT, MQPUT1 or MQGET, specifying MQPMO_SYNCPOINT or MQGMO_SYNCPOINT, in a multi-threaded job in which commitment control has been started, the call will fail with a reason code of MQRC_SYNCPOINT_NOT_AVAILABLE.
It is possible to use local units of work and the MQCMIT and MQBACK calls in a multi-threaded job.
If you call MQPUT, MQPUT1, or MQGET, specifying MQPMO_SYNCPOINT or MQGMO_SYNCPOINT, after starting commitment control, WebSphere MQ for iSeries adds itself as an API commitment resource to the commitment definition. This is typically the first such call in a job. While there are any API commitment resources registered under a particular commitment definition, you cannot end commitment control for that definition.
WebSphere MQ for iSeries removes its registration as an API commitment resource when you disconnect from the queue manager, provided there are no pending MQI operations in the current unit of work.
If you disconnect from the queue manager while there are pending MQPUT, MQPUT1, or MQGET operations in the current unit of work, WebSphere MQ for iSeries remains registered as an API commitment resource so that it is notified of the next commit or rollback. When the next syncpoint is reached, WebSphere MQ for iSeries commits or rolls back the changes as required. It is possible for an application to disconnect and reconnect to a queue manager during an active unit of work and perform further MQGET and MQPUT operations inside the same unit of work (this is a pending disconnect).
If you attempt to issue an ENDCMTCTL system command for that commitment definition, message CPF8355 is issued, indicating that pending changes were active. This message also appears in the job log when the job ends. To avoid this, ensure that you commit or roll back all pending WebSphere MQ for iSeries operations, and that you disconnect from the queue manager. Thus, using COMMIT or ROLLBACK commands before ENDCMTCTL should enable end-commitment control to complete successfully.
When OS/400 commitment control is used as an external syncpoint coordinator, MQCMIT, MQBACK, and MQBEGIN calls may not be issued. Calls to these functions fail with the reason code MQRC_ENVIRONMENT_ERROR.
To commit or roll back (that is, to back out) your unit of work, use one of the programming languages that supports the commitment control. For example:
When you are using OS/400 commitment control as an external syncpoint coordinator with WebSphere MQ for iSeries, OS/400 performs a two-phase commit protocol in which WebSphere MQ participates. Because each unit of work is committed in two phases, there is the possibility that the queue manager becomes unavailable for the second phase after having voted to commit in the first phase. This can happen, for example, if the queue manager's internal jobs are ended. In this situation, the job log performing the commit will contain message CPF835F indicating that a commit or rollback operation failed. The messages preceding this will indicate the cause of the problem, whether it occurred during a commit or rollback operation, and also the Logical Unit of Work ID (LUWID) for the failed unit of work.
If the problem was caused by the failure of the WebSphere MQ API commitment resource during the commit or rollback of a prepared unit of work, you can use the WRKMQMTRN command to complete the operation and restore the integrity of the transaction. The command requires that you know the LUWID of the unit of work to commit and back out.