Syncpoint Control

Syncpoint control is the steering wheel for IBM MQ reliability: it decides whether a put or get is provisional or final, whether a failure rolls back messaging work, and whether your consumer can retry without losing the message. Every production consumer that processes business data should understand MQGMO_SYNCPOINT, MQPMO_SYNCPOINT, MQCMIT, and MQBACK before tuning performance. On z/OS, CICS programmers often syncpoint at task end without calling MQ APIs by name—yet the same rules apply. This page explains how to enroll operations in a unit of work, how commit and backout change queue depth and visibility, how global transaction managers coordinate syncpoint with Db2, common mistakes that create at-most-once loss, and operational symptoms when applications forget to commit.

What a Syncpoint Does

A syncpoint marks a boundary. Everything after the previous boundary and before the next commit or rollback belongs to one unit of work. IBM MQ queues messages and locks resources so partial outcomes are not visible to other applications mid-UoW. When you MQCMIT, the queue manager makes puts visible and confirms gets. When you MQBACK, puts never appear for others and gets are reversed. That is syncpoint control—not a separate product feature but the discipline of using the right options and ending the UoW correctly.

Put Path Under Syncpoint

Application sets MQPMO_SYNCPOINT in the put message options. MQPUT returns success when the message is accepted into the UoW. CURDEPTH on the queue may not increase for other consumers until commit—exact visibility rules depend on share options and whether the getting application is the same connection. Batch producers often put hundreds of messages with SYNCPOINT then one MQCMIT to reduce commit overhead. If the job abends on message 400, MQBACK removes all 400 from the committed view—recovery replays from checkpoint or resends from source files.

Get Path Under Syncpoint

MQGMO_SYNCPOINT is the foundation of at-least-once consumers. After MQGET, the message is hidden from competing consumers but not deleted until MQCMIT. Process payload, call Db2, call external API, then commit. If processing fails, MQBACK makes the message available again and BackoutCount may increment. Never commit the get before successful processing unless loss is acceptable (at-most-once). Training labs should demonstrate depth unchanged for other consumers during an open UoW.

CICS Syncpoint Commands

EXEC CICS SYNCPOINT commits recoverable resources for the task, including MQ. EXEC CICS SYNCPOINT ROLLBACK backs out. Nested syncpoints in one task commit work done so far—use only when requirements demand partial progress. Abend without rollback leaves the task in doubt; CICS and MQ recovery procedures apply. Pair with the units-of-work tutorial: the task is often the fence.

Global Syncpoint (XA)

Application servers and transaction managers issue prepare and commit across MQ and databases. Your code may call fewer explicit MQCMIT APIs because the manager drives completion. In-doubt transactions after crashes require operator resolution—syncpoint control at global scope is shared between MQ and the transaction manager. Document which beans or modules begin and end global transactions.

Common Mistakes

• Forgetting MQCMIT in a loop—uncommitted gets hold messages until connection ends.
• MQGET without SYNCPOINT then long processing—message already gone if process crashes.
• Committing MQ while database work is still in a separate non-XA transaction.
• Assuming syncpoint implies persistent—DEFPSIST and MQMD still matter.

Tutorial: Consumer Loop MQSC and MQI Concept

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
MQI consumer pattern:
  loop:
    MQGET Q, MD, GMOD with MQGMO_SYNCPOINT + MQGMO_WAIT
    if error -> handle
    validate MD and payload
    if invalid -> MQBACK; continue
    update database / call service
    if failure -> MQBACK; continue
    MQCMIT   /* message removed, work durable */
 
CICS equivalent:
  MQGET ...
  process
  EXEC CICS SYNCPOINT
  on failure: EXEC CICS SYNCPOINT ROLLBACK

Explain Like I'm Five: Syncpoint

You are holding three library books at the desk. Until the librarian stamps your card as done, nobody else can borrow those copies. If you decide you do not want them, you hand them back and pretend you never checked them out—that is rollback. Stamp the card and leave—that is commit.

Practice Exercises

Exercise 1: Visibility

App A puts with SYNCPOINT but does not commit. What should App B see on CURDEPTH? What changes after MQCMIT?

Exercise 2: Failure

Consumer gets with SYNCPOINT, crashes before commit. Describe message state and BackoutCount behavior.

Exercise 3: CICS

Task MQGET then abend before SYNCPOINT. What happens to the message on the queue?

Frequently Asked Questions

Test Your Knowledge