Every DEFINE QLOCAL, ALTER CHANNEL, and DELETE TOPIC changes more than what DISPLAY shows in memory—it updates the queue manager object catalog on disk and records the change in the log so a future restart knows the object exists with those attributes. The repository manager is the subsystem that owns that catalog: allocating internal tables, serializing definitions to repository files, coordinating with logging for durability, and serving lookups when applications MQOPEN by name. When administrators say the repository is corrupt, they mean this catalog no longer matches what the log expects or files are damaged—symptoms include failure to start, missing objects that were defined yesterday, or DEFINE failing with media or repository return codes. This tutorial separates local repository internals from cluster repository replication, walks through startup load, explains relationship to dmpmqcfg output, covers inconsistency symptoms, and gives safe operational habits for beginners who already know runmqsc but not what happens underneath.
All queue managers maintain a local repository. Cluster members additionally publish cluster object subsets to partners via the cluster repository manager described in the operational repository manager page. Internally both rely on the same catalog technology at the base layer—cluster adds replication messages and full versus partial repository roles. A non-cluster queue manager still runs repository manager logic for every object; it simply skips cluster publication traffic.
| Layer | Scope | Survives restart |
|---|---|---|
| In-memory catalog | Single running QM | Until shutdown if not logged |
| Repository files on disk | Single QM directory | Yes, with log replay |
| Cluster repository cache | Cluster members | Rebuilt from full repos and channels |
Under the queue manager path you find directories such as qmgr, log, and queue data folders. Repository data lives in managed files—not meant for hand editing. The exact file names and split vary by version; IBM documents the layout in platform guides. Administrators should monitor disk on the qmgr volume: a full disk blocks both log extension and repository updates, producing cascading failures that look like mysterious MQRC errors. Permissions must allow only the mqm group (or equivalent) to write—host compromise of that directory is full control of definitions.
123456# Illustrative layout — paths vary by install /var/mqm/qmgrs/QM1/ qmgr/ # repository and control files log/ # write-ahead log queues/ # message data (see persistence tutorial) dspmq -m QM1 # confirms path and status
ALTER changes attributes—MAXDEPTH, DEFPSIST, TRIGGER—by updating the same catalog entry. DELETE marks removal; applications with open handles may retain access until MQCLOSE. Rapid scripted changes during incidents still hit the same path; flooding DEFINE can contend on internal locks discussed in the locking internals tutorial.
During strmqm, after log replay establishes a consistent recovery point, the queue manager loads repository files into memory structures. Channels and listeners defined in the catalog become eligible to start per configuration. A damaged repository before log replay completes may abort startup with AMQ errors referencing repository or media recovery. Operators capture the error, verify disk health, and consult IBM documentation for supported recovery—options may include restoring qmgr from backup taken while queue manager was cleanly ended.
dmpmqcfg exports catalog definitions as a script of MQSC or JSON—not a raw binary copy of repository files. Promotion pipelines replay those scripts on target queue managers, which re-enters the repository manager path on each DEFINE. This is safer than copying binaries because names, paths, and platform differences are visible in diff review. Object promotion tutorials complement this page for DevOps workflows.
Distinguish local corruption from cluster inconsistency: REFRESH CLUSTER addresses cluster sync, not substitute for fixing a broken local qmgr directory. Never delete files in qmgr folder to fix symptoms without IBM support case guidance.
Repository changes are logged like other persistent metadata. Unclean shutdown relies on log replay to redo incomplete catalog transactions. If log and repository disagree after storage failure, supported recovery tools reconcile—manual hex editing is not supported. Pair this topic with logging internals and recovery processing for end-to-end restart understanding.
The repository manager is the clerk who maintains the card catalog for a library—every new shelf label (queue) or rule (channel) gets a card in the cabinet and a note in the daily journal (log) so if the office floods, you can rebuild the catalog from the journal.
Take configuration exports after significant changes. End queue managers cleanly before VM snapshots when possible. Monitor qmgr filesystem separately from message data disks. Restrict who can run DELETE QMGR on shared admin hosts. Version-control dmpmqcfg output in Git with peer review like application code.
The repository manager is the list of all the boxes and tubes in the mail room, written in a book that does not get erased when the lights go out—because we also copy every change into a diary so we can fix the book after a mess.
Run dmpmqcfg on lab QM and identify three object types stored in repository.
After clean endmqm and strmqm, verify DEFINE QLOCAL(TEST.REPO) survives restart.
Map disk mounts for log, qmgr, and queues paths on your platform.
1. Local repository holds:
2. DEFINE QLOCAL updates:
3. Cluster repository is extra when:
4. Manual delete of repo files: