JCL TYPRUN Parameter: COPY, HOLD, JCLHOLD, and SCAN

A batch job has been changed, but you do not want it to allocate a data set or run a program until its JCL receives an initial syntax check. Add TYPRUN=SCAN to the JOB statement. JES sends the job through converter-level checking without executing its steps or allocating devices.

TYPRUN changes how JES handles a submitted job before normal step execution.

What the JCL TYPRUN parameter does

TYPRUN is an optional keyword parameter on the JOB statement. It requests special processing for the submitted job. Depending on the value and JES type, the system can print the submitted job stream, hold the job, stop JCL processing at an earlier point, or scan the JCL without running it.

Value	JES support	What happens	Does the job execute?
COPY	JES2 only	Copies the submitted input job stream to a SYSOUT data set controlled by the JOB statement's MSGCLASS.	No
HOLD	JES2 and JES3	Holds the job before execution until an operator releases it.	Only after release
JCLHOLD	JES2 only	Holds the job before JCL processing is completed until an operator releases it.	Only after release and successful JCL processing
SCAN	JES2 and JES3	Checks JCL syntax through the converter without running the job or allocating devices.	No

Started-task restriction: do not specify TYPRUN for a started task. IBM states that a started task containing this parameter fails.

TYPRUN syntax on the JOB statement

Code one value on the JOB statement. The exact account information, programmer name, class, notification setting, and message options depend on local standards.

//CHKJCL   JOB (ACCT),'JCL CHECK',CLASS=A,MSGCLASS=X,
//             NOTIFY=&SYSUID,TYPRUN=SCAN
//STEP01   EXEC PGM=IEFBR14

The continued JOB statement ends its first line with a comma. Remove TYPRUN=SCAN before submitting the job for normal execution.

Use TYPRUN=SCAN to check JCL without execution

TYPRUN=SCAN is the value most developers use while checking a new or changed job. JES does not run any EXEC statement and does not allocate the DD statement devices. The converter can report issues such as invalid parameter-keyword spelling, invalid characters, unbalanced parentheses, misplaced positional parameters, and bad syntax in cataloged procedures invoked by scanned EXEC statements.

//PAYSCAN  JOB (ACCT),'PAY TEST',CLASS=A,MSGCLASS=X,
//             NOTIFY=&SYSUID,TYPRUN=SCAN
//SORT01   EXEC PGM=SORT
//SORTIN   DD DSN=PAY.INPUT,DISP=SHR
//SORTOUT  DD DSN=PAY.OUTPUT,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(5,2)),UNIT=SYSDA
//SYSOUT   DD SYSOUT=*
//SYSIN    DD *
  SORT FIELDS=(1,10,CH,A)
/*

Review the job's JES messages after submission. Converter messages commonly begin with IEFC. A clean scan means the converter accepted the statements it checked; it does not prove that every data set exists, every program is available, or every runtime path will succeed.

What TYPRUN=SCAN can miss

IBM documents that SCAN checks only through the converter, not the interpreter. It does not catch every invalid subparameter, misplaced statement, or incompatible parameter combination. For example, a data-set qualifier longer than eight characters can pass the scan and fail later during interpreter processing.

Release check: never treat a successful scan as permission to run production work without the normal peer review, scheduler controls, data-set checks, and change process.

Use TYPRUN=HOLD to delay execution

TYPRUN=HOLD places the job on hold before execution. An operator must release it before JES can select it to run. This can be useful when a job must wait for a controlled event outside the scheduler, but a production scheduler should normally own production dependencies.

//PAYHOLD  JOB (ACCT),'PAYROLL',CLASS=A,MSGCLASS=X,
//             NOTIFY=&SYSUID,TYPRUN=HOLD
//STEP01   EXEC PGM=PAYRUN
//SYSOUT   DD SYSOUT=*

HOLD is supported with JES2 and JES3. Release commands and authority rules differ by installation. Follow the site's operations procedure rather than assuming that a developer ID can release the job.

Use TYPRUN=JCLHOLD to hold before completed JCL processing

TYPRUN=JCLHOLD is a JES2-only value. JES2 holds the job before completing JCL processing. After the operator releases the job, JCL processing continues. If pending errors surface while JCL processing is completed, JES2 does not keep the job held; it completes JCL processing and places the job in the output queue.

//JCLWAIT  JOB (ACCT),'WAIT FOR JCL',CLASS=A,MSGCLASS=X,
//             NOTIFY=&SYSUID,TYPRUN=JCLHOLD
//STEP01   EXEC PGM=MYPROG
//SYSOUT   DD SYSOUT=*

This behavior differs from the old explanation that JCL errors are simply checked when the operator releases the job. The timing of JCL processing and the treatment of pending error messages are the points that matter.

Use TYPRUN=COPY to print the submitted job stream

TYPRUN=COPY is also JES2 only. JES2 copies the submitted input stream directly to a SYSOUT data set and schedules that output for processing. The job is not selected for execution. The output class is the JOB statement's MSGCLASS.

//COPYJCL  JOB (ACCT),'COPY JCL',CLASS=A,MSGCLASS=X,
//             TYPRUN=COPY
//STEP01   EXEC PGM=IEFBR14

Use COPY when the submitted JCL itself must be routed to output. It is not a substitute for SCAN because its purpose is copying the input stream, not validating execution readiness.

TYPRUN=HOLD versus TYPRUN=JCLHOLD

Question	HOLD	JCLHOLD
Supported JES types	JES2 and JES3	JES2 only
Hold point	Before execution	Before completed JCL processing
Release required	Yes	Yes
Normal use	Delay a converted job before execution	Delay completion of JCL processing
What an error can do	An input-service error can prevent the hold	Pending JCL errors can cause completion into the output queue instead of a continued hold

TYPRUN and workload schedulers

Do not leave TYPRUN=SCAN, HOLD, or JCLHOLD in production scheduler JCL unless the scheduler and operations procedures require it. A scheduled job that never executes can remain outside the expected tracking path. IBM specifically warns against storing TYPRUN=SCAN jobs in IBM Z Workload Scheduler's EQQJBLIB because the scheduler does not track those test submissions.

A safer change flow is to copy the JCL to a developer-controlled library, add TYPRUN=SCAN, submit and review the JES messages, remove the parameter, then return the approved member through the site's normal change process.

Common TYPRUN mistakes

• Expecting SCAN to find every error: it performs converter-level checking and can miss interpreter-time faults.
• Leaving SCAN in the production member: the job is submitted but none of its steps execute.
• Using COPY or JCLHOLD under JES3: both values are JES2 only.
• Using TYPRUN on a started task: IBM states that the started task fails.
• Assuming HOLD manages job dependencies: an enterprise scheduler is usually the correct owner of recurring production dependencies.
• Expecting SCAN to verify resources: it does not prove that a program, data set, catalog entry, security profile, tape volume, or temporary-space request will work at execution time.
• Using an installation-specific held class without checking: held job classes are defined locally and should not be copied blindly from another system.

TYPRUN testing checklist

1. Work from the approved test copy of the JCL.
2. Add TYPRUN=SCAN to the JOB statement.
3. Submit the job and confirm that no program step executed.
4. Review JES converter messages and correct reported JCL errors.
5. Check data-set names, DISP values, program names, procedures, symbolic parameters, security access, and scheduler variables separately.
6. Remove TYPRUN=SCAN.
7. Submit through the normal test or production-control process.

Related JCL guides

• JCL JOB statement and job-card parameters
• JCL JOB, EXEC, and DD tutorial
• JES2 and JES3 JECL statements
• JCL RESTART parameter
• JCL procedures and cataloged procedures

Official IBM references

• z/OS MVS JCL Reference: TYPRUN parameter
• TYPRUN subparameter definitions
• Scanning JCL for errors
• Holding job entrance

JCL TYPRUN questions

Does TYPRUN=SCAN execute any job steps?

No. JES scans the JCL through the converter without executing the job or allocating devices.

Does TYPRUN=SCAN find every JCL error?

No. It can find many syntax faults, but it does not perform every interpreter-time check and does not verify runtime resources.

What is the difference between HOLD and JCLHOLD?

HOLD delays the job before execution and works with JES2 or JES3. JCLHOLD is JES2 only and stops the job before JCL processing is completed.

Can TYPRUN be used for a started task?

No. IBM states that a started task fails when TYPRUN is specified.

Working rule: use SCAN for an initial converter check, remove it before execution, and still review the resources and controls that SCAN cannot validate.