TYPRUN Parameter

Purpose

The TYPRUN parameter on the JOB statement specifies special processing options for a job. It allows you to request that the system check the JCL syntax without actually executing the job, hold the job for later release, or perform other special processing options. This can be particularly useful for testing new JCL or when you want to prepare jobs for execution at a later time.

The keyword is TYPRUN. People often search for TYPERUN, with an extra E. SCAN, HOLD, and JCLHOLD are explained on the TYPERUN tutorial.

Syntax

1
//jobname JOB parameters,TYPRUN=option

Options

System Differences

• JES2: Supports SCAN, HOLD, JCLHOLD, and COPY
• JES3: Supports SCAN and HOLD. JCLHOLD and COPY are JES2 only. On JES3, HOLD=YES on //*MAIN also holds a job.
• Note: Available options may vary by z/OS version and local system configuration

Examples

Syntax Checking a Job

1
//TESTJOB JOB (ACCT),'SYNTAX CHECK',CLASS=A,TYPRUN=SCAN

The system checks JCL syntax but doesn't execute the job

Holding a Job for Later Execution

1
//HOLDJOB JOB (ACCT),'HOLD JOB',CLASS=B,TYPRUN=HOLD

The job is held in the queue after JCL conversion until it is released

Creating Job Output Without Execution

1
//COPYJOB JOB (ACCT),'COPY JOB',CLASS=C,TYPRUN=COPY

JES2 only: Creates job output without executing the job

Use Cases

• SCAN
  • Testing new or modified JCL before actual execution
  • Checking JCL validity in complex job streams
  • Validating procedure substitutions
  • Identifying syntax errors in JCL without wasting resources on failed jobs
• HOLD
  • Preparing jobs that need to be run during specific time windows
  • Setting up jobs that require operator intervention before execution
  • Preparing a batch of jobs that must be released in a specific sequence
  • Submitting jobs that require resources not currently available
• COPY
  • Generating sample job output for documentation
  • Creating test cases for output processing
  • Testing report formatting without executing programs

Processing Details

SCAN Processing

1. The system converts and checks all JCL statements for syntax errors
2. Statements are expanded and symbolic parameters are substituted
3. JCL errors are identified and reported in the job's output
4. No steps are executed, no datasets are created, no programs are loaded
5. Job log and messages are produced showing the results of the scan

HOLD Processing

1. The system converts the JCL and places the job in held status
2. The job remains in the input queue until released
3. Job can be released using operator commands:
   plaintext

   1
   2
   3
   4
   $A 'jobname'      /* JES2 command to release a job */
   $TO JOB(jobname),RELEASE  /* JES2 command to release */
    
   *F J=jobname,R    /* JES3 command to release a job */

4. When released, the job executes normally

TYPRUN vs. Other Job Control Methods

Limitations

• SCAN doesn't detect all errors - It only checks JCL syntax, not program logic or runtime errors
• HOLD jobs consume resources - Held jobs occupy space in the JES queue
• System-specific options - Some options are specific to either JES2 or JES3
• No execution checkpoints with SCAN - Cannot verify program logic or test data processing
• Security validations - Some RACF or security validations may not be fully tested with SCAN

Common Mistakes

• Confusing SCAN with debugging - SCAN only checks JCL syntax, not program execution
  jcl

  1
  //WRONGUSE JOB (ACCT),'DEBUG',TYPRUN=SCAN  // Won't debug program logic

• Forgetting to release held jobs - Jobs with TYPRUN=HOLD remain in the queue indefinitely
  jcl

  1
  //ABANDONED JOB (ACCT),'FORGOTTEN',TYPRUN=HOLD  // Will remain in queue

• Using JES2-only values on JES3 - TYPRUN=COPY and TYPRUN=JCLHOLD are JES2 only
  jcl

  1
  //INCOMPAT JOB (ACCT),'WRONG JES',TYPRUN=JCLHOLD

• Relying on SCAN for complete validation - Some errors only appear during execution
  jcl

  1
  //MISLEADING JOB (ACCT),'INCOMPLETE TEST',TYPRUN=SCAN  // Won't catch runtime issues

Best Practices

• Use TYPRUN=SCAN during JCL development to catch syntax errors early
• Consider TYPRUN=HOLD for jobs that need to be run during specific maintenance windows
• When using TYPRUN=HOLD, establish a process to ensure held jobs are released appropriately
• After using SCAN to verify syntax, test with a controlled execution to verify complete functionality
• For JES2 environments, TYPRUN=COPY can be useful for testing output formatting without execution
• Document any held jobs in operations procedures to ensure they aren't forgotten
• Avoid using TYPRUN in production job streams; it's primarily a development/testing tool

Related Concepts

• JOB Statement - The TYPRUN parameter is specified on the JOB statement
• MSGLEVEL Parameter - Controls the level of detail in job messages
• CLASS Parameter - Determines the job class, which affects execution priority

Related Pages

• JOB Statement
• CLASS Parameter
• MSGLEVEL Parameter
• MSGCLASS Parameter