Depth trigger—TRIGTYPE(DEPTH)—is IBM MQ's way of saying "call more help when the pile is big enough." When CURDEPTH on a triggered queue reaches TRIGDPTH, the queue manager can write a trigger message so the trigger monitor starts another consumer instance. Payment systems use depth triggers after Black Friday traffic exceeds single-threaded processing; batch warehouses use them when file drops spike overnight. Misconfigured TRIGDPTH causes flapping triggers at the boundary or no extra workers when backlog is obvious. This tutorial explains TRIGDPTH selection, how depth triggers interact with FIRST and long-running consumers, PROCESS and INITQ requirements, sizing math, monitoring, and troubleshooting when depth is high but no new workers appear.
Unlike FIRST, depth trigger does not require the queue to have been empty. A steady stream of puts can push CURDEPTH from 400 to 600; if TRIGDPTH is 500, crossing that threshold generates trigger activity per queue manager rules. The started application should drain messages until depth falls or until a business limit stops the worker. If workers exit while depth remains above TRIGDPTH, another depth trigger may fire—by design for scale-out, dangerous if unchecked.
| Factor | Guidance | Rationale |
|---|---|---|
| Processing time per message | Higher latency → lower TRIGDPTH | Backlog builds faster per worker |
| Target parallel workers | TRIGDPTH ≈ backlog per worker desired | Avoid starting 50 processes at once |
| Put burst rate | Set above normal idle depth | Prevent flapping on routine traffic |
| MAXDEPTH | TRIGDPTH well below MAXDEPTH | Room before queue full 2053 |
123456DEFINE QLOCAL('ORDERS.BULK') TRIGGER(YES) TRIGTYPE(DEPTH) + TRIGDPTH(1000) PROCESS('ORDER.WORKER') + INITQ('INITQ.SCALE') TRIGDATA('POOL=BULK') DEFINE PROCESS('ORDER.WORKER') APPLICID('/opt/orders/worker.sh') + USERDATA('MAXMSG=200') * worker.sh: get up to 200 messages or until empty, then exit
TRIGDPTH(1000) suggests starting another worker when at least one thousand messages wait. If each worker removes two hundred messages per run, five concurrent workers might exist under sustained load—if each depth trigger starts one without cap. Application USERDATA can pass MAXMSG to limit per invocation. Operations should cap maximum instances in script or orchestration (Kubernetes replicas, etc.) when using MQ triggering as a scale signal.
If consumers cannot keep pace, CURDEPTH approaches MAXDEPTH and producers see 2053 queue full. Depth trigger is a prevention tool—fire extra workers before MAXDEPTH. Alert at eighty percent MAXDEPTH even with DEPTH configured. TRIGDPTH at ninety percent of MAXDEPTH leaves little time for new workers to drain before puts fail.
Pattern A: FIRST on primary queue starts baseline consumer when work arrives. Pattern B: DEPTH on same queue with higher TRIGDPTH adds workers when backlog grows—requires consumer idempotency or partitioned queues to avoid duplicate processing. Pattern C: separate scale queue fed by application logic—more complex. Document which pattern your estate uses; do not copy MQSC without architectural review.
When the supermarket line reaches ten carts (TRIGDPTH), the manager opens another checkout. Depth trigger is that policy— not opening a new checkout for the first cart only (FIRST), and not hiring one cashier per item (EVERY).
When the toy box has so many toys it is hard to count to one hundred, you ask more friends to help put toys away. The number one hundred is TRIGDPTH.
Lab: set TRIGDPTH(10), put 25 messages, count trigger-related activity on INITQ.
Given 5 sec/msg processing and target 4 workers max, propose TRIGDPTH with shown math.
List risks of DEPTH without consumer message locking strategy.
1. DEPTH trigger uses attribute:
2. DEPTH helps when:
3. TRIGDPTH too low causes:
4. CURDEPTH in DEPTH trigger refers to: