TRIGTYPE(EVERY)—every trigger—tells IBM MQ to treat each message arrival as a potential signal to start application processing through the trigger monitor. Where FIRST rings the doorbell once when mail first appears in an empty box, EVERY rings for every letter. That sounds precise but on a busy queue it becomes a process factory: hundreds of shell scripts or Java VMs launching per minute, initiation queue depth spiking, and operators paging on CPU while messages still backlog. This tutorial explains how EVERY works, when enterprises still use it, how the trigger monitor interacts with PROCESS definitions, coalescing and practical limits, safer alternatives, and troubleshooting when EVERY was chosen years ago and volume has grown.
A queue with TRIGGER(YES), TRIGTYPE(EVERY), PROCESS(name), and INITQ(name) causes the queue manager to write trigger messages to the initiation queue when puts satisfy the every-message rule. The trigger monitor reads each trigger message and starts APPLICID from the PROCESS object—often a script or binary path on distributed MQ, or a transaction on z/OS. The started program is expected to open the application queue, process work, and exit. If each instance handles only one message and exits, EVERY aligns with that design. If startup cost is seconds, EVERY cannot keep pace with sub-second put rates.
| TRIGTYPE | Typical fire pattern | High-volume risk |
|---|---|---|
| FIRST | 0 → 1 depth transition | Low if consumer drains queue |
| EVERY | Each put (per rules) | High—process storm |
| DEPTH | CURDEPTH >= TRIGDPTH | Medium—tune threshold |
12345DEFINE QLOCAL('LOWVOL.IN') TRIGGER(YES) TRIGTYPE(EVERY) + PROCESS('HANDLE.ONE') INITQ('SYSTEM.DEFAULT.INITIATION.QUEUE') + TRIGDATA('MODE=SINGLE') DEFINE PROCESS('HANDLE.ONE') APPLICID('/opt/handle_one.sh') APPLTYPE(UNIX) * Script should MQGET one message, process, commit, exit
TRIGDATA passes context to the started program—queue name, business parameters, or a flag that the worker should process exactly one message. USERDATA on PROCESS can duplicate environment hints. Wrong APPLICID leaves messages on LOWVOL.IN while initiation queue grows—check AMQERR for trigger monitor errors identical to other trigger types.
Operating systems cap processes per user and file descriptors per process. MQ trigger monitor starting hundreds of children can hit ulimit -u, fill /tmp, or saturate disk with logs. Initiation queue depth may lag if the monitor cannot start fast enough—trigger messages accumulate, delaying all triggered queues sharing that INITQ. Monitoring INITQ depth is mandatory for EVERY estates. Rate limiting at the application put side is not a substitute for changing TRIGTYPE.
Even in these cases, document maximum sustainable rate and escalation when rate exceeds design.
EVERY is ringing the doorbell for every package delivered. If packages arrive every second, nobody can answer the door fast enough and packages pile on the porch—the initiation queue—while exhausted helpers collapse from running to the door.
Every time a toy is put in the box, you yell for a new friend to come play. If toys arrive faster than friends can run over, the yard fills with yelling and confused friends, and toys still sit in the box.
Lab: EVERY with 20 rapid puts—observe INITQ depth and OS process count.
Rewrite same queue as FIRST with loop-until-empty script; compare resource use.
Write approval criteria: when EVERY is allowed in your standards document.
1. TRIGTYPE EVERY fires:
2. EVERY at high volume risks:
3. Better high-volume pattern often is:
4. Trigger messages go to: