Trigger Types

IBM MQ can start applications automatically when messages arrive on a queue—triggering. The trigger type (TRIGTYPE on the queue definition) decides the rule: start when the first message lands, start for every message, or start when depth crosses a threshold. Choosing the wrong type causes missed processing (FIRST when multiple parallel consumers are needed without depth scaling) or process storms (EVERY under high put rate). Beginners copy TRIGGER(YES) from samples without understanding TRIGTYPE; operations then wonders why fifty Java processes spawned overnight. This tutorial compares FIRST, EVERY, and DEPTH trigger types, explains TRIGDPTH and TRIGDATA, relates types to initiation queues and PROCESS objects, and gives selection guidance for batch, interactive, and scale-out workloads.

How Triggering Fits Together

An application puts to QLOCAL WORK.IN with TRIGGER(YES). When trigger conditions match TRIGTYPE, the queue manager writes a trigger message to the initiation queue (often SYSTEM.DEFAULT.INITIATION.QUEUE or a dedicated QLOCAL). The trigger monitor reads that message and starts the program named in the PROCESS object (APPLICID, USERDATA). The started program opens WORK.IN and gets messages. Trigger type controls how often that chain fires—not how the application processes messages once running.

TRIGTYPE comparison
TRIGTYPEFires whenBest for
FIRSTFirst message after queue was emptySingle consumer per idle-to-busy cycle
EVERYEach message put (per rules)Low volume, strict per-message start
DEPTHCURDEPTH >= TRIGDPTHScale extra workers when backlog grows

TRIGTYPE(FIRST)

FIRST is the default pattern for many enterprise batch triggers. When CURDEPTH was zero and a put makes depth one, MQ generates a trigger message. While the queue stays non-empty, additional puts do not generate more FIRST triggers—the assumption is the already-started consumer will drain the queue. If the consumer dies with messages remaining, depth is still non-zero so FIRST may not fire again until the queue empties. Operations must monitor consumer health or use DEPTH for scaling. See our first-trigger tutorial for operational detail.

TRIGTYPE(EVERY)

EVERY attempts to trigger for each message arrival (subject to queue manager coalescing and trigger monitor capacity). At hundreds of messages per second, starting one OS process per message exhausts CPU and file descriptors. Use EVERY only when volume is low and each message truly requires an isolated short-lived process—rare in modern MQ estates. Prefer FIRST with a long-running consumer or DEPTH with controlled parallelism.

TRIGTYPE(DEPTH)

DEPTH compares CURDEPTH to TRIGDPTH. Example: TRIGDPTH(100) starts additional consumers when backlog reaches one hundred messages—useful when message size or processing time varies and you want more workers only under load. Set TRIGDPTH high enough to avoid flapping triggers at boundary. Combine with application design that exits when the queue is empty so you do not accumulate idle processes.

shell
1
2
3
4
5
DEFINE QLOCAL('WORK.IN') TRIGGER(YES) TRIGTYPE(FIRST) + PROCESS('WORK.PROC') INITQ('SYSTEM.DEFAULT.INITIATION.QUEUE') DEFINE QLOCAL('WORK.BULK') TRIGGER(YES) TRIGTYPE(DEPTH) TRIGDPTH(500) + PROCESS('WORK.PROC') INITQ('INITQ.BACKLOG') DEFINE PROCESS('WORK.PROC') APPLICID('/opt/app/consume.sh') USERDATA('pool=1')

TRIGDATA and PROCESS

TRIGDATA on the queue passes a string to the trigger message so one PROCESS definition can serve multiple queues with different parameters (queue name, thread pool id). PROCESS APPLICID is the executable or script; USERDATA is often copied into the environment. Wrong PROCESS name leaves messages on the application queue with trigger messages piling on the initiation queue—check AMQERR for trigger monitor errors.

Choosing a Trigger Type

  • Steady single-threaded batch overnight file—FIRST with one durable consumer process.
  • Variable spike load—DEPTH with TRIGDPTH tuned from peak metrics.
  • Legacy per-message executable—EVERY only if rate caps enforced externally.
  • Modern microservices—consider long-running consumers instead of triggering entirely.

Explainer: Doorbell vs Alarm

FIRST is a doorbell when the first package arrives—one ring starts the handler. EVERY rings the bell for every package—noisy. DEPTH sounds an alarm when the pile reaches a line on the wall—call more helpers.

Explain Like I'm Five: Trigger Types

When mail arrives in the box, you can ring once for the first letter (FIRST), ring for every single letter (EVERY), or ring when the box is so full you need more friends to help (DEPTH).

Practice Exercises

Exercise 1

Define two queues on lab QM: FIRST vs DEPTH; put messages and observe initiation queue depth.

Exercise 2

Calculate safe TRIGDPTH if each message takes 2 seconds and you want max 5 parallel workers.

Exercise 3

Explain why EVERY is risky at 1000 msg/sec in one paragraph.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. TRIGTYPE(FIRST) fires when:

  • Queue goes from empty to non-empty
  • Every message always
  • Channel starts
  • TLS handshake

2. TRIGTYPE(DEPTH) uses:

  • TRIGDPTH threshold
  • SSLCIPH
  • MAXMSGL only
  • CCDT

3. TRIGTYPE(EVERY) can cause:

  • Many process starts per message
  • No triggers ever
  • Channel RETRY
  • Archive only

4. Trigger messages go to:

  • Initiation queue
  • XMITQ
  • DLQ only
  • Topic
Published
Read time18 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation