In IBM MQ documentation and operations meetings, application queue means a queue your business programs own—the place orders, payments, inventory updates, and audit events live until a consumer processes them. Technically that is almost always a local queue with USAGE(NORMAL), GET and PUT enabled for the right principals, and attributes tuned for volume and reliability. It is not a transmission queue holding messages for a channel, not the dead-letter queue, and not an initiation queue feeding a trigger monitor unless your application design explicitly uses triggering. Beginners drown in object types; this tutorial draws a bright line around application queues: what they are, how they differ from infrastructure queues, how naming and security conventions work, and how application queues relate to work queues, reply queues, cluster queues, and alias queues in real integrations.
When a COBOL CICS program, a Java microservice, or a .NET client calls MQPUT, the destination is normally an application queue (directly or through a QALIAS). The queue manager stores the message on disk or in memory according to persistence, honors syncpoint if the put is in a unit of work, and increments CURDEPTH. A consumer MQGETs the same message, processes it, and commits. That loop is the heart of message-oriented middleware. Application queues are where SLA metrics like depth, age of oldest message, and put/get rates are monitored.
| Role | Object type | USAGE |
|---|---|---|
| Application queue | QLOCAL | NORMAL |
| Transmission queue | QLOCAL | XMITQ |
| Dead-letter queue | QLOCAL (system) | NORMAL |
| Initiation queue | QLOCAL | NORMAL (trigger) |
| Remote routing | QREMOTE | N/A (definition only) |
DEFINE QLOCAL creates the physical storage for messages on that queue manager. Attributes you set here define the application experience: MAXDEPTH caps backlog; MAXMSGL caps size; DEFPSIST sets default durability; SHARE and DEFSOPT control competing consumers; BOTHRESH and BOQNAME implement poison handling; TRIGGER and PROCESS automate scaling. Remote queues (QREMOTE) and alias queues (QALIAS) are often part of the application path but do not replace the target QLOCAL where messages ultimately rest for processing.
123456DEFINE QLOCAL('ORDERS.APP.IN') REPLACE + DESCR('Inbound orders for OMS consumers') + USAGE(NORMAL) MAXDEPTH(500000) MAXMSGL(4194304) + GET(YES) PUT(YES) SHARE(YES) DEFPSIST(YES) + DEFSOPT(SHARED) BOTHRESH(5) BOQNAME('ORDERS.BO') DISPLAY QLOCAL('ORDERS.APP.IN') USAGE GET PUT DEFPSIST
Picture two kinds of bins in a warehouse. Application queues are bins where workers pick and pack customer orders—what the business cares about. Transmission queues are conveyor belts to the loading dock for trucks going to another warehouse (another queue manager). If you toss customer orders on the conveyor belt by mistake, the trucks ship orders away before anyone packed them, and dashboards show the wrong queue growing. Keeping business data on application queues with USAGE NORMAL is basic hygiene.
Applications may be configured to put to ORDERS.IN while operations define QALIAS(ORDERS.IN) pointing at ORDERS.APP.IN or at a QREMOTE that routes to a cluster. That indirection lets you move backends without recompiling every program. The application queue in an architectural diagram is still the QLOCAL (or cluster queue instance) that holds bytes at rest. Teach developers which names are aliases and which are the monitoring point for depth.
Application queues inherit DEFPSIST for messages that do not specify persistence on the put. Financial flows almost always use persistent messages and syncpoint on get so unprocessed work rolls back on failure. Non-persistent traffic suits metrics where restart loss is acceptable. Message type (MQMT_REQUEST, MQMT_REPLY, MQMT_DATAGRAM) lives in the descriptor, not the queue object—but request/reply designs pair application queues for requests and replies.
Each pattern uses the same object type; the difference is naming, attributes, and consumer design. See the dedicated tutorials for work, reply, and backout queues.
Application queues hold regulated data. Restrict PUT and GET with OAM or equivalent on distributed platforms. Log administrative changes to definitions. Consider message-level encryption for payloads leaving the data center. Application queues on shared systems need clear ownership in CMDB entries so auditors know which system of record each queue feeds.
Given SYSTEM.DEAD.LETTER.QUEUE, PAYMENT.XMIT.QM2, ORDERS.WORK.IN, and TRIGGER.INITQ—identify which are application queues and which are infrastructure. Display USAGE on each QLOCAL and document who may PUT and GET.
An application queue is the mailbox where your program's letters wait for your program's friend to read them—not the mailbox the post office uses to send mail to another city.
Write DEFINE QLOCAL for a new audit application queue with persistence, poison handling, and shared consumers.
Explain why putting business messages on a transmission queue is an architecture error.
Map a three-tier flow: web app put, alias, remote, target application queue on another QM.
1. Application queues typically have USAGE:
2. Messages on application queues are retrieved by:
3. QREMOTE is primarily:
4. DEFPSIST(YES) on an application queue means: