Syncpoints

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.

Unit of Work Concept

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.

Syncpoint versus related ideas
ConceptQuestion it answers
Syncpoint / UOWWhen do others see my puts and gets?
Persistence (MQMD)Does message survive QM restart?
Commit (MQCMIT)Make UOW permanent
Rollback (MQBACK)Undo UOW
XAOne commit for MQ + database

Enrolling Puts and Gets

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.

text
1
2
3
4
5
6
Typical 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)

Explainer: Draft Tray Versus Outbox

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.

Visibility and Timing

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.

Implicit and Explicit Boundaries

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.

Failure Scenarios

  1. Process crash after get commit but before DB commit — message lost from queue, DB inconsistent (avoid by commit order design).
  2. Process crash before MQCMIT after DB commit — duplicate message on redelivery (use idempotency).
  3. MQBACK after bad JSON — message returns, backout count rises.
  4. Disconnect without commit — UOW typically rolls back.

CICS and Batch on z/OS

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.

When Not to Use Syncpoints

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.

Explain Like I'm Five: Syncpoints

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.

Practice Exercises

Exercise 1

Draw a timeline for put-syncpoint-commit versus put-NO_SYNCPOINT for two messages.

Exercise 2

List three risks of a long-running UOW holding a syncpointed get.

Exercise 3

Explain difference between syncpoint and persistence for an audit log message.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. A syncpoint boundary marks:

  • Commit or rollback point
  • Channel start
  • Listener port
  • Format disk

2. Put under syncpoint before commit is:

  • Hidden from other consumers
  • Always on DLQ
  • Always persistent
  • Sent to FTP

3. MQPMO_SYNCPOINT enrolls:

  • Put in current UOW
  • Channel
  • Listener
  • Repository

4. Syncpoints differ from persistence because:

  • Syncpoint is atomicity; persistence is restart survival
  • They are identical
  • Persistence replaces syncpoint
  • Neither affects MQ
Published
Read time20 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation