Application Queues

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.

Definition: Queues Applications Put and Get

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.

Queue roles in a typical estate
RoleObject typeUSAGE
Application queueQLOCALNORMAL
Transmission queueQLOCALXMITQ
Dead-letter queueQLOCAL (system)NORMAL
Initiation queueQLOCALNORMAL (trigger)
Remote routingQREMOTEN/A (definition only)

Local Queues as the Default Application Queue

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.

shell
1
2
3
4
5
6
DEFINE 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

Explainer: Application vs Plumbing Queues

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.

Naming and Lifecycle Conventions

  • Use hierarchical names: FACILITY.FUNCTION.DIRECTION (ORDERS.PAYMENT.IN).
  • Separate .IN and .OUT or .REQ and .REP for request/reply pairs.
  • Document whether a queue is work, notification, or audit—same object type, different SLAs.
  • Align OAM profiles with application IDs; avoid shared queues without shared accountability.
  • Version major interface changes with new queue names rather than breaking in-place semantics.

Alias and Remote in the Application Path

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.

Persistence, Syncpoint, and Message Types

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.

Patterns Built on Application Queues

  1. Work queue — one inbound application queue, many consumers.
  2. Reply queue — dedicated application queue for responses in request/reply.
  3. Backout queue — application queue receiving poison messages from BOQNAME.
  4. Event queue — application queue feeding monitoring or event hubs.
  5. Staging queue — short-lived buffer before batch pickup.

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.

Security and Compliance

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.

Tutorial: Classify Queues in a Sample Estate

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.

Explain Like I'm Five: Application Queues

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.

Practice Exercises

Exercise 1

Write DEFINE QLOCAL for a new audit application queue with persistence, poison handling, and shared consumers.

Exercise 2

Explain why putting business messages on a transmission queue is an architecture error.

Exercise 3

Map a three-tier flow: web app put, alias, remote, target application queue on another QM.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. Application queues typically have USAGE:

  • NORMAL
  • XMITQ
  • DLQ
  • TOPIC

2. Messages on application queues are retrieved by:

  • Application programs
  • Sender channel only
  • LDAP
  • Only the command server

3. QREMOTE is primarily:

  • Routing definition to a remote QLOCAL
  • CF structure
  • Channel type
  • Listener

4. DEFPSIST(YES) on an application queue means:

  • Default persistent messages survive restart
  • No syncpoint
  • USAGE XMITQ
  • No GET
Published
Read time15 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation