Reason code 2009—MQRC_CONNECTION_BROKEN—is what applications see when their conversation with IBM MQ ends unexpectedly. The job was happily doing MQGET in a loop; then the next call returns 2009 because the TCP session died, the queue manager restarted, or an operator quiesced the instance during maintenance. Unlike 2059 on first connect, 2009 means you were in the building and the lights went out. Beginners retry the same stale Hconn handle forever; correct code paths MQDISC, reconnect, MQOPEN again, and handle duplicate messages if the broken call happened mid-transaction. This tutorial explains failure timing, firewall idle timeout math, queue manager restart behavior, client reconnection attributes, channel versus application connection layers, idempotent consumer design, and coordinated testing with network teams.
Any MQI call on a broken connection may return 2009—MQPUT after network drop, MQGET after QM restart, MQCMIT during quiesce. Some clients return 2009 on the call that detects the break; others on the subsequent call. Log call name, object handle validity, and whether syncpoint was active. In-flight transactions may be indoubt—coordinate with MQ transaction and XA documentation before assuming commit state.
| Code | When | Recovery |
|---|---|---|
| 2009 | Session was up; link lost | Reconnect, reopen |
| 2059 | Cannot attach to QM | Fix QM/listener/name |
| 2538 | TCP to host fails | Network, DNS, port |
| 2195 | Other connection errors (version-specific) | See reason text |
A MQGET with long wait (MQGMO_WAIT with thirty minute interval) sends no traffic on the socket. Stateful firewalls drop the session at fifteen minutes idle. The queue manager still holds the logical connection until the client wakes and gets 2009. Mitigations: shorter wait intervals with loop, heartbeat traffic where supported, firewall exception for MQ ports with longer idle, or reconnect-enabled client. Document firewall idle timer in integration specs—not only MQ timeouts.
12345* Planned maintenance: endmqm -i QM_PROD * Clients see 2009; after strmqm: strmqm QM_PROD * Applications must reconnect — automate health checks
endmqm quiesce allows graceful stop; immediate stop breaks connections faster. Communicate maintenance windows; enable client reconnection where possible. Multi-instance failover may produce 2009 during switch—applications should tolerate brief outage.
Java, .NET, and C clients support automatic reconnect options on MQCONNX when using supported channel and security configurations. Reconnection re-establishes TCP and may restore some handles depending on version—not all applications qualify. Read IBM client reconnection limitations: incompatible with some XA managers, certain security exits, or non-idempotent one-shot programs. Test reconnect in performance environment with forced TCP reset (iptables DROP) not only graceful endmqm.
Application 2009 on SVRCONN does not automatically explain SDR RETRY to remote site—check both during datacenter incidents. Partner may see transmission queue growth while your apps see 2009 on local QM restart. Runbooks should list both checks.
2009 is a phone call that dropped mid-sentence—you redial (reconnect) and ask what was last heard (idempotent retry).
You were talking through a tin-can string and the string broke. You need a new string (connection) to keep talking.
Design a GET loop that survives fifteen-minute firewall idle without 2009.
Write reconnect pseudocode: DISC, CONNX with reconnect option, reopen queue, resume GET.
List data integrity risks if MQCMIT was in flight when 2009 occurred.
1. 2009 means:
2. 2009 often needs:
3. Idle firewall timeout causes:
4. Reconnection options help: