TRIGTYPE(FIRST)—first trigger—is the workhorse of IBM MQ batch integration. When messages arrive after an idle period, MQ starts the consumer once; the consumer drains all available messages until the queue is empty again. Operations teams live with FIRST daily on payment files, inventory feeds, and nightly jobs. They also learn its sharp edge: if the consumer crashes halfway, depth stays above zero and FIRST may not fire again—messages look stuck until someone restarts the application or clears the queue to idle. This tutorial explains the empty-to-non-empty rule in detail, MQSC to define FIRST triggering, trigger monitor and PROCESS dependencies, coexistence with TRIGDATA, troubleshooting missed and duplicate triggers, and when to add DEPTH triggering for resilience.
CURDEPTH must be zero before a put that makes depth one. If a test message remains from yesterday, today's first business put does not generate FIRST—it is not the first message on an empty queue. Operations clearing queues for test must understand this. Similarly, browse applications that leave messages locked or uncommitted can prevent the queue from appearing empty. Use DISPLAY QSTATUS CURDEPTH before declaring FIRST broken.
| Item | Requirement | If missing |
|---|---|---|
| TRIGGER | YES on application queue | No trigger messages |
| TRIGTYPE | FIRST | Wrong firing pattern |
| PROCESS | Valid PROCESS name | Trigger msg with no start target |
| INITQ | Initiation queue exists | Trigger messages cannot be queued |
| Trigger monitor | Running | Messages pile on INITQ |
12345678DEFINE QLOCAL('ORDERS.IN') REPLACE + TRIGGER(YES) TRIGTYPE(FIRST) + PROCESS('ORDER.CONSUMER') + INITQ('SYSTEM.DEFAULT.INITIATION.QUEUE') + TRIGDATA('QUEUE=ORDERS.IN') DEFINE PROCESS('ORDER.CONSUMER') APPLICID('/opt/orders/run.sh') + USERDATA('LOGLEVEL=info') * Ensure trigger monitor active for queue manager
The put that transitions depth 0→1 creates a trigger message containing process name, queue name, and trigger type. The trigger monitor starts run.sh with USERDATA available per platform rules. The script should open ORDERS.IN with MQGET and loop until empty or until a business batch limit, then disconnect.
Without the trigger monitor, initiation queue depth grows while ORDERS.IN also has messages—classic "triggering broken" appearance. On distributed MQ the monitor is often started with the queue manager or via strmqtrm. Verify in your environment. AMQERR logs show trigger monitor failures to execute APPLICID—wrong path, permission denied, or SELinux blocking scripts on Linux.
Ideal pattern: one long-running triggered process handles many messages per FIRST event, or a short process drains and exits allowing the queue to return to empty. If processing takes hours while more messages arrive, depth stays non-zero—acceptable if the same process keeps getting. If the process exits after one message while depth remains, you need either loop-until-empty logic or EVERY/DEPTH—not FIRST alone.
Many modern apps use an always-on listener MQGET loop instead of FIRST. FIRST still wins when you must not run idle consumers overnight—mainframe-style batch costing. Compare operational cost: FIRST restarts on demand; listeners need health checks but avoid missed re-trigger after crash with depth remaining.
FIRST is one wake-up call when the first letter hits an empty inbox. You are expected to stay awake and read all letters that keep arriving until the inbox is empty again—not get a new wake-up call for every letter.
When the toy box is empty and you put the first toy in, a bell rings so your friend comes to play. If toys are already in the box, putting another toy does not ring the bell again—the friend who already came should keep playing.
Lab: put with depth 0, confirm trigger; put second message without emptying—confirm no second trigger.
Kill consumer with depth 10; document recovery options without losing messages.
When would you add DEPTH trigger alongside FIRST? Write three bullet criteria.
1. FIRST trigger fires on transition:
2. Consumer died, depth still 50—FIRST:
3. TRIGTYPE(FIRST) is set on:
4. Trigger monitor reads: