Trigger Monitor

Polling a queue in a tight loop wastes CPU; leaving messages unprocessed when traffic spikes hurts SLAs. IBM MQ triggering bridges the gap: when a local queue meets conditions you define, the queue manager generates a trigger event and the trigger monitor starts your program. Mainframe batch and distributed services alike have relied on this pattern for decades. This page explains the trigger monitor process, initiation queues, PROCESS definitions, TRIGTYPE and TRIGDPTH attributes, trigger data passed to apps, and operational pitfalls so beginners can design event-driven consumers without custom daemons.

Components in the Trigger Chain

1. Application MQPUTs to a local queue with TRIGGER enabled.
2. Queue manager evaluates TRIGTYPE and depth against TRIGDPTH.
3. Queue manager creates a trigger message on the initiation queue.
4. Trigger monitor MQGETs the trigger message and starts the PROCESS.
5. Started application MQOPENs the triggered queue and MQGETs business messages.

Explainer: FIRST vs EVERY vs DEPTH

TRIGTYPE(FIRST) starts processing when the queue transitions from empty to non-empty—ideal when one worker drains many messages. TRIGTYPE(EVERY) can launch a new instance for each message, which may flood the system under load; use only when isolation requires separate processes. TRIGTYPE(DEPTH) starts work when CURDEPTH reaches TRIGDPTH—useful for batching (start consolidator when 100 messages accumulate). Compare to modern competing consumers: multiple manual MQGET programs on one queue achieve parallelism without EVERY triggers.

PROCESS Objects

DEFINE PROCESS(APPL.PROC) APPLICID('myapp') USERDATA('env=prod') supplies the executable identity the trigger monitor invokes. On Windows this may be a .exe; on Linux a script or binary path subject to platform rules in IBM documentation. APPLTYPE and APPLID format vary by platform—verify samples for your OS. Wrong PROCESS names cause trigger messages to accumulate on the initiation queue with errors in AMQERR while business messages sit unprocessed.

Trigger Data

The started application can read trigger message content to learn ProcessName, TriggerType, QName, and other fields (see MQTM structure in MQI reference). This helps one generic starter binary open the correct queue. CICS and IMS bridges use related concepts on z/OS; distributed Java apps more often use long-running listeners, but triggering remains valuable for legacy COBOL executables launched from shell.

Operations and Pitfalls

• Ensure trigger monitor service is running—part of queue manager status.
• Initiation queue depth greater than zero with idle apps signals failed PROCESS or permissions.
• TRIGMPRI and TRIGPPRI control priority on some platforms—document for capacity planning.
• Not a substitute for poison message handling—still configure backout and DLQ.

Tutorial: Enable Triggering on a Work Queue

1
2
3
4
5
6
7
DEFINE PROCESS('ORDERS.PROC') APPLICID('ordersvr') +
  DESCR('Order processor') REPLACE
ALTER QLOCAL('ORDERS.IN') TRIGGER(ENABLED) +
  TRIGTYPE(FIRST) PROCESS('ORDERS.PROC') +
  INITQ('SYSTEM.DEFAULT.INITIATION.QUEUE')
DISPLAY QLOCAL('ORDERS.IN') TRIGGER TRIGTYPE PROCESS
* Put a message; verify application starts and depth drains

Explain Like I'm Five: Trigger Monitor

When the mailbox gets its first letter, a bell rings (trigger). A helper (trigger monitor) wakes up the mail sorter (your app) to empty the box. Without the bell, someone would have to keep peeking inside all day (polling).

Practice Exercises

Exercise 1

Queue has TRIGGER(ENABLED) TRIGTYPE(FIRST) but INITQ wrong name. What symptom?

Exercise 2

When is DEPTH trigger better than FIRST for payroll files?

Exercise 3

Compare triggering to three competing Java consumers on one queue.

Frequently Asked Questions

Test Your Knowledge