2009 Errors

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.

Where 2009 Appears in Application Flow

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.

Connection failure codes compared
CodeWhenRecovery
2009Session was up; link lostReconnect, reopen
2059Cannot attach to QMFix QM/listener/name
2538TCP to host failsNetwork, DNS, port
2195Other connection errors (version-specific)See reason text

Firewall Idle Timeout

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.

Queue Manager Restart and Quiesce

shell
1
2
3
4
5
* 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.

Client Reconnection

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.

Idempotent Consumers

  • After 2009 mid-GET, message may be redelivered or lost depending on syncpoint—design for at-least-once.
  • Use business duplicate detection keys in payload or database.
  • Avoid assuming partial batch committed without MQCMIT success logged.
  • Log correlation IDs across reconnect attempts for support.

Channel Layer Parallel

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.

Troubleshooting Workflow

  1. Correlate timestamp with QM restart, network change, firewall change.
  2. Check AMQERR on server for channel or listener errors same second.
  3. Test TCP stability with sustained traffic—not single ping.
  4. Review client wait intervals versus firewall idle.
  5. Implement reconnect or shorten waits; retest forced failure.
  6. Verify message processing idempotency after recovery.

Explainer: Phone Call Dropped

2009 is a phone call that dropped mid-sentence—you redial (reconnect) and ask what was last heard (idempotent retry).

Explain Like I'm Five: 2009 Errors

You were talking through a tin-can string and the string broke. You need a new string (connection) to keep talking.

Practice Exercises

Exercise 1

Design a GET loop that survives fifteen-minute firewall idle without 2009.

Exercise 2

Write reconnect pseudocode: DISC, CONNX with reconnect option, reopen queue, resume GET.

Exercise 3

List data integrity risks if MQCMIT was in flight when 2009 occurred.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. 2009 means:

  • CONNECTION_BROKEN
  • UNKNOWN_OBJECT
  • NOT_AUTHORIZED
  • Q_FULL

2. 2009 often needs:

  • Reconnect and reopen objects
  • Only ALTER MAXDEPTH
  • DELETE channel
  • Disable logging

3. Idle firewall timeout causes:

  • 2009 on next MQI call
  • 2085 on connect
  • Higher CURDEPTH
  • Automatic DEFINE

4. Reconnection options help:

  • Eligible client applications
  • Only z/OS batch
  • JCL only
  • COBOL compile
Published
Read time21 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation