CICS MQ Triggering

CICS MQ triggering is how mainframe shops turn passive queues into live workers without operators typing START every morning. A producer—batch job, remote channel, or another CICS region—MQPUTs business data to an application queue. IBM MQ evaluates TRIGGER, TRIGTYPE, TRIGDPTH, and related attributes. When conditions match, the queue manager writes an internal trigger message to the initiation queue. CKTI, the CICS trigger monitor, MQGETs that trigger message and starts the CICS transaction named in the PROCESS object. That transaction MQGETs the real work from the application queue and runs COBOL or Java business logic. The pattern predates cloud autoscaling but solves the same problem: do not pay for idle CICS tasks when queues are empty, yet react within seconds when work arrives. This tutorial walks the full chain on z/OS, compares TRIGTYPE values for CICS workloads, explains PROCESS and INITQ wiring, covers scaling and failure modes, and ties triggering to the broader CICS-MQ bridge so beginners can configure and troubleshoot message-driven CICS.

End-to-End Trigger Chain in CICS

1. A message arrives on a local application queue with TRIGGER(YES) and supporting attributes.
2. The queue manager decides whether a trigger event is needed based on TRIGTYPE and current CURDEPTH.
3. If yes, MQ creates a trigger message on the initiation queue (INITQ) named on the application queue.
4. CKTI runs in CICS, reads the trigger message, and issues a start for the application transaction.
5. The application transaction connects to MQ (if not already), MQGETs from the application queue, and processes the payload.
6. When the queue drains or goes idle, TRIGTYPE(FIRST) will not fire again until the queue becomes empty and receives new messages.

TRIGTYPE Values for CICS Workloads

TRIGTYPE controls when the queue manager generates trigger messages. Choosing the wrong type is the most common design mistake: either nothing starts, or CKTI floods CICS with duplicate transactions during peak load.

TRIGDPTH works with TRIGTYPE(DEPTH). If TRIGDPTH is 500 and MAXDEPTH is 50000, each time depth crosses another 500-message band while work backs up, MQ can request another consumer—subject to trigger monitor behavior and whether an instance is already considered active. Document the maximum CICS tasks your PROCESS design allows; Db2 connection pools and thread limits often fail before MQ does.

Example MQSC and CICS Definitions

1
2
3
4
5
6
7
8
9
10
11
12
DEFINE QLOCAL('ORDERS.IN') REPLACE +
  TRIGGER + TRIGTYPE(FIRST) TRIGDPTH(1) +
  INITQ('SYSTEM.DEFAULT.INITIATION.QUEUE') +
  PROCESS('ORDPROC') MAXDEPTH(100000)
 
DEFINE PROCESS('ORDPROC') REPLACE +
  APPLICID('ORD1') +
  USERDATA('Order intake from MQ trigger')
 
/* CICS: transaction ORD1 -> program ORDPROG
   CICS: CKTI defined and active in region
   RACF: CKTI and ORD1 authorized for MQ queues */

INITQ must be a local queue the queue manager can write to. Many sites use SYSTEM.DEFAULT.INITIATION.QUEUE until naming standards require a dedicated INITQ per application family. PROCESS APPLICID must match a CICS transaction id that starts the correct program with correct COMMAREA or channel if used. USERDATA is opaque bytes some programs read from the trigger message context; keep it short and documented.

CKTI and the CICS Region

CKTI is not optional decoration—it is the CICS-side trigger monitor. If CICS is recycled but MQ keeps accepting puts, trigger messages accumulate on INITQ until CKTI runs again. Operators verify CKTI with CICS inquiry before blaming MQ depth. Multiple CICS regions attached to one queue manager each need a clear architecture: usually one region owns CKTI for a given INITQ, or initiation queues are partitioned per region. Sharing one INITQ across regions without design leads to duplicate starts or races.

CKTI should use short MQGET waits so it does not hold CICS tasks unnecessarily, but not so aggressive that CPU spins. Application transactions started by CKTI may use MQGET with wait intervals appropriate to business SLAs. Long waits in triggered tasks consume MXT slots—consider internal work queues and child transactions for heavy processing.

Triggering Versus Permanent MQ Listeners in CICS

Some installations run a long-lived CICS transaction that loops MQGET with wait instead of triggering. That model is simpler mentally but consumes a task slot continuously. Triggering saves resources when traffic is bursty or overnight-idle. Hybrid designs trigger the first worker with TRIGTYPE(FIRST) and add workers with TRIGTYPE(DEPTH) when depth grows. Compare electricity bills: triggering is the motion sensor light; permanent listener is the bulb left on.

Security and Authorization

CKTI needs GET on the initiation queue and authority to start application transactions. Application programs need GET on the application queue and PUT if they reply. RACF profiles for the CICS region userid and transaction definitions must align with MQ object profiles—see the MQ RACF tutorials in this track. A 2035 NOT_AUTHORIZED on INITQ looks like “triggering broken” in operations dashboards.

Tutorial: Verify a Trigger Configuration

1. DISPLAY QLOCAL('ORDERS.IN') TRIGGER TRIGTYPE INITQ PROCESS CURDEPTH.
2. DISPLAY QLOCAL initiation queue CURDEPTH—trigger messages waiting imply CKTI lag.
3. Confirm CKTI active in CICS; check system messages for start failures.
4. DISPLAY PROCESS('ORDPROC') APPLICID; match to CICS trans definition.
5. Put a test message; observe application queue depth decrease after CICS starts.

Troubleshooting Checklist

• Messages on application queue, zero on INITQ: TRIGGER off, TRIGTYPE NONE, or conditions not met (e.g. queue not empty for FIRST).
• Messages on INITQ, no CICS activity: CKTI down, CKTI not authorized, or PROCESS APPLICID invalid.
• CICS starts then abends: program, copybook, or MQ connection definition; not a trigger logic bug.
• Too many CICS tasks: TRIGTYPE(EVERY) or TRIGDPTH too low for message rate; tune or cap instances.
• Duplicate processing: multiple regions or overlapping triggers; review architecture.

Explainer: The Night Watchman

Think of triggering as a night watchman who only calls the warehouse crew when the loading dock sensor shows cartons arrived. CKTI is the watchman reading the sensor ticket (trigger message). The crew (CICS transaction) unloads cartons (application messages). No cartons, no crew on payroll.

Explain Like I'm Five

When letters appear in the big mailbox, a bell rings in the office. CKTI hears the bell and tells the right worker to collect the letters. No letters, no bell, worker stays home.

Practice Exercises

Exercise 1

Design TRIGGER attributes for a queue that should wake one CICS task when the first overnight message arrives, then add DEPTH triggers when more than 1000 messages accumulate.

Exercise 2

List five DISPLAY and CICS inquiry commands you would run if INITQ depth is 50 and application queue depth is 5000.

Exercise 3

Draw a sequence diagram from MQPUT through CKTI to application MQGET.

Frequently Asked Questions

Test Your Knowledge