PROCESS Objects

PROCESS objects are the bridge between IBM MQ triggering and your applications. When a triggered queue needs work, the queue manager does not guess which binary to run—it looks up the PROCESS object named on the queue and hands APPLICID to the trigger monitor. Beginners often fix TRIGGER and TRIGTYPE on the queue but leave PROCESS undefined or APPLICID pointing to a path that does not exist on the server. Messages pile up on the application queue while initiation queue shows trigger messages and AMQERR complains about start failures. This tutorial explains DEFINE PROCESS, each attribute's effect, platform differences for APPLICID and APPLTYPE, ENVDATA and USERDATA, altering PROCESS objects safely, and how PROCESS fits with TRIGDATA and the trigger monitor.

PROCESS in the Trigger Chain

Put on triggered queue → trigger message to INITQ → trigger monitor reads message → looks up PROCESS → starts APPLICID with environment from ENVDATA/USERDATA/TRIGDATA → application connects and MQGETs. A break anywhere in the chain looks like "triggering broken" but only the PROCESS step may be wrong.

DEFINE and ALTER PROCESS

1
2
3
4
5
6
DEFINE PROCESS('PAY.CONSUMER') APPLICID('/app/bin/pay_consume') +
  APPLTYPE(UNIX) USERDATA('LOG=info') ENVDATA('HOME=/app')
ALTER PROCESS('PAY.CONSUMER') USERDATA('LOG=debug')
DISPLAY PROCESS('PAY.CONSUMER') ALL
DEFINE QLOCAL('PAY.IN') TRIGGER(YES) TRIGTYPE(FIRST) +
  PROCESS('PAY.CONSUMER') INITQ('SYSTEM.DEFAULT.INITIATION.QUEUE')

APPLICID must be executable by the user under which the trigger monitor runs—often mqm on Linux. Permissions, SELinux contexts, and missing interpreters (#!/bin/bash) cause silent-looking failures. On Windows, APPLICID may be a .exe path; on z/OS, follow IBM samples for APPLTYPE and stub modules.

APPLTYPE Values

APPLTYPE tells the queue manager how to invoke APPLICID. UNIX starts shell scripts and binaries per POSIX rules on Linux. WINDOWS uses Windows process creation. CICS and other mainframe types use platform-specific starters. Using UNIX on a script without execute bit fails. Copy PROCESS definitions between platforms only after rewriting APPLICID and APPLTYPE—never assume identical syntax.

One PROCESS, Many Queues

Shared PROCESS reduces maintenance: one consume.sh handles ORDERS.IN, RETURNS.IN, and ADJUSTMENTS.IN with different TRIGDATA on each queue. The script reads TRIGDATA or environment to open the correct queue name. Avoid hard-coding a single queue inside the script when multiple queues share PROCESS— that breaks the second queue silently.

Security and Authority

The started application runs as a platform user determined by trigger monitor configuration—not automatically as the putting user. Grant the runtime user MQ connect and queue authority. Starting /bin/sh from PROCESS is a security-sensitive change control item—validate paths and arguments to prevent command injection via TRIGDATA if scripts are poorly written.

Troubleshooting PROCESS Failures

1. DISPLAY PROCESS — confirm APPLICID spelling.
2. Run APPLICID manually as trigger user on the host.
3. Check AMQERR for trigger monitor start errors.
4. Verify queue PROCESS attribute matches object name.
5. Confirm INITQ and trigger monitor active.

Explainer: Name Tag on the Job Order

The PROCESS object is the name tag on a work order telling the factory which machine to start. The queue is the inbox; the trigger monitor is the supervisor; PROCESS is the tag saying run Machine B.

Explain Like I'm Five: PROCESS Objects

When the bell rings for mail, PROCESS is the note that says which friend to call to pick up the mail. If the note has the wrong name, nobody comes even though mail is waiting.

Practice Exercises

Exercise 1

Define PROCESS and queue; break APPLICID path; fix using AMQERR clues.

Exercise 2

Design one PROCESS serving three queues with distinct TRIGDATA values.

Exercise 3

Document APPLTYPE and run-as user for your platform in a runbook table.

Frequently Asked Questions

Test Your Knowledge