IBM MQI Channels vs Message Channels

IBM MQ uses the word channel for two related but distinct purposes, and mixing them up causes weeks of misdirected troubleshooting. Message channels are the pipes queue managers use to ship messages to each other—sender pairs with receiver, data flows from a transmission queue across TCP (or other transport), and no application program opens the channel directly. MQI channels are the pipes IBM MQ clients use to send MQI calls—MQCONN, MQPUT, MQGET—to a remote queue manager as if they were local bindings. Both show up in DISPLAY CHANNEL output and both use listeners, but the payloads, lifecycle, and security differ. This tutorial compares the two families for beginners, maps CHLTYPE values to each family, explains CONNAME and listeners in both contexts, and gives a decision guide for architects documenting interfaces.

Two Families, One Product

Message channels implement store-and-forward between queue managers. When a message cannot be delivered locally and routing points to another queue manager, it lands on a transmission queue; the queue manager starts or uses a sender channel to push protocol data to the partner receiver channel. MQI channels implement remote procedure-style access: the client serializes API requests; the queue manager executes them against local objects. A payment service in Kubernetes might use only SVRCONN to QM_MAIN; QM_MAIN and QM_BRANCH might use only SDR/RCVR to exchange settlement files encapsulated as messages.

Message Channel Types in Detail

• SDR (sender) — active outbound; connects to partner CONNAME; reads XMITQ.
• RCVR (receiver) — passive inbound; accepts connection from partner sender.
• SVR (server) — hybrid in traditional hub patterns; partner uses requester.
• RQSTR (requester) — initiates to server channel on schedule or demand.
• CLUSSDR / CLUSRCVR — cluster variants publishing and receiving cluster traffic.

Channel names must match on both sides of a pair (with cluster rules for cluster channels). Sequence numbers, heartbeat intervals, and retry attributes apply to message channels. TLS and CHLAUTH protect inter-queue-manager links the same way as client links.

1
2
3
4
5
6
DEFINE CHANNEL('QM1.TO.QM2') CHLTYPE(SDR) TRPTYPE(TCP) +
  CONNAME('qm2.example.com(1414)') XMITQ('QM2') +
  MCAUSER('mqm')
DEFINE CHANNEL('QM1.TO.QM2') CHLTYPE(RCVR) TRPTYPE(TCP) +
  MCAUSER('mqm')
* On QM2: matching RCVR name QM1.TO.QM2

MQI Channel Types in Detail

• SVRCONN — defined on the queue manager that hosts queues; referenced by clients and by CHLAUTH rules.
• CLNTCONN — optional mirror definition on client describing host, port, and channel name for MQCONNX.

The client does not put messages onto the channel as onto a queue—it issues MQPUT to QUEUE.NAME after connecting. Channel authentication records map TLS distinguished names or usernames to MCAUSER for authorization. Connection sharing (client reconnect options) affects how many TCP sessions you see per SVRCONN name in displays.

1
2
3
4
5
DEFINE CHANNEL('APP.PAYMENTS.SVRCONN') CHLTYPE(SVRCONN) TRPTYPE(TCP) +
  MCAUSER('payapp') MAXMSGL(4194304)
DEFINE LISTENER('LISTENER.TCP') TRPTYPE(TCP) PORT(1414) +
  CONTROL(QMGR) IPADDR('*')
START LISTENER('LISTENER.TCP')

Explainer: Freight Train vs Telephone

Message channels are freight trains between warehouses—full of crates (messages), scheduled when the loading bay (XMITQ) has crates ready. MQI channels are a telephone line between your desk and the warehouse office—you ask the clerk to move crates (API calls) without you driving the train yourself. You need trains between warehouses and phones for remote clerks; they are not interchangeable.

Listeners Serve Both

A LISTENER object accepts inbound TCP connections. Receiver channels wait for partner senders; SVRCONN channels wait for clients. The port in CONNAME must match the listener. Firewall rules often allow one port for many channel names distinguished after the TCP handshake. Misconfigured listeners produce errors that look similar from client and sender perspectives—always check which channel type is involved before tuning HBINT on the wrong object.

Monitoring and Displays

DISPLAY CHSTATUS shows running instances—CHTYPE distinguishes SDR from SVRCONN. Message channel problems correlate with XMITQ depth and delayed partner delivery. SVRCONN problems correlate with client connection errors, CHLAUTH failures, and MCAUSER authority. Do not clear a stuck XMITQ by creating a SVRCONN with the same name; object types are not interchangeable.

Design Checklist

1. Inter-QM business flow — message channels + transmission queues + remote/cluster definitions.
2. Remote application to central QM — SVRCONN + listener + OAM on queues.
3. Both on same QM — separate channel names and auth for ops clarity.
4. Document in runbooks which topology each interface uses.
5. Test TLS and CHLAUTH for each family independently.

Explain Like I'm Five: Two Channel Kinds

Message channels are trucks between two MQ cities. MQI channels are walkie-talkies so your toy robot (client program) can tell the city hall (queue manager) what to do without living in the city.

Practice Exercises

Exercise 1

Classify five CHLTYPE values into message or MQI family.

Exercise 2

A developer says their app opens the sender channel—correct the statement and describe the real flow.

Exercise 3

List three symptoms that indicate an XMITQ/message channel issue vs an SVRCONN issue.

Frequently Asked Questions

Test Your Knowledge