Distributed IBM MQ queue managers introduce themselves by name when they open channel connections. QMGR mapping—CHLAUTH TYPE(QMGRMAP)—lets your queue manager decide whether QM_PARIS, QM_LONDON, or an unknown name may bind to CLUSRCVR or RCVR channels and which MCAUSER to use if they are accepted. Cluster estates depend on this heavily: dozens of members connect to each other repository and message paths. Point-to-point hubs also whitelist partner queue manager names on inbound receivers. Beginners confuse QMGRMAP with the QMGRNAME attribute on outbound channel definitions; QMGRNAME helps your SDR find the partner, while QMGRMAP CHLAUTH rules police who may enter when they call you. This tutorial explains QMNAME in SET CHLAUTH, ALLOW and BLOCK patterns, MCAUSER mapping for cluster members, interaction with cluster repositories, security cautions about name assertion, operational DISPLAY practices, and failure modes when a new cluster member joins without a matching rule.
During channel startup, protocol exchanges carry identifying information including the remote queue manager name in cluster and distributed messaging contexts. QMGRMAP rules compare that name to patterns in the CHLAUTH record. A match triggers ALLOW, BLOCK, or MAP. Wrong name with strict rules produces bind failure and CHLAUTH log entries—support teams should capture the exact name string from the log when requesting new rules. Typos between QM_NYC and QM-NYC have caused multi-hour outages.
| Control | Matches on | Typical channel |
|---|---|---|
| QMGRMAP | Remote QMGR name | CLUSRCVR, RCVR |
| ADDRESSMAP | Source IP | RCVR, SVRCONN |
| SSLPEERMAP | Certificate DN | RCVR, SVRCONN |
| QMGRNAME (channel attr) | Partner for outbound | SDR, CLUSSDR |
1234567SET CHLAUTH('ALLOW.CLUSTER.MEMBERS') TYPE(QMGRMAP) + QMNAME('QM_*') ACTION(ALLOW) DESCR('Cluster members pattern') SET CHLAUTH('ALLOW.PARTNER.HUB') TYPE(QMGRMAP) + QMNAME('QM_PARTNER') ACTION(ALLOW) CHNAME('PARTNER.TO.US') SET CHLAUTH('MAP.CLUS.MEMBER') TYPE(QMGRMAP) + QMNAME('QM_WEST') MCAUSER('cluswest') USERSRC(MAP) ACTION(ALLOW) DISPLAY CHLAUTH('ALLOW.PARTNER.HUB') ALL
Wildcard QMNAME patterns depend on IBM MQ release syntax—validate in lab before production. Explicit per-member rules are verbose but clear in audits. MAP assigns MCAUSER for puts from that member—grant OAM only on queues that member should reach via cluster routing.
Cluster receivers accept connections from cluster senders presenting member queue manager names. Repository updates and message forwarding assume trusted members. When adding QM_NEW to the cluster, update QMGRMAP (or default cluster rules) on every member that must accept QM_NEW inbound before go-live. Partial updates cause one-way cluster symptoms—some paths work, others CHLAUTH block. Document cluster naming standards so QMNAME patterns remain maintainable.
A hub RCVR may allow only QM_SPOKE1 and QM_SPOKE2 via QMGRMAP while ADDRESSMAP limits IP. Spoke SDR presents hub name on outbound; hub QMGRMAP validates spoke name on inbound. Spoofing risk on private MPLS may be acceptable; on internet, require TLS client certs and SSLPEERMAP in addition to QMGRMAP. Never rely on name alone across public internet.
QMGRMAP checks the company name on the delivery van badge. If the badge says a warehouse you do not recognize, the dock refuses entry—even if the van came from a familiar street (IP).
QMGR mapping is a rule that says only queue managers with these names may connect to our MQ doors.
Add QM_NEW to a three-member cluster—list QMGRMAP updates on each member.
Compare when to trust QMGRMAP alone versus require SSLPEERMAP.
Parse a CHLAUTH block log line and write the SET CHLAUTH fix.
1. QMGRMAP matches:
2. QMGRMAP is common on:
3. QMGRMAP alone on internet should be avoided without:
4. SET CHLAUTH TYPE for QMGRMAP is: