MQRC 2009: Connection broken

What it means

The queue manager, or the network path to it, went away while the application was connected. The call that noticed it fails with MQCC_FAILED and reason 2009. If the call was an MQGET waiting with MQGMO_WAIT, the wait ends with 2009. From then on, the old connection handle and every object handle opened under it are useless.

For a local (bindings) application, 2009 usually means the queue manager ended or failed. For a client application it more often means the TCP connection broke. A firewall dropped an idle session, the server-connection channel was stopped, or a network error closed the socket. IBM warns that on a client, a call that returns 2009 may in fact have completed on the queue manager. Treat the outcome of that one call as unknown.

Uncommitted work in the unit of work is backed out when the queue manager coordinates it. The program must reconnect, reopen its queues, and redo the work.

Common causes

• The queue manager was stopped, failed or switched over, for example during maintenance or a multi-instance or HA failover.
• A firewall or load balancer dropped a TCP session it thought was idle. Long MQGET waits on client connections are a common victim.
• An administrator stopped the server-connection channel instance or ended the connection, for example with STOP CHANNEL or STOP CONN on distributed MQ.
• A network error such as a reset socket, a cable or VPN drop, or a client host that was suspended.
• A client channel hit a channel limit (MAXINSTC or MAXINST on the channel, or the queue manager's overall limit, MaxChannels in qm.ini or MAXCHL on z/OS) and was ended. A new connection refused for this reason normally gets 2537 instead.
• On z/OS IMS, the IMS adapter connection to the MQ subsystem isn't active.

How to find the problem

1. Check whether the queue manager is running. Use dspmq on distributed MQ. On z/OS, check the MSTR address space and the CSQ messages in SYSLOG.
2. For client applications, read the queue manager error log (AMQERR01.LOG) and the client's own error log at the time of the failure. Look for messages about a receive error or a channel ending, which show which side closed the socket.
3. Use DISPLAY CHSTATUS(APP.SVRCONN) ALL to see current instances, and compare HBINT and KAINT with the timeouts on firewalls in the path.
4. Check the time pattern. Failures after a fixed idle time, such as exactly 30 or 60 minutes, point to a firewall or load balancer timeout.
5. On z/OS IMS, issue /DIS SUBSYS to see whether the MQ subsystem connection is active.

How to fix it

• Make the application reconnect. Catch 2009, back out if needed, connect again with MQCONN or MQCONNX, reopen its queues and retry, with a pause between attempts.
• For clients, consider automatic client reconnect (MQCNO_RECONNECT, or the reconnect options on a JMS connection factory) so short outages are handled for you.
• Lower the channel heartbeat interval (HBINT) below the firewall idle timeout so the session never looks idle. Ask the network team for the timeout value.
• On z/OS IMS, start the subsystem connection with /STA SUBSYS. CICS applications don't call MQCONN, because the CICS adapter connects for them.
• Make the program safe to retry, because the last call before 2009 may have worked on a client.

What it looks like

JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2009' ('MQRC_CONNECTION_BROKEN').

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.