TRIGGER

The TRIGGER attribute on a local queue is the switch that tells IBM MQ: when messages arrive here, do not wait for operations to start a program manually—start it for me according to rules. TRIGGER(YES) is the foundation of event-driven batch and online processing on queue managers that predate Kubernetes and JMS listeners. Paired with TRIGTYPE, TRIGDPTH, PROCESS, INITQ, and the trigger monitor, it turns a passive queue into an autoscaling signal. This page focuses on the TRIGGER queue attribute itself: enabling and disabling it, how each TRIGTYPE behaves, how trigger messages flow to initiation queues, and how TRIGGER differs from modern listener containers—so beginners can configure MQSC confidently and troubleshoot “messages piling up but no consumer started.”

TRIGGER(YES) vs TRIGGER(NO)

TRIGGER(NO) is the default on many application queues: messages wait until a permanently running consumer or a scheduler starts the program. TRIGGER(YES) opts into automation—the queue manager evaluates trigger conditions and writes internal trigger messages. Disabling triggering with ALTER QLOCAL TRIGGER(NO) stops new trigger events; it does not stop already-running programs. Use NO on reply queues, initiation queues themselves, transmission queues, and dead-letter queues—triggering there would recurse or start inappropriate processes.

Related Attributes on the Same Queue

TRIGGER is only one line in a trigger profile. PROCESS names the PROCESS object with APPLICID and environment data the trigger monitor uses to start work. INITQ names the initiation queue (default SYSTEM.DEFAULT.INITIATION.QUEUE if omitted on many systems). TRIGDATA passes a string to the started program—often the queue name or a parameter file path. TRIGMPRI influences trigger message priority when many queues trigger at once. TRIGDPTH works with TRIGTYPE(DEPTH). DISPLAY QLOCAL shows the full set; copy a known-good template from a working queue rather than typing attributes from memory.

Flow: Message Arrives to Process Starts

1. Producer MQPUTs to local queue with TRIGGER(YES).
2. Queue manager detects trigger condition (FIRST or DEPTH, etc.).
3. Queue manager puts trigger message to initiation queue.
4. Trigger monitor MQGETs trigger message.
5. Monitor starts program per PROCESS definition (user id, args from TRIGDATA).
6. Application opens work queue and processes backlog.

If any step fails—initiation queue full, PROCESS typo, trigger monitor stopped—depth grows while no consumer appears. Operators check DISPLAY QMSTATUS for trigger monitor, DISPLAY QLOCAL INITQ PROCESS, and errors in AMQ messages.

TRIGTYPE(FIRST) in Practice

FIRST suits overnight-style workloads: queue empty most of the day, burst of messages, one server wakes up. When the queue drains empty again, the next arrival can trigger again. FIRST does not by itself start a second instance while the first is still running and depth is high—add TRIGTYPE(DEPTH) on the same or a companion design, or use external orchestration, if you need parallel instances during backlog.

TRIGTYPE(DEPTH) and TRIGDPTH

DEPTH triggering is horizontal scaling in classic MQ. Example: MAXDEPTH 100000, TRIGDPTH 20000—each time depth crosses 20000 while consumers lag, another trigger can request another PROCESS instance (subject to trigger monitor and platform limits). Set TRIGDPTH well below MAXDEPTH so workers start before queue full (reason 2053). Document how many concurrent instances your PROCESS allows; unbounded starts can exhaust CPU or database connections.

TRIGTYPE(EVERY): Use Sparingly

EVERY can attempt to start one process per message—catastrophic at thousands of messages per second. Historical systems sometimes used EVERY with lightweight shells; modern estates prefer always-on listeners, JMS MDBs, or DEPTH/FIRST with caps. If you inherit EVERY, treat it as technical debt and measure process table usage under load before production peaks.

MQSC Example: Triggered Work Queue

1
2
3
4
5
6
7
8
DEFINE PROCESS('ORDERS.PROC') REPLACE APPLICID('ordersvr') +
  USERDATA('ENV=PROD')
DEFINE QLOCAL('ORDERS.IN') REPLACE TRIGGER(YES) +
  TRIGTYPE(DEPTH) TRIGDPTH(5000) +
  PROCESS('ORDERS.PROC') INITQ('SYSTEM.DEFAULT.INITIATION.QUEUE') +
  TRIGDATA('ORDERS.IN') MAXDEPTH(100000)
* Verify trigger monitor: DISPLAY QMSTATUS TRMON
* Test: PUT one message; DISPLAY QSTATUS CURDEPTH; check app started

TRIGGER vs Always-On Listeners

Cloud-native teams often run long-lived consumers and set TRIGGER(NO) because the platform scales replicas via CPU or depth metrics externally. TRIGGER remains valuable on z/OS, small VMs, and legacy estates where spinning processes on demand saves licenses. Hybrid designs use TRIGGER(FIRST) to wake a container group that then stays up until idle timeout. Choose based on cost of idle processes versus latency to first message processed.

Common Misconfigurations

• TRIGGER(YES) but TRIGGER monitor not running.
• PROCESS name typo—trigger messages consumed with no start.
• Initiation queue put inhibited or wrong INITQ name.
• TRIGDPTH equal to MAXDEPTH—workers start too late.
• Triggering enabled on XMITQ or DLQ by mistake.

Explain Like I'm Five: TRIGGER

The queue is a mailbox. TRIGGER(YES) is a bell on the mailbox that rings when letters arrive (by rules you set). The trigger monitor hears the bell and wakes up the mail-sorting robot (PROCESS) to empty the box. If the bell is off (TRIGGER NO), letters sit until someone checks manually.

Practice Exercises

Exercise 1

Design TRIGTYPE and TRIGDPTH for a queue with MAXDEPTH 50000 that should start extra workers before 40000 messages.

Exercise 2

Messages arrive but no process starts. Write a six-step troubleshooting checklist.

Exercise 3

Why should initiation queues usually have TRIGGER(NO)?

Frequently Asked Questions

Test Your Knowledge