A queue manager is more than a daemon that holds messages. It is the security gate, the transaction coordinator for queue operations, the router between local and remote destinations, the publisher of events to monitoring tools, and the recovery engine after power loss. MQ Series documentation has always described the queue manager as providing messaging and queuing services; in modern IBM MQ 9.x those services span on-prem, containers, and cloud images with the same core responsibilities. This page walks through each duty in depth so beginners know what to expect when they connect, put, route over a channel, or restart after maintenance.
The queue manager accepts MQCONN from bindings-mode programs on the same host or from remote clients through a listener and server-connection channel. Each connection has a handle; each open queue has another handle. The queue manager schedules access so concurrent MQPUT and MQGET operations remain consistent with SHARE options and syncpoint boundaries. Client libraries (.NET, Java, C, Python) are thin layers over the same services; the queue manager remains authoritative.
All DEFINE objects belong to one queue manager name. The queue manager loads the repository at startup, applies ALTER at runtime, and persists changes. It resolves alias and remote queue names at put time so applications use stable logical names. When you DELETE an object, the queue manager removes catalog entries and may remove underlying storage depending on object type and options.
| Area | What the queue manager does | What operations configures |
|---|---|---|
| Messaging | MQPUT/MQGET, depth, ordering options | MAXDEPTH, DEFPSIST, monitoring |
| Security | CONNAUTH, TLS, OAM checks | AUTHREC, CHLAUTH, certificates |
| Recovery | Log write, checkpoint, restart | Log sizing, backup, strmqm |
| Routing | XMITQ, channel agents | CHANNEL, LISTENER, CONNAME |
| Pub/Sub | Topic routing, retained messages | TOPIC, SUB, cluster topics |
When DEFPSIST is YES or the message is marked persistent, the queue manager must survive process failure without losing accepted messages. It writes log records before acknowledging syncpoint commit to disk (subject to platform sync settings). Non-persistent messages may stay in memory for speed; they can disappear on unclean shutdown. The queue manager chooses how to map queues to files or media; administrators tune log size and disk speed because every persistent put touches the log path.
Under syncpoint, puts and gets are visible to other applications only after MQCMIT (or implicit commit when NO SYNCPOINT is used, depending on options). MQBACK rolls back uncommitted changes on that connection. The queue manager tracks which messages are current versus logically removed. This is how a COBOL batch program can read a message, update DB2, and commit both—or back out the get if SQL fails. Distributed two-phase commit involves the queue manager as a resource manager speaking XA to a transaction manager.
Before MQCONN succeeds, CONNAUTH and TLS may validate identity. On each MQOPEN, the OAM checks whether the principal has +get, +put, +inq, or +dsp as defined in AUTHREC. Channel exits and CHLAUTH can block entire connection attempts based on IP, certificate DN, or asserted user name. The queue manager fails closed: missing authority returns MQRC_NOT_AUTHORIZED (2035), not silent success. Security is centralized so individual applications do not each implement login logic for messaging.
Sender channels read transmission queues and send data to partner receiver channels. The queue manager starts and stops channel agents, honors BATCHSZ and HBINT, retries on network failure, and increments sequence numbers to detect gaps. Listeners accept inbound TCP or LU62 connections. Without these components, remote queue definitions would be useless names—the queue manager would have nowhere to forward work.
For topics, the queue manager matches publications to subscriptions, including wildcard topic strings. Durable subscriptions retain interest across subscriber disconnects. Clustered topics propagate definitions and traffic across members. Pub/sub is not a separate product process you install beside MQ; it is a queue manager responsibility activated when topics and subscriptions exist.
Linear logs (and on z/OS, CF and page set structures) record object changes and persistent message activity. After an unclean stop, restart replays logs to rebuild consistent queue state. The queue manager can emit configuration, performance, and security events to queues or subscribers for Splunk, Instana, or custom monitors. FDC files capture internal diagnostics when components fail assertions—operations uses them with IBM support.
Each is started and supervised by the queue manager; they are not optional extras in a typical production deployment.
On z/OS, a queue manager may join a queue sharing group, using Coupling Facility structures for shared queues across LPARs. It integrates with SMF accounting, uses EBCDIC in many payloads, and may be administered with CSQ commands. Responsibilities remain the same conceptually; the implementation uses system-managed storage and sysplex awareness.
1234567891011121314# Connection and authority (after CONNAUTH configured) # amqsputc / amqsgetc test put/get # Persistence and depth echo "DISPLAY QLOCAL('ORDERS.IN') MAXDEPTH CURDEPTH DEFPSIST" | runmqsc QM1 # Syncpoint (conceptual MQI) # MQBEGIN or MQPUT under syncpoint, MQCMIT or MQBACK # Channel responsibility echo "DISPLAY CHSTATUS('TO.PARTNER')" | runmqsc QM1 # Events (if enabled) echo "DISPLAY QMGR EVENT" | runmqsc QM1
The queue manager is the post office boss. It checks IDs at the door (security), puts letters in the right boxes (storage), keeps a notebook of every box that exists (repository), sends trucks to other towns (channels), and if the lights go out, uses a backup notebook to remember which letters were already accepted (logs). It does not read your letter for you—that is your app with MQGET.
A Java client gets MQRC 2035 on MQOPEN. List three queue manager responsibilities involved in diagnosing it.
A program MQPUTs under syncpoint but crashes before MQCMIT. What does the queue manager do with the message?
Draw a diagram: application, queue manager, listener, channel, remote queue manager.
1. MQPUT authority is checked by:
2. Persistent messages survive restart because the queue manager:
3. Channels move messages:
4. MQCMIT on a connection tells the queue manager to: