Syncpoint Coordination

Syncpoint coordination is the discipline that keeps IBM MQ messages aligned with everything else the mainframe touched in the same business second—Db2 rows, IMS databases, VSAM files, and CICS recoverable resources. Without coordination, you can commit a payment in SQL and lose the fraud-alert message, or publish an order event while the inventory row rolled back. z/OS matured answers decades ago: CICS drives syncpoints for online tasks, Resource Recovery Services coordinates batch and subsystem paths, IMS and Db2 enroll as resource managers, and MQ joins the unit of work when configured. Distributed developers meet the same ideas through XA and JTA; the names change but the contract does not—one commit or one rollback for the whole action. This tutorial explains coordination concepts, CICS and RRS paths, what developers should and should not call, indoubt handling at a high level, differences from eventual-consistency patterns, and operational signals when coordination breaks.

Unit of Work and Coordinators

A unit of work (UOW) is the set of changes between syncpoints. MQ puts and gets with syncpoint options enroll in the current UOW—they are provisional until commit. The syncpoint coordinator decides when to commit or roll back and notifies each resource manager. On z/OS the coordinator may be CICS, IMS, RRS, or a transaction manager in a Java server. MQ is a participant, not the business owner of the whole transaction.

CICS Syncpoint Coordination

In a coordinated CICS region, application code MQPUTs and MQGETs with syncpoint participation, updates Db2 through EXEC SQL, and ends with EXEC CICS SYNCPOINT. CICS tells MQ to prepare and commit with the task. If the program issues SYNCPOINT ROLLBACK or the task abends with rollback, MQ work in the UOW backs out as well—messages put under syncpoint disappear from the queue for other consumers; gets may be restored depending on options. Developers must not sprinkle MQCMIT in the middle of a CICS transaction unless architecture explicitly allows MQ-only commits—which breaks Db2 alignment.

1
2
3
4
      EXEC CICS SYNCPOINT END-EXEC.
      * After successful MQPUT with syncpoint and SQL updates:
      * One SYNCPOINT commits CICS, Db2, and MQ together
      * when all are enrolled in the same task UOW.

Task boundaries matter. A triggered CICS transaction that MQGETs under syncpoint and fails before SYNCPOINT may return the message to the queue or move it per backout threshold—coordinate with poison-message handling tutorials. Nested transactions and LINK to other programs require clear ownership of who issues SYNCPOINT.

RRS and Batch Coordination

Resource Recovery Services lets batch jobs and certain subsystem programs coordinate Db2 and MQ without CICS. The job establishes an RRS-coordinated UOW, performs SQL and MQI calls with syncpoint options, and commits through the RRS interface. Operations teams monitor RRS and subsystem logs when batch claims success but partners see missing messages—often a partial commit or skipped syncpoint. Not every batch job uses RRS; many still do MQ-only commits with compensating logic. Architects document which jobs are atomic across resources.

IMS and MQ Coordination

IMS Transaction Manager programs can coordinate IMS databases and MQ when the environment is configured for it. The IMS bridge tutorials cover entry patterns; syncpoint coordination means CHKP in IMS terms aligns with MQ visibility. Mixed IMS–CICS–MQ designs need explicit ownership of which subsystem coordinates which leg of a workflow.

MQ-Only Versus Global UOW

Indoubt and Failure Handling

During two-phase commit, a system failure after prepare can leave MQ or Db2 indoubt—uncertain whether the global transaction committed. Operators use queue manager and Db2 administration tools to resolve indoubt UOWs per IBM procedures. Applications should treat coordinator errors seriously: retrying blindly can duplicate work. Logging correlation ids across CICS task, MQ message id, and Db2 audit keys speeds recovery meetings.

Developer Rules of Thumb

1. One business commit point per request when possible—avoid multiple SYNCPOINTs unless the business requires partial progress.
2. Enroll MQ puts and gets that must match database work with syncpoint options.
3. Let the platform coordinator commit; avoid MQCMIT in coordinated CICS or IMS tasks.
4. Map abend and rollback paths: what happens to the message and the Db2 row?
5. Test failure injection: kill task after SQL but before SYNCPOINT; verify no phantom messages.

Tutorial: Trace a Coordinated CICS Transaction

Document one online flow: MQGET payment request, validate in program, UPDATE Db2 balance, MQPUT confirmation, EXEC CICS SYNCPOINT. List each resource touched, which calls use syncpoint options, and what rollback does to the input message. Present to operations before production cutover.

Explainer: One Receipt for the Whole Shopping Trip

Coordination is one receipt for groceries, pharmacy, and dry cleaning bought together—either everything is paid or nothing is. Uncoordinated MQ is paying for groceries while the pharmacy charge vanishes from the statement.

Explain Like I'm Five

When you save a game, all your coins, lives, and level number save together. Syncpoint coordination saves your MQ message and database score at the same time so they never disagree.

Practice Exercises

Exercise 1

For a transfer between two Db2 accounts plus MQ notification, argue for global UOW versus outbox table.

Exercise 2

List three symptoms operators see when a developer used MQCMIT inside coordinated CICS incorrectly.

Exercise 3

Write rollback behavior for: SQL fails after MQPUT under syncpoint; abend after SYNCPOINT.

Frequently Asked Questions

Test Your Knowledge