Sender and Receiver Concept

The sender and receiver channel pair is the workhorse of distributed IBM MQ: two queue managers, one logical pipe, messages flowing from a transmission queue on the sending side to application or forwarding queues on the receiving side. The sender (SDR) dials; the receiver (RCVR) answers. Same channel name on both sides, different CHLTYPE. If you understand only one channel pattern deeply, make it this one—almost every remote queue, cluster sender, and hub-and-spoke design builds on it. This tutorial walks through initiation, XMITQ binding, CONNAME and listeners, batching and sequence numbers at a conceptual level, MCAUSER flow, common failure states, and how sender/receiver differs from server/requester and from SVRCONN client channels.

The Pair in One Diagram (Words)

On QM_BOSTON, application MQPUT to a QREMOTE or cluster route places messages on XMITQ.TO_CHICAGO. When the queue manager needs to forward, it starts channel BOSTON.TO.CHICAGO type SDR. SDR reads XMITQ.TO_CHICAGO, opens TCP to chicago.example.com(1414) from CONNAME, and negotiates with RCVR channel BOSTON.TO.CHICAGO on QM_CHICAGO. RCVR accepts the connection, receives message batches, and the queue manager puts them to the target QLOCAL on QM_CHICAGO. Consumers on Chicago MQGET from their application queue—never from the channel object itself.

Defining the Pair

Administrators coordinate naming conventions with partners. Channel names often embed direction: PAY.QM1.QM2. On QM1 define SDR with XMITQ pointing at the transmission queue that holds traffic for QM2. On QM2 define RCVR with the identical channel name. Both use TRPTYPE(TCP) in typical estates. MCAUSER on each side should be a user with authority to put to target queues on the receiver and to read the XMITQ on the sender. Mismatched MCAUSER causes authorization failures that appear as channel errors or backout on the transmission queue.

1
2
3
4
5
6
7
8
9
10
* === On QM1 (sending) ===
DEFINE QLOCAL('XMIT.QM2') USAGE(XMITQ)
DEFINE CHANNEL('QM1.TO.QM2') CHLTYPE(SDR) TRPTYPE(TCP) +
  CONNAME('qm2.corp.example(1414)') XMITQ('XMIT.QM2') +
  MCAUSER('mqm') BATCHSZ(50) HBINT(300)
* === On QM2 (receiving) ===
DEFINE CHANNEL('QM1.TO.QM2') CHLTYPE(RCVR) TRPTYPE(TCP) +
  MCAUSER('mqm')
DEFINE LISTENER('TCP.1414') TRPTYPE(TCP) PORT(1414)
START LISTENER('TCP.1414')

Explainer: Outbound Truck and Inbound Dock

The sender is a truck leaving the Boston warehouse loading bay (XMITQ). CONNAME is the GPS address of the Chicago dock. The receiver is the dock door that must be open (listener running) with a sign matching the truck's paperwork (channel name). If the dock is closed or the sign wrong, the truck circles (RETRY) until someone fixes the dock or the address.

When the Channel Starts

By default many queue managers use automatic channel triggering when a message appears on the transmission queue—DISCINT and related attributes tune disconnect after idle. Operators can START CHANNEL manually for testing. The receiver does not START in the same way—it becomes active when the listener accepts the inbound connection. PING CHANNEL from the sending side tests whether the receiver path is reachable without moving application messages.

Sequence Numbers and Batching

Message channels assign sequence numbers to batches for recovery. If the link drops mid-batch, partners reconcile on reconnect—operations see messages on XMITQ until successfully transferred. BATCHSZ and BATCHLIM influence how many messages travel per network unit. Heartbeat HBINT detects silent failures so channels do not hang forever in RUNNING while the network is dead. Deep troubleshooting belongs in the channel sequence numbers tutorial; here the takeaway is that sender/receiver are stateful protocols, not raw TCP streams.

Server and Requester (Brief Contrast)

In some firewall-constrained networks, the queue manager behind the firewall cannot accept inbound TCP. A server (SVR) channel on the secure side pairs with a requester (RQSTR) on the outside that periodically connects and pulls work—reversing who initiates TCP while preserving message direction semantics. Sender/receiver is simpler when outbound connections from the sending QM are allowed.

Common Problems

1. Channel name typo between QM1 and QM2—BINDING or protocol errors.
2. CONNAME wrong port or DNS—channel RETRY, XMITQ depth grows.
3. Listener down on receiver—sender cannot connect.
4. CHLAUTH or TLS mismatch—connection refused or SSL errors in CHSTATUS.
5. No XMITQ or wrong XMITQ on SDR—sender has nothing to read or wrong queue.
6. MCAUSER lacks authority on target QLOCAL at receiver.

Tutorial: Trace One Message Across the Pair

Put a test message to a QREMOTE targeting QM2. Confirm depth on XMITQ on QM1. DISPLAY CHSTATUS for the SDR—expect RUNNING. On QM2 confirm target QLOCAL depth increased and XMITQ on QM1 decreases after commit. Stop the listener on QM2 and observe sender enter RETRY—restore listener and confirm recovery.

Explain Like I'm Five: Sender and Receiver

The sender channel is you calling your friend; the receiver channel is your friend picking up the phone. You both have to agree it is the right phone call (same channel name) or nobody talks.

Practice Exercises

Exercise 1

Write MQSC for a minimal SDR/RCVR pair including XMITQ and listener.

Exercise 2

XMITQ depth is 5000 and channel is RUNNING but remote queue empty—list four checks.

Exercise 3

Explain when you would choose requester/server instead of sender/receiver.

Frequently Asked Questions

Test Your Knowledge