A queue in IBM MQ is a named mailbox on a queue manager. Applications do not send bytes directly to each other over sockets for business payloads—they hand work to MQ as messages, and the queue manager stores each message on a queue until a consumer is ready. That single idea powers decoupling, buffering during outages, and horizontal scaling with many consumers. If you understand queues, the rest of MQ (channels, clusters, pub/sub) becomes easier because almost everything eventually lands on or leaves from a queue. This page defines queues from scratch: put and get, open and close, local versus remote names, how queues relate to the repository, persistence, depth, and how queues differ from topics.
Administrators create a queue with DEFINE QLOCAL('ORDERS.IN') (or remote, alias, model types). The queue manager records attributes—MAXDEPTH, DEFPSIST, GET, PUT—in the object repository. The queue also has runtime state: current depth (how many messages waiting), open handles, and last put/get times on many platforms. DISPLAY QLOCAL shows definition; DISPLAY QSTATUS shows live depth. The name is up to 48 characters on typical platforms; naming standards keep environments readable.
Each step can fail with MQ reason codes: not authorized (2035), unknown object (2085), queue full (2053). Client libraries wrap the same flow in Java JMS, Python, .NET, and COBOL. The queue name string in code must match the repository definition unless you use QALIAS indirection.
| Concept | Stores messages? |
|---|---|
| QLOCAL | Yes—on this queue manager |
| QREMOTE | No—routing pointer to remote queue |
| QALIAS | No—another name for a queue |
| CHANNEL | No—moves messages in flight |
| TOPIC | No—routes to subscriber queues |
Without MQ, Service A calls Service B synchronously—both must be up, and slow B blocks A. With a queue between them, A MQPUTs and continues; B MQGETs when ready. The queue holds the backlog if B is down (until MAXDEPTH). That buffer is why batch, mainframe, and cloud microservices all still use queues decades after MQ was invented.
A message has a descriptor (MQMD) and payload. Persistence (persistent vs non-persistent) controls whether the message survives queue manager restart. Priority, expiry, correlation ID, and reply-to queue name ride in the descriptor. The queue does not interpret business JSON or COBOL copybooks—it stores bytes. Applications agree on format. Poison messages that fail processing may move to backout or dead-letter queues after retry limits.
From the producer view, you often put to one name. If it is QLOCAL, storage is local. If it is QREMOTE, the queue manager forwards to another queue manager via transmission queue and channel. If it is a cluster queue, cluster repository and channels choose the path. Beginners should trace one put in a diagram: application → queue object → (optional channel) → target queue.
A queue delivers each message to one consumer (competing consumers share work). A topic delivers copies to every matching subscription. Use queues for jobs and commands; use topics for events many systems observe. Some architectures use both: event on topic, command on queue.
1234567DEFINE QLOCAL('LAB.HELLO') REPLACE MAXDEPTH(1000) * Put a test message (distributed): echo 'Hello MQ' | amqsput LAB.HELLO QM1 * Get it back: amqsget LAB.HELLO QM1 DISPLAY QLOCAL('LAB.HELLO') CURDEPTH IPSPROCS OPSPROCS * CURDEPTH should be 0 after successful get
Operations teams define permanent queues through MQSC, GitOps, or Terraform. Developers request names via change control. Model queues (QMODEL) let applications create temporary dynamic queues for request/reply—those queues disappear when the application closes them. Shared queues on z/OS QSG are still queues but stored in CF structures as described in other tutorials.
A queue is a line at the ice cream counter. The person taking orders (producer) hands cups to the line (queue). Workers (consumers) take one cup at a time from the front. If workers are slow, the line gets longer until it hits the shop rule for maximum line length (MAXDEPTH).
Draw a diagram: App1 MQPUT → QLOCAL → App2 MQGET. Label connect, open, put, get.
Why does QREMOTE not store messages? Where do they sit while in transit?
Name three reason codes you might see on first MQOPEN to a mistyped queue name.
1. MQPUT adds a message to:
2. After one successful MQGET with default options, the message:
3. A queue name is defined in:
4. Queues are primarily used for: