Channel Status

Channel status tells operators whether distributed IBM MQ can move messages between queue managers right now. A payment hub may show healthy queue depths locally while a sender channel sits in RETRYING—funds messages pile on the transmission queue invisible to teams watching only application queues. DISPLAY CHSTATUS is the authoritative MQSC view; Prometheus exporters and APM tools like Instana and Dynatrace surface the same states as metrics for paging and trends. This tutorial explains channel instance versus definition, common CHSTATUS values and what each means for operations, monitoring sender versus receiver versus server-connection channels, mapping status codes in metrics systems, alert design for not RUNNING conditions, pairing channel status with XMITQ depth and listener health, and beginner troubleshooting when status flaps during network or TLS changes.

Instances vs Definitions

DEFINE CHANNEL creates PARIS.TO.LONDON with CHLTYPE(SDR) and attributes like CONNAME and XMITQ. Starting the channel or automatic start when messages arrive creates an instance recorded in CHSTATUS. Multiple instances can exist for some channel types in advanced scenarios; beginners focus on one SDR instance per name per queue manager. If CHSTATUS shows no instance, the channel may be INACTIVE—not an error if no messages trigger start and policy uses trigger or manual START.

Common CHSTATUS values (operational meaning)
StatusMeaningTypical action
INACTIVENo active instanceSTART if work pending; else normal idle
BINDINGTCP/TLS handshake in progressWait briefly; check TLS and firewall if stuck
RUNNINGSession up, messages can flowNone if MSGS moving; verify rates
RETRYINGFailed connect or break; retry timer activeCheck partner listener, CHLAUTH, sequence numbers
STOPPEDStopped by operator or errorRead AMQERR, RESET CHANNEL if needed, fix root cause
PAUSEDFlow paused by operator commandRESUME when maintenance complete

DISPLAY CHSTATUS Essentials

shell
1
2
3
4
5
6
7
8
DISPLAY CHSTATUS('PARIS.TO.LONDON') ALL * Key fields for monitoring: * STATUS — RUNNING, RETRYING, etc. * CHTYPE — SDR, RCVR, SVRCONN, etc. * MSGS — messages sent or received on instance (direction depends on type) * BYTES — volume indicator * LASTMSGDT — time of last message (staleness check) * CONNAME — partner address for outbound types

Run DISPLAY CHSTATUS on both queue managers during incidents. Sender RETRYING on QM_PARIS while receiver shows no BINDING attempt suggests firewall blocking outbound CONNAME or wrong port. Receiver BINDING forever with sender RUNNING may be CHLAUTH on inbound MCAUSER.

Which Channels to Monitor

  • Tier-1 SDR channels to critical remote sites—alert if not RUNNING five minutes.
  • RCVR channels on hub queue managers—pair with partner SDR status.
  • Cluster sender channels when cluster traffic is business critical.
  • SVRCONN only when client connectivity SLA requires it—high cardinality if all clients listed.

Do not alert on every test channel in RETRY left intentionally down in development. Tag objects in documentation or use separate queue managers for non-production noise isolation.

Metrics Export and Dashboards

Exporters translate STATUS to integers for PromQL comparisons. Document the mapping in your runbook: for example 2 equals RUNNING in a given exporter version—never assume across versions without checking release notes. Grafana stat panels color red when status not equal RUNNING for channel label in tier1 list. Combine with ibmmq_channel_msgs_total rate to detect zombie RUNNING sessions that are up but not moving messages—status green but MSGS flat while XMITQ grows suggests stuck protocol or inhibited puts.

Correlate with Transmission Queue and Listener

  1. XMITQ depth rising and SDR not RUNNING — channel or network problem.
  2. SDR RUNNING and XMITQ rising — partner not committing or batching delay; check remote.
  3. RCVR not RUNNING on hub — inbound partner cannot connect; check LISTENER and firewall.
  4. SVRCONN failures — client issue; CHSTATUS on SVRCONN plus client error logs.

Events and Accounting

Channel events to the event queue can notify on state changes when CHINT and event configuration enable them—useful when scrape interval is sixty seconds and you need faster notification on STOPPED. Channel accounting records give historical bytes and batch counts for capacity planning, complementing real-time CHSTATUS metrics.

Maintenance and Alert Fatigue

Planned STOP CHANNEL during certificate rotation should silence alerts in Alertmanager or Grafana for the maintenance window. Document expected BINDING duration during TLS renegotiation tests so NOC does not escalate brief yellow states. After DR failover, channels may need RESET CHANNEL and sequence number alignment—status may show STOPPED until operators complete runbook steps.

Explainer: Highway Ramp Light

Channel status is the ramp meter light on the freeway on-ramp—RUNNING means cars merge; RETRYING means the meter keeps flashing red because the merge failed; XMITQ is cars stacked on the ramp.

Explain Like I'm Five: Channel Status

Channel status is whether the tunnel between two toy rooms is open, closing, or broken. If it is broken, toys pile up in the tunnel entrance waiting room (transmission queue).

Practice Exercises

Exercise 1

Write an alert rule in plain English: SDR PAY.TO.HUB not RUNNING for five minutes, severity critical.

Exercise 2

Given RUNNING but XMITQ depth rising for one hour, list four checks beyond restarting the channel.

Exercise 3

Map five CHSTATUS values to colors for a NOC dashboard legend.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. Healthy transferring sender channel status is usually:

  • RUNNING
  • INACTIVE only forever
  • REQUESTING on RCVR only
  • BINDING forever

2. DISPLAY CHSTATUS shows:

  • Active channel instances
  • Only queue depth
  • JCL job count
  • CF structure size

3. RETRYING status often means:

  • Connection or partner problem
  • Queue is full
  • Successful batch end
  • All messages browsed

4. When SDR not RUNNING, check XMITQ because:

  • Messages cannot leave
  • DLQ deletes itself
  • MAXDEPTH doubles
  • TLS expires
Published
Read time21 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation