When you DISPLAY CHSTATUS and see a sender channel in RUNNING with thousands of messages still on the transmission queue, something inside the queue manager is actively dequeuing, framing, encrypting, and pushing those messages across the network. That workhorse is the channel agent—historically called the Message Channel Agent or MCA. Beginners learn to define CHAN.SALES.SDR and CHAN.SALES.RCVR, but the MCA is the running instance that honors those definitions. If the MCA stops, the channel leaves RUNNING even when TCP still looks fine. If the MCA mis-batches or waits on a full partner queue, your XMITQ depth climbs while application puts to the remote queue alias still succeed locally. This tutorial explains what channel agents do, how they differ from listeners and from MQI channels, the sender and receiver roles, batching and flow control, heartbeats and disconnect detection, MCAUSER execution context, interaction with persistence and logging, and how to read symptoms when MCA-related CPU or retries dominate an incident.
An application MQPUTs to a queue that resolves to a remote queue. The queue manager routes the message onto a transmission queue (XMITQ) associated with a message channel. The channel definition names partner CONNAME, CHLTYPE, TLS ciphers, and tuning attributes. None of that moves bits until the MCA runs: it is the protocol engine for inter-queue-manager communication. On the receiving queue manager, a listener thread accepts the inbound connection, negotiates SSL if required, and hands the socket to a receiver MCA paired with the RCVR channel definition. The receiver MCA validates bind parameters, applies CHLAUTH outcomes, and performs local MQPUTs into the target queue or further routing. Both sides report status in DISPLAY CHSTATUS fields such as CHSTATE, MSGS, BYTES, and LASTMSGTIME.
| Role | Primary read | Primary write | Typical CHLTYPE |
|---|---|---|---|
| Sender MCA | Transmission queue | Network socket to partner | SDR, CLUSSDR |
| Receiver MCA | Network socket from partner | Target local or alias queue | RCVR, CLUSRCVR |
| Requester MCA | XMITQ when traffic needs reverse | Socket (bidirectional pattern) | RQSTR paired with SVR |
| Server MCA | Socket and XMITQ as needed | Both directions in turn | SVR on hub QM |
Sender MCAs are pull-driven from the XMITQ: no messages, no batches (though heartbeats may still flow when configured). Receiver MCAs are push-driven from the network: the partner sender determines arrival rate unless local puts block because the target queue is full (MQRC_Q_FULL propagated back through the protocol). When both sides show RUNNING but depth does not fall, suspect receiver put authority, full target queue, or discriminator mismatch—not always "the network is down."
BINDING state visible in CHSTATUS means the MCAs are still negotiating—useful when TLS succeeded but CHLAUTH blocks the bind. RETRY means the MCA exited and the queue manager will attempt again; repeated RETRY with unchanged config wastes hours unless you fix root cause.
BATCHSZ caps how many messages one MCA will try to place in a single protocol batch before sending. Larger batches amortize TCP and TLS round trips on high-latency links—throughput rises. Small messages with BATCHSZ of 50 on a 200 ms RTT link can outperform BATCHSZ of 1 dramatically. BATCHINT is the maximum time the sender waits to fill a partial batch; low traffic may send undersized batches when BATCHINT expires rather than waiting forever for a full BATCHSZ. Setting BATCHSZ to 9999 on a low-volume link can add latency because the first lonely message waits for companions that never arrive until BATCHINT fires. Compare with channel-batching tutorial examples on your lab QM: measure XMITQ depth drain rate, not gut feel.
123456* Illustrative tuning — adjust per workload and IBM doc for your version ALTER CHANNEL(CHAN.SALES.SDR) CHLTYPE(SDR) BATCHSZ(100) BATCHINT(500) HBINT(300) DISCINT(6000
HBINT (heartbeat interval) lets MCAs detect silent partner failure when no messages flow—heartbeats are small protocol traffic, not business messages. DISCINT influences disconnect timing for inactive channels. Values are in different units depending on attribute—always verify DISPLAY CHSTATUS after ALTER and document your estate standard.
Receiver MCA typically puts messages using MCAUSER from the channel definition unless ADOPTCTX or security exits change context. If MCAUSER lacks put authority on the target queue, the receiver MCA may fail puts even when the remote application is trusted on the sending side—classic cross-team bind success, message loss symptom. Sender MCA does not run application code; it forwards bytes representing messages already accepted on the XMITQ under the putting application authority at origin. Misunderstanding this split leads to granting OAM on the wrong queue manager side.
Persistent messages on the XMITQ are logged like other persistent data; the MCA does not skip durability when batching. A batch may contain many persistent messages; commit boundaries follow MQ protocol rules between partners. If the sender QM crashes mid-batch, recovery replays log and XMITQ state; the MCA restarts and may resend messages the partner had not acknowledged. Exactly-once between queue managers still requires application design and idempotency—MCA reliability is at-least-once transport unless you add higher-layer deduplication.
CLUSSDR and CLUSRCVR instances are still MCAs with cluster-aware routing. The MCA may move messages between cluster members using cluster transmission queues and repository knowledge. Repository manager updates do not replace MCA work—they inform which channel instance or route is chosen. When cluster channels flap, check both repository sync and MCA bind errors.
Queue managers are warehouses. Transmission queues are loading docks. The channel definition is the shipping contract (destination, truck type, security seal). The channel agent is the truck driver who actually loads cartons, drives the highway, and unloads at the other warehouse. Applications drop cartons on the dock; they never hold the steering wheel.
DISPLAY CHSTATUS ALL where CHSTATE ne RUNNING. Compare MSGS and BYTES counters on sender versus receiver—divergence hints one side not committing puts. AMQERR messages mentioning channel, MCA, or protocol often include partner QM name. Short strmqtrc on components chl, comm, and ssl around reproduction. Avoid STOP CHANNEL during bulk catch-up unless necessary—draining XMITQ may take longer after stop/start because MCA cold-starts negotiation.
1234DISPLAY CHSTATUS('CHAN.SALES.SDR') ALL DISPLAY QSTATUS('SYSTEM.CHANNEL.SYNCQ') WHERE (CURDEPTH GT 0) * On receiver QM: DISPLAY CHSTATUS('CHAN.SALES.RCVR') ALL
Channel agent concepts align on z/OS, but you may inspect channels with CSQUTIL and operator displays rather than Linux ps output. Shared channels and queue sharing groups add coupling-facility paths; MCAs still move messages between queue managers, sometimes via different buffers. Read z/OS channel topics after mastering distributed MCA mental model.
Channel agents are the robots that carry mail between two post offices. You put letters in the outbox; the robot picks them up, drives to the other post office, and puts them in the right slot there.
On a lab pair, DISPLAY CHSTATUS during a bulk send and record MSGS rate per minute on sender and receiver.
ALTER BATCHSZ up and down; note effect on time-to-drain 10,000 small messages.
Document MCAUSER on RCVR and verify setmqaut grants match the target queue put requirements.
1. Channel agents move:
2. Applications interact with MCA by:
3. Sender MCA reads from:
4. BATCHSZ affects: