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.

Syntax

jcl
1
//jobname JOB parameters,TYPRUN=option

Options

OptionDescription
SCANChecks JCL syntax without executing the job. The system scans all JCL statements for syntax errors and returns messages, but does not execute any programs or allocate resources.
HOLDPlaces the job in hold status after converting the JCL. The job remains in the queue until released by an operator command or other mechanism.
JCLHOLDJES3 only. Similar to HOLD, but job is held until specifically released by a Modify (F) command.
COPYJES2 only. Job is processed by the JCL converter, then copied directly to the output processor. No execution occurs. Useful for creating job output without execution.

System Differences

  • JES2: Supports SCAN, HOLD, and COPY options
  • JES3: Supports SCAN, HOLD, and JCLHOLD options
  • Note: Available options may vary by z/OS version and local system configuration

Examples

Syntax Checking a Job

jcl
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

jcl
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

jcl
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

FeatureTYPRUNAlternativeKey Difference
Syntax checkingTYPRUN=SCANMSGLEVEL=(1,1)MSGLEVEL produces detailed messages but attempts execution
Job holdingTYPRUN=HOLD/*HOLD statement/*HOLD is a JES2 JECL statement, not standard JCL
Job holdingTYPRUN=HOLDSCHEDULE parameterSCHEDULE provides more options for timed execution
No executionTYPRUN=COPYEXEC PGM=IEFBR14IEFBR14 provides minimal execution vs. no execution

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 JES-specific options - Using TYPRUN=COPY on JES3 or TYPRUN=JCLHOLD on JES2
    jcl
    1
    //INCOMPATIBLE JOB (ACCT),'WRONG JES',TYPRUN=JCLHOLD  // JES3 only
  • 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

Related Pages