Work Queues

A work queue is where IBM MQ earns its keep in most enterprises: producers drop jobs, consumers pick them up when ready, and nobody waits on a synchronous phone call. Whether the payload is a JSON order, a fixed-length COBOL copybook, or a trigger to run batch, the work queue pattern is the same shape. This page describes how to name and define work queues, configure attributes for competing consumers and durability, size depth for outages, integrate triggering and autoscaling, handle poison messages, and distinguish work queues from transmission queues and reply queues—written for beginners building their first integration.

Anatomy of the Pattern

One or more producer applications MQPUT messages to a local queue such as ORDERS.WORK.IN. One or more consumer applications MQGET under syncpoint, process, and MQCOMMIT. Producers and consumers need not run at the same time or on the same server—they only need connectivity to the same queue manager (or cluster). The queue buffers load spikes. Monitoring CURDEPTH answers “how far behind are we?” at a glance.

Essential Queue Attributes

MAXDEPTH caps backlog message count; size for peak (put rate minus get rate) times maximum acceptable delay. DEFPSIST(YES) keeps work across restarts when messages must not vanish. SHARE(YES) and DEFSOPT(SHARED) allow multiple consumer instances; exclusive defaults block scale-out. GET(ENABLED) and PUT(ENABLED) with appropriate security profiles. BOTHRESH(3) and BOQNAME('ORDERS.WORK.BO') isolate poison messages after repeated rollbacks. MAXMSGL must exceed your largest message. Document each choice in your queue catalog spreadsheet.

Competing Consumers

Horizontal scale means N identical programs or container replicas each looping MQGET. IBM MQ guarantees each message goes to one consumer (for standard queues without special browse/commit patterns). Faster consumers receive more messages naturally. Slow consumers create imbalance—use uniform processing time or partition into multiple work queues (ORDERS.WORK.A, ORDERS.WORK.B) keyed by business unit if one heavy message type blocks others. Message priority and MQGMO_WAIT intervals affect fairness; tune in load tests.

Triggering and Autoscaling

Low-volume estates use TRIGGER(YES) TRIGTYPE(FIRST) to start batch when mail arrives. High-volume cloud estates run always-on listeners and scale replica count from CURDEPTH metrics. TRIGTYPE(DEPTH) with TRIGDPTH below MAXDEPTH starts extra workers before queue full. Either approach is valid; mixing undocumented trigger and Kubernetes scale can double-start consumers—coordinate in architecture reviews.

1
2
3
4
5
6
DEFINE QLOCAL('ORDERS.WORK.IN') REPLACE +
  MAXDEPTH(500000) DEFPSIST(YES) SHARE(YES) DEFSOPT(SHARED) +
  BOTHRESH(3) BOQNAME('ORDERS.WORK.BO') +
  TRIGGER(YES) TRIGTYPE(DEPTH) TRIGDPTH(10000) +
  PROCESS('ORDERSVR') DESCR('Inbound work')
DEFINE QLOCAL('ORDERS.WORK.BO') REPLACE MAXDEPTH(10000) DEFPSIST(YES)

Transactions and Idempotency

Consumers should MQGET under syncpoint, process, then commit or rollback. Rollback returns the message for retry and increments BackoutCount toward BOTHRESH. Design handlers idempotent: duplicate delivery after rollback must not double-charge a customer. Work queues do not magically deduplicate—application logic or external idempotency keys do.

Cluster Work Queues

When producers on many queue managers put to one logical name, define CLUSTER on each instance and set CLWLUSEQ and DEFBIND deliberately. LOCAL keeps work on the producing node; ANY spreads across the cluster. Work queue depth monitoring must aggregate per instance or use tools that understand cluster queues. Do not point applications at XMITQ names by mistake.

Naming and Governance

• Use clear suffixes: .IN, .WORK, .BO for backout.
• Separate environments in names or queue managers (ORDERS.WORK.IN.DEV).
• Version interface payloads in message headers, not queue names.
• Runbook: max depth alert, consumer lag, poison on .BO.

Explain Like I'm Five: Work Queue

A to-do tray on a desk. People drop tasks in the tray (put). Workers take one task at a time (get), do it, and throw the paper away (commit). More workers mean more trays emptied per hour if they share politely (shared access).

Practice Exercises

Exercise 1

Design MQSC for a work queue at 100 msg/sec with 15-minute consumer outage tolerance.

Exercise 2

Only one of five consumers receives messages—list checks for SHARE and DEFSOPT.

Exercise 3

When would you split one work queue into three?

Frequently Asked Questions

Test Your Knowledge