A queue manager is the heart of IBM MQ—the server process that accepts connections, stores messages on queues, moves traffic over channels, enforces who may put and get, and recovers after failure. MQ Series documentation describes it as the component that provides messaging and queuing services through the Message Queue Interface (MQI). Beginners sometimes conflate the queue manager with a single queue or with the whole enterprise; in practice you deploy many queue managers across datacenters, each with a unique name, each owning thousands of objects. This page defines the queue manager role, lists the object types it controls, contrasts z/OS and distributed deployments, explains how MQI programs connect, and sets context for lifecycle, startup, and shutdown tutorials that follow.
When an order service MQPUTs to ORDERS.IN, the queue manager validates authority, assigns or honors MsgId, logs persistent data, and places the message on the queue. When a fulfillment service MQGETs, the same queue manager coordinates syncpoint. No other queue manager owns that queue unless you route to a remote definition. The queue manager is therefore the transaction coordinator for queue operations on its node—an idea carried forward from MQSeries tutorials that still applies in IBM MQ 9.x.
| Object type | Role |
|---|---|
| QLOCAL | Actual queue storage for messages |
| QREMOTE / QALIAS | Routing and aliasing to other names or QMs |
| CHANNEL | Path to another queue manager |
| LISTENER | Accepts inbound network connections |
| TOPIC / SUBSCRIPTION | Publish/subscribe routing |
| AUTHREC / CHLAUTH | Security policy |
Classic MQI sequence for sending: MQCONN to queue manager name, MQOPEN queue, MQPUT messages, MQCLOSE, MQDISC. Receiving mirrors with MQGET. MQBEGIN, MQCMIT, and MQBACK control units of work. Java JMS, .NET, and Node clients call the same queue manager services through client libraries. On z/OS, batch and CICS programs link to MQ modules; the queue manager may be local to the LPAR or accessed through client channels depending on architecture.
MQ Series defines four queue types beginners still meet daily. Local queue: real storage. Remote queue: definition pointing to a queue on another queue manager. Alias queue: another name for an existing queue—switch destinations without code changes. Model queue: template for temporary dynamic queues in request/reply. All are objects defined to one queue manager even when they reference remote targets.
Channels are not mailboxes for application data long term—they are pipes between queue managers. Sender channels drain transmission queues; receiver channels accept inbound data. Listeners wait on TCP ports (for example 1414) for partner connections. Your queue manager must be running and listening before remote partners can connect.
The queue manager can generate some report messages automatically; applications set options in the MQMD and PMO/GMO for others.
Distributed queue managers use file system logs and queue files (or modern media options per version). z/OS queue managers integrate with Coupling Facility for queue sharing groups, use EBCDIC considerations in payloads, and often sit beside CICS and IMS. The conceptual model—connect, put, get, commit—is the same; operations tooling differs (MQSC, ISPF, Operations and Control Center).
1234567* After installation, queue manager QM1 may exist DISPLAY QMGR ALL DISPLAY QLOCAL(*) CURDEPTH * Application connection (conceptual): * MQCONN('QM1', ...) * MQOPEN('ORDERS.IN', ...) * MQPUT(...)
The queue manager is the post office building for your town. Mailboxes (queues) are inside. Trucks between towns (channels) leave from this building. You must enter the building (connect) before you can drop letters in a mailbox (put) or collect them (get).
List three queue managers in a diagram with channels between them and one queue per manager.
App puts to PAY.REMOTE which resolves to PAY.IN on QM2. Which objects exist on QM1?
Put MQDISC before MQPUT. What goes wrong?
1. Applications connect to IBM MQ using:
2. Messages are stored on:
3. A queue manager acts as transaction coordinator for:
4. Remote queue definitions point to: