Cluster Receiver Channels

Every outbound cluster sender on a partner queue manager needs somewhere to land. The cluster receiver channel (CHLTYPE CLUSRCVR) is that landing point: it accepts inbound TCP sessions from CLUSSDR definitions, participates in cluster protocol, and enables messages and repository updates to enter the member. If CLUSRCVR is misconfigured or the listener is down, remote members see RETRY on their senders and cluster queues on this machine become unreachable from the rest of the cluster—even when local applications still put and get successfully. This tutorial covers DEFINE CLUSRCVR, listener dependencies, differences from RCVR, security at the cluster edge, monitoring CHSTATUS, and recovery scenarios after network or queue manager failover.

Inbound Cluster Architecture

Cluster membership is not a single cable between two boxes. Each member exposes CLUSRCVR so peers can connect CLUSSDR instances. Repository queue managers aggregate object advertisements; partial repositories on other members subscribe through the same channel family. When QM_EAST receives a CLUSSDR connection from QM_WEST, messages and control flows deserialize into local processing—puts to cluster queues hosted locally, updates to local repository caches, and replies on the same session as required by the protocol. Understanding CLUSRCVR as the front door for peer queue managers prevents misdiagnosing application SVRCONN issues when the real fault is cluster TCP.

CLUSRCVR vs RCVR (inbound comparison)
AspectCLUSRCVRRCVR
Partner CHLTYPECLUSSDRSDR
TopologyCluster mesh / hubPoint-to-point
CONNAME on selfNot requiredNot required
CLUSTER attributeOn channel definitionN/A
Repository roleYesNo

Defining a Cluster Receiver

shell
1
2
3
4
5
6
7
8
DEFINE LISTENER('CLUSRV.TCP') TRPTYPE(TCP) PORT(1414) CONTROL(QMGR) START LISTENER('CLUSRV.TCP') DEFINE CHANNEL('QM_WEST') CHLTYPE(CLUSRCVR) TRPTYPE(TCP) + CLUSTER('INVENTORY') MCAUSER('mqm') HBINT(300) * Partner QM_WEST defines: * DEFINE CHANNEL('QM_EAST') CHLTYPE(CLUSSDR) TRPTYPE(TCP) + * CONNAME('qm_east.corp(1414)') CLUSTER('INVENTORY') DISPLAY CHSTATUS('QM_WEST')

The channel name QM_WEST on QM_EAST is a convention: it identifies which remote member is expected to connect. Partner QM_WEST defines CLUSSDR named QM_EAST with CONNAME pointing here. CLUSTER('INVENTORY') must match on both sides and on CLUSQMGR definitions. MCAUSER on CLUSRCVR influences authorization for inbound work—tighten from default administrative IDs in production.

Explainer: Reception Desk for Sister Stores

If your store chain shares inventory information, CLUSRCVR is the reception desk that accepts deliveries and memos from other stores in the chain. CLUSSDR at the other store is their driver who knows your address (CONNAME). Without your desk open (listener down), their trucks circle the block (RETRY).

Listeners and Ports

CLUSRCVR does not open its own port without a LISTENER. Define LISTENER with TRPTYPE(TCP) and PORT matching what partners place in CONNAME. Many sites use 1414 as a convention but any unused port works if documented. Sharing a port between CLUSRCVR and SVRCONN reduces firewall rules but increases blast radius if a misconfiguration affects all inbound traffic—segmentation is a design choice, not a requirement.

Security and CHLAUTH

Cluster receivers face other queue managers, not end-user laptops, but compromised partners could attempt connections. CHLAUTH should restrict which hosts or certificates may bind to CLUSRCVR names. TLS mutual authentication is common between data centers. Map certificate DNs to MCAUSER where policy requires service accounts per partner. Review default permit rules after upgrades—IBM has tightened defaults across releases.

Monitoring and Capacity

  • DISPLAY CHSTATUS shows RUNNING instances per partner CLUSSDR connection.
  • MSGS and BYTS counters help identify hot links during month-end batch.
  • Multiple concurrent sessions may exist depending on cluster version and configuration—do not assume one session only.
  • Correlate listener errors with simultaneous CHLAUTH failures in the error log.

Failure Scenarios

  1. Listener stopped—all partners RETRY toward this host.
  2. Wrong CLUSTER name—binding failures or partial membership.
  3. Channel name mismatch with partner CLUSSDR—session never reaches RUNNING.
  4. Sequence number drift after restore—coordinate RESET with IBM guidance.
  5. Disk full on receiving QM—channel stops with errors though TCP was fine.

CLUSRCVR and Application Traffic

Remote Java or .NET clients do not use CLUSRCVR—they use SVRCONN. Cluster receivers exist only for queue-manager-to-queue-manager cluster protocol. Teaching developers this boundary saves hours: a failed MQ client connection is rarely fixed by ALTER CLUSRCVR.

Explain Like I'm Five: Cluster Receiver Channels

A cluster receiver is the door other IBM MQ computers in your team use to reach your computer with messages and updates about shared queue names.

Practice Exercises

Exercise 1

Document listener port, CLUSRCVR name, and expected partner CLUSSDR for one cluster member.

Exercise 2

Explain why stopping the listener breaks CLUSRCVR but not local MQGET from a local app.

Exercise 3

Write a short comparison table: CLUSRCVR, RCVR, SVRCONN for inbound TCP.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. Cluster receiver CHLTYPE is:

  • CLUSRCVR
  • CLUSSDR
  • RQSTR
  • XMITQ

2. CLUSRCVR waits for:

  • Partner CLUSSDR to connect
  • Only FTP
  • JCL submit
  • Browse only

3. CLUSRCVR vs RCVR—RCVR pairs with:

  • SDR
  • CLUSSDR
  • CLNTCONN only
  • Topic

4. Listener on cluster member is needed because:

  • Partners must reach CLUSRCVR port
  • Queues cannot exist
  • DLQ is optional
  • No TCP in MQ
Published
Read time17 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation