The receiver channel (CHLTYPE RCVR) is the inbound half of point-to-point distributed MQ. While the sender at the remote site connects to your CONNAME, the receiver accepts the session, validates the partner, and instructs the queue manager to put messages onto local queues. Misconfigured receivers are why transmission queues grow on the far side while your listener shows no connections—firewall blocks, wrong port, or CHLAUTH denying the sender MCAUSER. This tutorial covers DEFINE RCVR, listener dependencies, security at the inbound edge, monitoring inbound CHSTATUS, RCVR versus CLUSRCVR, and troubleshooting patterns for beginners who administer the data center that receives traffic.
A LISTENER object binds to TCP port 1414 (example). Multiple channel types may share the port: RCVR channels for message partners, SVRCONN for clients. When a sender connects, the queue manager associates the TCP session with the RCVR definition whose name matches the protocol exchange. Messages deserialize into local puts. The sending queue manager removes messages from XMITQ only after protocol commit rules succeed—receiver disk and authority matter.
| Aspect | RCVR | SDR (partner) |
|---|---|---|
| TCP role | Listen | Connect out |
| CONNAME | Not required | Required |
| XMITQ | No | Yes |
| Starts | When partner connects | XMITQ work or START |
123456DEFINE LISTENER('TCP.LISTENER') TRPTYPE(TCP) PORT(1414) CONTROL(QMGR) START LISTENER('TCP.LISTENER') DEFINE CHANNEL('PARIS.TO.LONDON') CHLTYPE(RCVR) TRPTYPE(TCP) + MCAUSER('mqm') HBINT(300) * Partner QM_PARIS defines same name as SDR with CONNAME to this host:1414 DISPLAY CHSTATUS('PARIS.TO.LONDON')
MCAUSER on RCVR is the user under which inbound messages are put unless overridden by protocol or message context per IBM rules for your release. Grant this user put authority to target QLOCAL objects and remove authority from overly broad IDs.
The receiver is the warehouse dock that only opens when a truck identifies itself with the right paperwork (channel name). The listener is the street address where trucks arrive. If the address is wrong on the sender van (CONNAME), trucks never reach your dock even though your dock is ready.
Inbound receivers are high-value targets: a rogue sender with a matching name and broken security could inject messages. Pair technical controls with change management on CHANNEL definitions.
DISPLAY CHSTATUS shows RCVR instances in BINDING or RUNNING when senders connect. Multiple senders do not share one RCVR name from different unauthorized partners if CHLAUTH is correct—each legitimate pair uses agreed names. MSGS and BYTES counters help capacity planning. Absence of instances while partner XMITQ grows points to network or listener failure on your side.
Messages arrive with routing from the sending side—remote queue name, cluster headers, or reply-to context. The receiver queue manager resolves to QLOCAL puts. Authority failures send messages to DLQ or block channel with errors depending on configuration. Test with non-production senders before production cutover.
CLUSRCVR accepts cluster sender connections and participates in cluster repository updates. Production clusters often have multiple CLUSRCVR definitions. Point-to-point RCVR is simpler: one partner SDR, one name, one listener port often shared. Document which listeners serve which channel sets.
The receiver channel is the door you open when your friend's delivery van calls your house—the van has to know your address and your name on the intercom must match what you agreed.
Write MQSC for LISTENER plus RCVR for one inbound partner.
Partner SDR in RETRY—list checks on receiver QM only.
Why share one listener port for RCVR and SVRCONN?
1. Receiver channel CHLTYPE is:
2. RCVR waits for connection on:
3. XMITQ on RCVR is:
4. Channel names for SDR/RCVR pair must: