Chapter seven of a typical IBM MQ curriculum covers cluster queues and channels first; topics arrive later in publish/subscribe modules as TOPTYPE(CLUS) and fan-out behavior. From a cluster objects perspective, topics are first-class citizens in the repository alongside queues: a TOPIC definition with CLUSTER(name) and TOPTYPE(CLUS) registers a branch of the topic tree on that queue manager and advertises it to full and partial repositories so remote members can honor subscriptions and forward publications without bespoke channel wiring per publisher-subscriber pair. Operators who understand cluster queues but treat topics as purely local often see subscriptions on QM_PARIS never receive publications from QM_LONDON even though cluster queues work—because no cluster topic object joined the catalog, or CLUSTER names disagree, or scope attributes block propagation. This tutorial positions cluster topics inside the cluster object model, contrasts them with local topics, explains administrative parents and CLUSTER alignment with CLUSNL, repository sync and DISPLAY commands, security parallels with cluster queues, performance cautions for wide topic trees, and how this page connects to the clustered topics pub/sub tutorial for end-to-end design.
When you DEFINE TOPIC with TOPTYPE(CLUS) and CLUSTER('SALES'), the queue manager records the topic in its local repository and publishes metadata into the cluster catalog. Other members learn that a topic string or topic name exists on QM_LON under cluster SALES. Pub/sub engine components use that metadata when an application publishes to a topic string or when a subscription is created with scope that allows cluster-wide interest. The CLUSTER attribute is the same string used on DEFINE QLOCAL CLUSTER('SALES')—consistency across object types keeps repository indexes coherent. A topic with CLUSTER(PAYMENTS) on a queue manager whose CLUSNL namelist omits PAYMENTS will not integrate correctly; fix membership before debugging pub/sub.
| TOPTYPE | CLUSTER attribute | Typical reach |
|---|---|---|
| LOCAL | Optional / usually blank | Defining queue manager only |
| CLUS | Required cluster name | Cluster members per scope rules |
| ALIAS | Points at target topic | Depends on target |
| Administrative | Often CLUS at root | Structures subtree for children |
12345678ALTER QMGR CLUSTER('SALES') CLUSNL('SALES') DEFINE TOPIC('SALES.ORDERS') TOPTYPE(CLUS) CLUSTER('SALES') + TOPSTR('Orders/') DESCR('Order events cluster root') DEFINE TOPIC('SALES.ORDERS.NEW') TOPTYPE(CLUS) CLUSTER('SALES') + TOPICSTR('Orders/New') PARENT('SALES.ORDERS') DISPLAY TOPIC('SALES.ORDERS') TOPTYPE CLUSTER * On full repository member: DISPLAY CLUSTOPIC('SALES.ORDERS') CLUSTER('SALES')
TOPICSTR and TOPIC name define how applications and subscriptions resolve strings. PARENT links children to administrative topics for hierarchy. CLUSTER must match the cluster you intend for repository fan-out. After definition, allow time for repository sync on partial members—DISPLAY on a remote partial repository should eventually show the topic; if not, check cluster channels, REPOSNL, and full repository health before opening pub/sub tickets.
Full repository queue managers hold authoritative cluster object definitions including topics. Partial repositories receive updates over cluster channels. The mechanism mirrors cluster queues: not every member hosts every topic definition locally until needed, but routing metadata must be reachable. Stale cache symptoms include subscriptions that exist locally but publications never arrive from remote publishers—operators compare DISPLAY TOPIC on publisher QM, DISPLAY CLUSTOPIC or equivalent on repository host, and subscription DEST queue depth on subscriber QM. Message data never sits in the repository; only names, strings, and attributes travel the catalog.
Cluster-wide pub/sub scales better when domain roots are administrative TOPTYPE(CLUS) topics with CLUSTER set, and application topics hang beneath them. Flat hundreds of unrelated CLUS topics without PARENT structure complicates DISPLAY and security policy. Topic authorization tutorials apply per object; cluster topic security extends to which members may define or alter cluster-visible topics. Change a parent CLUSTER without updating children and you fragment the tree—use REPLACE carefully and verify propagation.
Cluster queues solve which instance of PAYMENT.IN receives a point-to-point message. Cluster topics solve which queue managers participate in interest for a topic string and where publications copy. Both rely on cluster channels and repository health. Workload attributes CLWLPRTY and friends apply to queues, not topics; topic routing uses PUBSCOPE, SUBSCOPE, and subscription location instead. Architects should document both patterns in the same cluster name when an domain uses request/reply on queues and events on topics together.
A cluster topic is like posting on a company bulletin board that every office building in the chain can see the title of—not the full poster stored in headquarters, but the index card saying Orders/New exists and which building posted it. Mail copies still go building to building over the roads you already built (cluster channels).
Very broad topic strings with cluster scope can fan out many copies per publication. Retained messages and durable subscriptions multiply disk and channel load. Prefer narrow topic trees and explicit administrative parents. Load-test cluster pub/sub separately from cluster queue workload tests—channel bandwidth may be adequate for queues but saturated by event storms. Coordinate with the topic clustering best practices tutorial for naming conventions.
Cluster topics are like telling every branch of your toy store chain that the New Toys section exists, so when headquarters announces a new toy, each branch knows to listen and put a copy in the right bin.
Write MQSC for an administrative CLUS topic and one child topic under the same CLUSTER name.
List three differences between cluster queue routing and cluster topic routing.
Publication works on QM1 but not QM2—write a five-step DISPLAY checklist.
1. Cluster pub/sub topic TOPTYPE is:
2. CLUSTER on a topic must align with:
3. Repository stores for cluster topics:
4. Administrative topic at domain root: