Channel States

IBM MQ channels are not simply on or off—they move through a defined lifecycle visible in DISPLAY CHSTATUS. Operations teams live in these states: a sender stuck in RETRY explains growing transmission queue depth; a receiver in BINDING forever points to TLS or firewall problems; PAUSED may be deliberate during maintenance. Beginners who only know DEFINE CHANNEL miss half the troubleshooting story because the definition is static while the instance state changes second by second. This tutorial explains each major channel state and substate, how message channels differ from MQI channels in what RUNNING means, how states transition during normal puts, what operators should do in each state, and how channel states relate to listeners, sequence numbers, and retry timers covered in sibling pages.

Definition vs Instance Status

DEFINE CHANNEL creates an object in the repository. When traffic needs the link, the queue manager creates a channel instance—a running process context tied to that definition. DISPLAY CHANNEL shows CHLTYPE, CONNAME, XMITQ, and other static attributes. DISPLAY CHSTATUS shows STATUS, SUBSTATE, LASTMSGDATE, CHTYPE, and error information for active instances. One definition can have zero instances (INACTIVE at the instance level) or, for SVRCONN, multiple concurrent instances when many clients connect.

INACTIVE: Waiting to Start

Most channel definitions spend most of their time without a running instance. A sender channel becomes active when a message appears on its transmission queue (if triggering is configured) or when an operator issues START CHANNEL. Until then, CHSTATUS may show no row or INACTIVE. This is normal—not an error. Do not confuse INACTIVE with a broken channel; check whether XMITQ depth should have triggered activity.

BINDING: Handshake in Progress

BINDING is short in healthy systems: the sender resolves CONNAME, TCP connects to the listener, TLS negotiates if enabled, partners exchange channel names and protocol capabilities, and MCAUSER context is established. Long BINDING states often mean the remote listener is down, the wrong port is in CONNAME, certificate trust failed, or CHLAUTH blocked the connection. On the receiver, BINDING appears while accepting the inbound sender. Capture network traces only after verifying basics—ping, listener STATUS, and DISPLAY CHSTATUS on both sides.

RUNNING: Healthy Transfer

For message channels in RUNNING, the sender reads batches from the XMITQ and the receiver writes to target queues or forwarding paths. CURDEPTH on the XMITQ should trend down when consumers on the far end keep pace. For SVRCONN, RUNNING means clients have connected and MQI traffic flows—many instances may show RUNNING with different connection IDs. Monitor MSGS, BYTES, or monitoring metrics appropriate to your release for throughput. RUNNING does not guarantee zero backlog—it means the pipe works.

PAUSED, STOPPING, and STOPPED

• PAUSE CHANNEL — operator holds traffic without deleting the definition; useful during partner maintenance windows.
• STOP CHANNEL — graceful shutdown; instance moves through STOPPING to STOPPED.
• STOPPED — no active transfer; may require START CHANNEL or new XMITQ traffic to restart senders.

Stopping a channel does not delete messages on the transmission queue—they remain until successfully forwarded or moved by administrative action. Coordinate stops with partner teams to avoid half-open batches when possible.

RETRY: Failure with Scheduled Reconnect

RETRY is the state operators notice when alerts fire. The channel attempted to connect or failed mid-session and backs off before trying again. SHORTRTY and SHORTTMR control short retries; long retry intervals apply after repeated failures. LASTCHLERR and associated fields in CHSTATUS point to reason codes—connection refused, SSL handshake failure, sequence number mismatch, and others. Fix root cause rather than only cycling STOP/START. See the channel retries tutorial for timer attributes.

Substates and Additional Detail

SUBSTATE provides finer detail within STATUS—for example distinguishing phases of binding or stopping. Exact substate values vary by release; consult IBM documentation for your version when automating monitors. Scripts should treat STATUS as primary and SUBSTATE as diagnostic enrichment.

Explainer: Traffic Lights for Pipes

Think of channel states as traffic lights for a pipe between buildings. INACTIVE is the light off—no cars moving. BINDING is yellow—cars approaching the intersection. RUNNING is green. RETRY is flashing red—the road is blocked but plows will try again on a schedule. STOPPED is red with a barrier down until someone lifts it.

Tutorial: Inspect States with MQSC

1
2
3
4
5
6
7
DISPLAY CHSTATUS(*) WHERE(CHLTYPE EQ SDR)
DISPLAY CHSTATUS('QM1.TO.QM2') ALL
* Note STATUS, SUBSTATE, XMITQ, LASTMSGTIME, LASTCHLERR
START CHANNEL('QM1.TO.QM2')
* Observe transition INACTIVE -> BINDING -> RUNNING
STOP CHANNEL('QM1.TO.QM2')
DISPLAY CHSTATUS('QM1.TO.QM2')

Message Channels vs MQI Channels

STATUS values apply to both families, but interpretation differs. SDR in RETRY blocks inter-queue-manager forwarding. SVRCONN in RETRY blocks new client connections on that channel name—existing apps may disconnect depending on failure mode. Monitor both CHSTATUS and client error logs for SVRCONN issues.

Operational Playbook

1. XMITQ growing, channel INACTIVE — check triggering, START CHANNEL, automatic define.
2. Stuck in BINDING — listener, CONNAME, TLS, CHLAUTH on receiver.
3. RETRY looping — read LASTCHLERR, fix partner, verify sequence numbers if applicable.
4. RUNNING but remote queue empty — routing, MCAUSER authority, wrong target queue.
5. Planned maintenance — PAUSE or STOP with change record; communicate to partners.

Explain Like I'm Five: Channel States

A channel state tells you whether the phone call between two MQ helpers is not started yet, ringing, talking, on hold, or hanging up to try again later.

Practice Exercises

Exercise 1

Map five STATUS values to the action an operator should take first.

Exercise 2

Why might XMITQ depth rise while STATUS shows RUNNING?

Exercise 3

Write a monitoring rule: alert when SDR to critical partner is RETRY for more than N minutes.

Frequently Asked Questions

Test Your Knowledge