MQRC 2024: Syncpoint limit reached

What it means

Messages put or got under syncpoint stay uncommitted until the application commits or backs out. The queue manager keeps a count for each unit of work and refuses the call that would push it over MAXUMSGS. That call fails with MQCC_FAILED and reason 2024. The work already done in the unit of work is still there, uncommitted.

The count includes more than the application's own puts and gets. Trigger messages and confirm-on-arrival reports that the queue manager creates for syncpoint puts count too, and so do confirm-on-delivery reports for syncpoint gets. IBM also notes that publishing to a topic can hit the limit, even when the publisher didn't ask for syncpoint, because publications can be delivered to subscribers inside a unit of work.

The limit stops one runaway unit of work from filling the log. A program that loops, or a batch job that never commits, reaches it first.

Common causes

• A batch program processes thousands of messages under syncpoint and commits only at the end of the run.
• On z/OS IMS, a BMP gets or puts messages but never takes an IMS checkpoint (CHKP or SYNC), so the MQ unit of work keeps growing. In IMS the checkpoint is what commits MQ work.
• On CICS, a long-running task never issues EXEC CICS SYNCPOINT, so everything it did is still in one unit of work.
• A JMS transacted session or XA transaction that sends or receives many messages before commit.
• The program is looping and puts or gets the same messages over and over.
• Publishing to a topic with many subscribers, where the copies delivered to subscribers inside a unit of work can add up to the limit.

How to find the problem

1. Check the current limit with DISPLAY QMGR MAXUMSGS in runmqsc, or the same command with the command prefix on z/OS.
2. Count how many messages the program handles between commits. Look for MQCMIT, EXEC CICS SYNCPOINT, IMS CHKP or SYNC, or session.commit() and see how far apart they are.
3. Use DISPLAY CONN(*) TYPE(CONN) UOWSTATE UOWLOGDA UOWLOGTI to find long-running units of work, and DISPLAY QSTATUS(...) TYPE(QUEUE) UNCOM to see which queues hold uncommitted changes.
4. If the counts look far too high for the data, look for a loop. A program that rereads its own output queue, or backs out and gets the same message again, is a common pattern.

How to fix it

• Commit more often. Taking a syncpoint every few hundred or thousand messages keeps the unit of work small and also shortens restart and backout time.
• In IMS BMPs, take regular checkpoints. In CICS, add EXEC CICS SYNCPOINT at a sensible interval in long tasks.
• Fix any loop before raising the limit. A higher limit only lets a runaway job write more log.
• If the workload really needs bigger units of work, raise the limit with ALTER QMGR MAXUMSGS(n). On IBM i use CHGMQM. Check log space first, because large units of work keep log extents active longer.
• After 2024 the program should back out or commit what it has, depending on its design, and not just retry the failed call inside the same unit of work.

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s MQ documentation for your version.