A syncpoint is a checkpoint in IBM MQ where work either becomes permanent or disappears. Between checkpoints, puts and gets enrolled in the unit of work (UOW) are provisional—like draft emails not sent until you press send. Enterprises use syncpoints so messaging matches database updates: transfer money in Db2 and notify downstream in MQ in one business decision. Without syncpoints, each MQPUT commits immediately and a crash after partial processing leaves inconsistent state. With syncpoints, you batch operations and choose commit or rollback once. Beginners confuse syncpoint with persistence—persistent messages survive restart; syncpoint controls whether a put is visible to others before you commit. This tutorial defines UOW boundaries, how MQPMO_SYNCPOINT and MQGMO_SYNCPOINT enroll calls, visibility rules, mixing syncpoint and non-syncpoint calls, CICS task boundaries, global transactions preview, and failure scenarios that teach why backout exists.
Think of one business transaction: debit account, put confirmation message, update audit row. All three should succeed or none. The UOW holds MQ operations until syncpoint commit. Non-MQ resources join only when a transaction manager coordinates—Db2, IMS, or XA. Pure MQ batch may still use UOW to group ten puts before one commit for performance and atomicity.
| Concept | Question it answers |
|---|---|
| Syncpoint / UOW | When do others see my puts and gets? |
| Persistence (MQMD) | Does message survive QM restart? |
| Commit (MQCMIT) | Make UOW permanent |
| Rollback (MQBACK) | Undo UOW |
| XA | One commit for MQ + database |
MQPMO_SYNCPOINT on put adds message to UOW. MQGMO_SYNCPOINT on get removes message provisionally—rollback puts it back. NO_SYNCPOINT options commit immediately when not inside a larger coordinated transaction. Mixing within one program requires documentation: accidental NO_SYNCPOINT put while database still open creates orphan messages.
123456Typical consumer UOW: 1. MQGET + MQGMO_SYNCPOINT (message locked in UOW) 2. Validate and update database 3. MQCMIT (get committed, message gone for others) OR MQBACK (get rolled back, message available again)
Syncpoint is the draft tray inside the post office. Letters you put there are not delivered until the clerk commits them to the outbox. Rollback throws your drafts away.
Before commit, competing consumers on the same queue should not see a syncpointed get. Before commit, syncpointed puts are invisible. Exact edge cases with browse and certain APIs are documented by IBM for your release—test in lab. Long UOW holding gets blocks queue depth—keep processing fast inside the fence.
Some environments start UOW on first syncpoint call. MQBEGIN explicitly starts in certain client configurations. CICS may tie UOW to task start and SYNCPOINT command. Microservices using only NO_SYNCPOINT rarely call MQCMIT—each operation auto-commits. Know which pattern your template uses.
EXEC CICS SYNCPOINT ends UOW including MQ in the task. SYNCPOINT ROLLBACK backs out. Batch programs may call MQCMIT explicitly. RACF and task user still govern authority inside UOW.
High-volume telemetry with tolerated loss may use NO_SYNCPOINT and non-persistent for speed. Read-only browse never needs syncpoint. Request/reply with auto-commit may be fine when duplicates are impossible. Document the trade-off in architecture reviews.
Syncpoints are when you tell the game to save your progress—until then, if you turn off the console, the level you just finished might not count.
Draw a timeline for put-syncpoint-commit versus put-NO_SYNCPOINT for two messages.
List three risks of a long-running UOW holding a syncpointed get.
Explain difference between syncpoint and persistence for an audit log message.
1. A syncpoint boundary marks:
2. Put under syncpoint before commit is:
3. MQPMO_SYNCPOINT enrolls:
4. Syncpoints differ from persistence because: