Subscription Propagation

Subscription propagation is how IBM MQ tells the cluster that a consumer on QM_PARIS wants messages about prod/retail/order/# so that when a publisher on QM_LONDON emits an event, the routing layer knows to forward copies. Without propagation, each queue manager is an island: local publish matches local subs only. Propagation depends on SUBSCOPE, clustered topic definitions, healthy CLUSSDR and CLUSRCVR channels, and repository synchronization between full and partial repositories. Beginners confuse propagation with message movement—propagation is interest registration across the topology; delivery happens later on publish. This tutorial explains SUBSCOPE ALL versus QMGR, administrative ASPARENT subs, repository timing, DISPLAY and status commands, failure modes when channels flap, and capacity when many propagated subs multiply remote routing work.

Local Registration Versus Cluster Advertise

DEFINE SUB with SUBSCOPE(QMGR) registers only on the local queue manager object repository. Publications from remote members do not target that interest unless other mechanisms bridge queue managers. SUBSCOPE(ALL) adds cluster advertisement—remote publishers participating in cluster pub/sub can include that subscriber in fan-out calculations. Choosing scope is an architecture decision affecting security, bandwidth, and operations visibility.

Propagation Timeline Example

1. Administrator DEFINE SUB on QM_PARIS with SUBSCOPE(ALL) and TOPICSTR prod/events/#.
2. Queue manager records subscription and advertises to cluster infrastructure.
3. Repository processes update partial repositories on other members.
4. Publisher on QM_LONDON later publishes prod/events/order/created.
5. Engine matches local and propagated interest; delivery puts to QM_PARIS DEST over cluster channel.

1
2
3
4
5
6
DEFINE TOPIC('EVENTS.CLUS') TOPSTR('prod/events') TOPTYPE(CLUS) +
  CLUSTER('CORP') PUBSCOPE(ALL) SUBSCOPE(ALL)
DEFINE SUB('EVENTS.PARIS') TOPICSTR('prod/events/#') +
  DESTQL('EVENTS.PARIS.Q') DESTQMGR('QM_PARIS') SUBSCOPE(ALL) DURSUB(YES)
DISPLAY SUB('EVENTS.PARIS') SUBSCOPE DESTQL
DISPLAY CHSTATUS('CORP.QM_PARIS') WHERE(CHLTYPE EQ CLUSRCVR)

ASPARENT and Administrative Topics

When administrative cluster topic EVENTS.CLUS sets SUBSCOPE(ALL), child subscriptions with SUBSCOPE(ASPARENT) inherit propagation behavior—reduces inconsistent subs under the same domain. Changing parent SUBSCOPE requires impact analysis on all ASPARENT children. Document inheritance in topic catalog.

Troubleshooting Missing Remote Delivery

• Confirm SUBSCOPE is ALL on subscribing QM, not QMGR.
• Verify publisher uses topic under CLUS parent with matching PUBSCOPE.
• Check cluster channels RUNNING both directions.
• Wait for repository sync after new SUB—retry publish after delay in lab.
• DISPLAY SUB on publishing QM—some releases show propagated interest views.
• Authority on remote DEST and topic still required on each node.

Performance and Propagation Storms

Thousands of SUBSCOPE(ALL) subscriptions with # patterns increase repository churn and routing tables. Prefer fewer administrative subs with broader patterns over per-application ALL subs on every QM. Consolidate analytics to dedicated subscriber queue managers.

Explainer: Sign-Up Sheet Copied to Every Office

Propagation is photocopying the sign-up sheet to every office in the company so any office that produces news knows who to mail copies to—not mailing the articles themselves yet.

Explain Like I'm Five: Subscription Propagation

You tell every school in the district you want dinosaur news, not just your teacher. Propagation is telling all the schools; delivery is when someone actually sends you the paper.

Practice Exercises

Exercise 1

Compare SUBSCOPE QMGR vs ALL for Paris subscriber and London publisher.

Exercise 2

List five checks when remote publish does not reach DEST.

Exercise 3

Why consolidate ALL subs instead of one per microservice?

Frequently Asked Questions

Test Your Knowledge