Process Definitions

Process definitions are the instruction cards IBM MQ uses when a queue says "start my worker now." The queue holds messages; triggering detects work waiting; a trigger message lands on an initiation queue; the trigger monitor reads APPLICID and APPLTYPE from a PROCESS object and launches the right program or transaction. Without a correct process definition, depth triggers fire but nothing runs—one of the most common beginner mysteries in operations. This page covers DEFINE PROCESS, every important attribute, how queues reference PROCESS names, first versus every versus depth triggers, platform differences on z/OS and distributed systems, security (who runs the job), and troubleshooting when triggers stall.

PROCESS Objects in the Repository

Like channels or listeners, a process definition is metadata. DISPLAY PROCESS shows APPLICID, APPLTYPE, DESCR, ENVDATA, and USERDATA. Applications normally do not open process objects during steady-state messaging; administrators define them once and queues reference them by name. ALTER PROCESS changes future trigger behavior; running instances of an old program are not automatically killed.

Explainer: Trigger Chain End to End

Step one: a producer MQPUTs to ORDERS.IN with triggering enabled. Step two: the queue manager decides a trigger event occurred (first message, every message, or depth threshold depending on TRIGTYPE and TRIGDPTH). Step three: it creates a trigger message on the initiation queue (often SYSTEM.DEFAULT.INITIATION.QUEUE or a custom INITQ). Step four: the trigger monitor (runmqtrm on UNIX and Windows) gets the message, reads which PROCESS and APPLICID to use, and starts the worker. Step five: the worker MQGETs from ORDERS.IN and processes backlog. The process definition is the bridge between "something should run" and "this executable or CICS transaction."

APPLTYPE Values Compared

Choosing APPLTYPE wrong is a silent failure mode. UNIX expects a path and shell conventions on Linux or AIX. WINDOWS expects a Windows executable path. CICS and IMS use transaction IDs understood by the respective trigger adapters on z/OS. MVS covers batch and TSO styles. WLM integrates with z/OS workload manager. DEF defers to the platform default starter. Custom numeric APPLTYPE values exist for vendor extensions—avoid until you have vendor documentation. When migrating from test to production, verify APPLTYPE matches the OS actually hosting the queue manager.

Queue Attributes That Reference PROCESS

• TRIGGER(YES) enables triggering on the queue.
• PROCESS(name) names the process definition to embed in trigger messages.
• TRIGTYPE(FIRST), EVERY, or DEPTH controls when events fire.
• TRIGDPTH(n) for depth triggers—fire when CURDEPTH reaches n.
• INITQ(name) selects which initiation queue receives trigger messages.

If PROCESS is blank, the trigger message may still fire but the monitor lacks startup instructions. If INITQ is wrong, messages sit unread. Operations runbooks should list the triple: work queue, initiation queue, process name.

Security and Identity

The started application runs under an identity determined by the trigger monitor and platform—often the queue manager's service account on distributed systems, or a defined user on z/OS. MCAUSER on channels is a different concept; do not confuse them. Grant the runtime user authority to MQGET the work queue and MQPUT replies if needed. Principle of least privilege: the triggered job should not have system administration authority unless required.

z/OS and Distributed Differences

On z/OS, APPLICID for CICS might be a four-character transaction id; for distributed queuing stubs, documentation sometimes mandates specific module names. On Linux containers, APPLICID might be /opt/app/bin/consume_orders.sh with APPLTYPE(UNIX). Path typos produce trigger error logs, not MQRC on client puts—monitor AMQERR and trigger monitor output. Container images must include the binary at the path in APPLICID.

Tutorial: Lab Trigger with PROCESS

1
2
3
4
5
6
7
8
9
10
11
12
13
DEFINE PROCESS('ORDERS.CONSUMER') REPLACE +
  APPLICID('/opt/mq/lab/amqsget') +
  APPLTYPE(UNIX) +
  DESCR('Lab GET sample for ORDERS.IN')
DEFINE QLOCAL('ORDERS.IN') REPLACE +
  TRIGGER(YES) TRIGTYPE(FIRST) +
  PROCESS('ORDERS.CONSUMER') +
  INITQ('SYSTEM.DEFAULT.INITIATION.QUEUE')
* Start trigger monitor (platform command):
* runmqtrm -m QM1 -q SYSTEM.DEFAULT.INITIATION.QUEUE
* Put one message; verify consumer starts and depth drops
DISPLAY PROCESS('ORDERS.CONSUMER')
DISPLAY QLOCAL('ORDERS.IN') TRIGGER PROCESS TRIGTYPE

Common Mistakes

1. Trigger monitor not running—backlog grows, no application.
2. APPLICID path wrong after deployment move.
3. TRIGTYPE(FIRST) already fired; need new message or TRIGTYPE(EVERY) for each message.
4. Process name typo between queue PROCESS attribute and DEFINE PROCESS.
5. Insufficient authority for started job to MQGET the queue.

Explain Like I'm Five: Process Definitions

A bell rings in the kitchen when mail arrives in the mailbox (trigger). On the wall is a note that says which person to call to pick up the mail (process definition). Without the note, the bell rings but nobody knows who should go. The note does not walk to the mailbox itself—it only tells the helper what job to do.

Practice Exercises

Exercise 1

Design PROCESS, QLOCAL, and INITQ names for a payment queue that should start one COBOL batch on z/OS when depth reaches 100.

Exercise 2

Trigger fired once with TRIGTYPE(FIRST) but operators expect one consumer per message. Which TRIGTYPE change do you recommend and what is the trade-off?

Exercise 3

List log files and DISPLAY commands you would use when trigger messages appear but APPLICID never runs.

Frequently Asked Questions

Test Your Knowledge