Full repository queue managers are the authoritative librarians of an IBM MQ cluster. When a member defines a new cluster queue or queue manager joins the cluster, full repositories record that knowledge on SYSTEM.CLUSTER.REPOSITORY.QUEUE and propagate updates to partial repository members. Without healthy full repositories, applications see stale routes, cluster puts fail with unknown object, or traffic sticks to outdated instances after failover. Beginners often configure cluster channels and CLUSTER on queues but skip REPOS—then wonder why QM_B never learns about ORDERS.IN on QM_A. This tutorial explains ALTER QMGR REPOS, pairing two full repositories for availability, how full repos differ from partial repos, DISPLAY and maintenance commands, failure modes, performance considerations, and operational runbooks when migrating repository role to a new host.
1234567ALTER QMGR CLUSTER('SALES') CLUSNL('SALES') ALTER QMGR REPOS('SALES') DISPLAY QMGR REPOS REPOSNL CLUSTER * On second HA member QM_NYC: ALTER QMGR CLUSTER('SALES') CLUSNL('SALES') ALTER QMGR REPOS('SALES') * Partial members use REPOSNL only - see partial repositories tutorial
REPOS accepts one cluster name per ALTER on typical configurations—verify IBM documentation if multiple clusters need full repos on same QM. Both full repository queue managers must reach each other via cluster channels and agree on cluster name spelling. Typo SALES versus SALE breaks synchronization.
Repository messages describe cluster members: queue manager names, network addresses, cluster queues, cluster channels, and related attributes needed for workload routing. This is metadata—not a copy of your business messages. Size grows with cluster object count; unusually large clusters monitor repository queue depth and CPU on full repo hosts.
| Aspect | Full (REPOS) | Partial (REPOSNL only) |
|---|---|---|
| Catalog completeness | Holds complete cluster definition set | Receives updates from full repos |
| Count per cluster | Usually 2 | All other members |
| Failure impact | Critical—lose both and cluster routing at risk | Can often restart; refreshes from full |
| CPU load | Higher—publishes updates | Lower—consumer of updates |
| ALTER command | REPOS(cluster) | REPOSNL(cluster) without REPOS |
Place full repositories on different physical hosts, power domains, or zones. During maintenance, restart one full repo while the other serves updates—avoid simultaneous bounce of both. Document which queue managers hold REPOS in cluster runbook. After disaster recovery, verify REPOS attribute on replacement QMs before accepting application traffic.
Partial repository queue managers use REPOSNL to subscribe to cluster name updates. They request or receive repository publishes from full members. Delay between DEFINE CLUSTER queue on QM_APP and visibility on QM_REMOTE is normal seconds-level—mass bulk defines may take longer. REFRESH CLUSTER or repository recovery commands on your release may be needed after extended outages—consult IBM MQ cluster recovery documentation.
Full repositories are the main library that holds the master card catalog. Branch libraries (partial repos) copy updates from the master. If both master libraries burn down, branches only have old photocopies.
Two teachers keep the official class list for every school in the district. Other schools copy from those teachers. If both teachers are away and nobody has the list, new kids do not know which classroom to visit.
Write MQSC to configure two full repos for cluster PAY.
Why not run zero full repositories?
List four symptoms of full repository outage.
1. Full repository is set by:
2. Typical full repo count is:
3. Repository data lives on:
4. REPOSNL means: