Every queue manager maintains a repository of objects—a structured catalog of everything messaging depends on except the messages themselves. When you DEFINE QLOCAL, DEFINE CHANNEL, or ALTER LISTENER, you are writing to this repository. When an application MQOPENs ORDERS.IN, the queue manager looks up ORDERS.IN in the repository, checks authority, and attaches the program to the real queue data structures. Beginners often picture messages floating in a generic cloud; in IBM MQ, both the definitions and the message data have well-defined homes. This tutorial explains local object repositories, how definitions load at startup, how DISPLAY and export tools read the catalog, and how cluster full and partial repositories extend the idea across many queue managers.
IBM MQ object types include queues (local, alias, remote, model), channels, listeners, topics, subscriptions, namelists, process definitions, authentication information objects, storage classes, and security records such as AUTHREC and CHLAUTH. Each object has a name, a type, and many attributes (MAXDEPTH, CHLTYPE, CONNAME, and hundreds more). The repository stores these attributes; altering an object updates the repository and may change runtime behavior immediately or on the next open, depending on the attribute.
| Object type | Purpose |
|---|---|
| QLOCAL | Stores messages; CURDEPTH is live queue state |
| QREMOTE / QALIAS | Routing and indirection without code changes |
| CHANNEL | Logical path between queue managers |
| LISTENER | Network entry point for inbound connections |
| TOPIC / SUB | Publish/subscribe topology |
| AUTHREC | Who may connect, put, get, or administer |
Think of two layers. The repository is the card catalog in a library: title, shelf location, loan rules. Messages are the books on the shelf. DISPLAY QLOCAL shows catalog cards (MAXDEPTH, DEFPSIST, GET, PUT). To read a book, you MQGET from the queue. Deleting a message does not delete the queue definition; deleting the queue object (DELETE QLOCAL) removes the catalog entry and, with options, the messages. Backup strategies often export definitions with dmpmqcfg separately from queue data backups.
Administrators use runmqsc, MQ Explorer, REST admin, Terraform providers, or Ansible roles to issue DEFINE and ALTER. The command server process accepts MQSC and applies changes to the in-memory repository, then persists to disk so strmqm after reboot reloads the same names and attributes. Scripted promotion from DEV to TEST to PROD is literally copying or merging repository content under change control. A typo in ALTER CHANNEL can stop a partner connection even though no application code changed—because applications depend on the repository names and attributes remaining correct.
During queue manager startup, the queue manager reads persisted object definitions into memory. If files are damaged, startup may fail or require recovery utilities. After start, DISPLAY QMSTATUS confirms the manager is running; DISPLAY QLOCAL(*) lists what loaded. Dynamic objects (temporary dynamic queues, some subscriptions) are created at runtime and may not survive restart unless defined as permanent. The repository manager component (covered in a later tutorial) participates in cluster repository replication on some platforms.
In an MQ cluster, queue managers publish cluster queue and cluster channel definitions so partners can route without manual remote definitions on every node. Full repository queue managers retain the authoritative superset of cluster-published definitions. Partial repository members hold subsets and refresh from full repositories when they join or when objects change. Planning typically uses two full repositories on different hosts for availability. If a full repository is unavailable, cluster administration and new bindings can degrade until it returns—operations monitor repository queue managers closely.
DISPLAY is read-only inspection of the repository. Compare exports across environments to find drift—TEST missing a channel attribute PROD relies on. Many teams store dmpmqcfg output in Git and diff on pull requests. DISPLAY QLOCAL CURDEPTH is special: CURDEPTH is runtime state on the queue object, not merely a static definition, but it is still shown alongside definitional attributes in one command for convenience.
12345678910# Interactive MQSC echo "DISPLAY QMGR" | runmqsc QM1 echo "DISPLAY QLOCAL(*) TYPE(QLOCAL)" | runmqsc QM1 echo "DISPLAY CHANNEL(*) CHLTYPE(SDR)" | runmqsc QM1 # Export all definitions to a file for backup or Git dmpmqcfg -m QM1 -a > QM1-objects.mqsc # Search export for a queue name grep "DEFINE QLOCAL('ORDERS.IN')" QM1-objects.mqsc
Applications embed object names in code or config: queue ORDERS.IN, channel TO.PARTNER. Renaming requires ALTER plus application or CCDT updates. Alias queues reduce rename pain by indirection. Repository discipline—naming standards, ownership tags in descriptions, documented ALTER history—prevents the mystery objects that accumulate in decade-old estates.
The queue manager keeps a big list of all mailboxes and roads (definitions). When you build a new mailbox, you add it to the list. When a friend wants to mail something, the post office looks at the list to see if that mailbox exists and what rules it has. The list is not the letters inside the mailbox—just the rules and the name.
Explain to a teammate why DISPLAY QLOCAL does not show message bodies.
Your cluster has QM_A and QM_B as full repositories and twelve others as partial. QM_A fails. What might still work? What might break for new cluster bindings?
DEV export adds DEFINE CHANNEL(TO.HUB) but PROD already has TO.HUB with different CONNAME. How do you merge safely?
1. Object definitions in IBM MQ are created primarily with:
2. A full repository in a cluster:
3. DISPLAY QLOCAL(ORDERS.IN) shows:
4. After ALTER QLOCAL, apps see changes when: