# MQRC 2024: Syncpoint limit reached Source: https://wndsoftware.com/mainframe-errors/mqrc-2024 ### MQRC 2024: Syncpoint limit reached MQRC 2024 (MQRC_SYNCPOINT_LIMIT_REACHED, hex 07E8) means an MQGET, MQPUT or MQPUT1 failed because it would take the current unit of work past the queue manager's limit on uncommitted messages. That limit is the MAXUMSGS attribute (MaxUncommittedMsgs in the MQI). #### Other names for this code Also written as `RC2024`, `reason code 2024`, `MQ 2024`, `MQ error 2024`, `MQRC_SYNCPOINT_LIMIT_REACHED`, `07E8`, `0x07E8`, `MAXUMSGS`, `syncpoint limit reached`, `MQ uncommitted messages limit`. ### 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 - Check the current limit with `DISPLAY QMGR MAXUMSGS` in runmqsc, or the same command with the command prefix on z/OS. - 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. - 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. - 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. ### IBM documentation [IBM documentation: MQRC 2024](https://www.ibm.com/docs/en/ibm-mq/9.4.x?topic=codes-2024-07e8-rc2024-mqrc-syncpoint-limit-reached). Use the documentation for your installed release. [Report a correction to WND Software](https://wndsoftware.com/contact#message). Technical reviewer: [Albert Joseph](https://wndsoftware.com/authors/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. ### Related codes [MQRC 2053 MQRC_Q_FULL Read →](https://wndsoftware.com/mainframe-errors/mqrc-2053) [MQRC 2009 MQRC_CONNECTION_BROKEN Read →](https://wndsoftware.com/mainframe-errors/mqrc-2009) [MQRC 2033 MQRC_NO_MSG_AVAILABLE Read →](https://wndsoftware.com/mainframe-errors/mqrc-2033) [MQRC 2071 MQRC_STORAGE_NOT_AVAILABLE Read →](https://wndsoftware.com/mainframe-errors/mqrc-2071) [MQRC 2195 MQRC_UNEXPECTED_ERROR Read →](https://wndsoftware.com/mainframe-errors/mqrc-2195) ### Questions #### What is the default MAXUMSGS value? On most queue managers it is 10,000 unless someone changed it. Check your own value with DISPLAY QMGR MAXUMSGS before planning batch sizes. #### Does 2024 mean my messages are lost? No. The failed call didn't happen, and earlier work in the unit of work is still uncommitted. The program decides whether to commit what it has or back it all out. #### Why does an IMS BMP get 2024 when the same logic works in batch? In IMS, MQ work is committed by IMS checkpoints, not by MQCMIT. A BMP that never takes a checkpoint keeps adding to one unit of work until it reaches the limit. [IBM MQ reason codes](https://wndsoftware.com/mainframe-errors/mq-reason-codes) · [MQRC 2019](https://wndsoftware.com/mainframe-errors/mqrc-2019) · [MQRC 2025](https://wndsoftware.com/mainframe-errors/mqrc-2025) [← All error codes](https://wndsoftware.com/mainframe-errors/)