JCL is how z/OS tells the system which program to run, which libraries to load, and where to read input and write output. IBM MQ operations live in that world: starting the subsystem from a procedure, applying fifty queue definitions from a change ticket through CSQUTIL, running backup utilities after maintenance, and scheduling housecleaning jobs when depth dashboards trend wrong. Distributed administrators paste runmqsc in a terminal; mainframe administrators submit jobs whose JES output is evidence for auditors. Beginners must read PROC libraries, understand STEPLIB to MQ SDFSMS or load libraries, and interpret completion codes when a DEFINE fails at 2 a.m. This tutorial explains common JCL patterns for MQ, CSQUTIL job structure, started task PROCs versus batch jobs, DD statement purposes, return code discipline, and how JCL fits change management next to SMP/E and CSQ console work.
A batch job runs to completion and ends—ideal for CSQUTIL define packages and reports. A started task PROC may run continuously (channel initiator, listener) or restart on failure depending on automation. Subsystem startup may use a started task from an operator command or IPL automation referencing a PROC. Knowing which PROC is long-running versus one-shot prevents operators from canceling the wrong job during an incident.
| Pattern | Typical PGM | When used |
|---|---|---|
| CSQUTIL define | CSQUTIL | Change windows, new queues |
| Subsystem start PROC | MQ control modules | IPL, recovery |
| Application batch | COBOL/Java + MQI | Nightly processing |
| Housekeeping | Site tools + MQ | Depth, log archive |
| Backup/export | IBM/site utility | DR drills |
1234567891011//MQCHG JOB (ACCT),'MQ DEFINE PACKAGE',CLASS=A,MSGCLASS=X, // NOTIFY=&SYSUID //MQUTIL EXEC PGM=CSQUTIL,REGION=0M //STEPLIB DD DSN=MQ.SCSQLOAD,DISP=SHR //SYSPRINT DD SYSOUT=* //INPUT DD * DEFINE QLOCAL('BATCH.IN') QSGDISP(SHARED) CFSTRUCT(MQSG001) ALTER QLOCAL('BATCH.IN') MAXDEPTH(100000) DISPLAY QLOCAL('BATCH.IN') ALL /* //
STEPLIB must resolve to the MQ load library for your release—DSN names differ per site. SYSPRINT captures CSQUTIL messages; search for CSQ messages indicating success or failure. INPUT (or your proc DD name) holds commands terminated with the end marker your site uses. REGION=0M is common for utilities needing virtual storage. Job accounting on the JOB card feeds chargeback.
JCL COND parameters chain steps so a failed DEFINE does not trigger downstream jobs that assume new queues exist. Program return codes from MQI batch should be documented: RC 0 success, higher values map to MQ reason in program output. Operations playbooks tie RC thresholds to pager severity. Never ignore CSQUTIL warning lines because JES shows COMPLETED.
Mature shops store CSQUTIL input in sequential data sets or Git exported to mainframe with Zowe. Promotion path: development LPAR job succeeds, test LPAR mirrors production CF structure sizing, production change window submits approved JCL. Identical JCL with different STEPLIB or INPUT DSN separates environments. Drift between environments causes the classic works in test, 2085 in prod incident.
JCL is the recipe card the kitchen (z/OS) follows: ingredients (DD), cooking program (PGM), and where to plate the result (SYSOUT). CSQUTIL is one recipe; your payment batch with MQI is another.
JCL is a list of instructions that tells the mainframe to run the IBM MQ helper program and give it the words (commands) it should obey.
Annotate a sample CSQUTIL JCL job: label each DD purpose.
Write COND logic so step two runs only if CSQUTIL return code is zero.
Compare how your site versions MQ JCL versus distributed Git MQSC.
1. CSQUTIL runs in:
2. JCL for MQ often includes:
3. SYSPRINT DD is for:
4. DEFINE QLOCAL in batch uses: