TYPRUN
A JOB statement parameter that changes how a job is handled, most often to check its JCL without running it, or to hold it.
Also written TYPRUN=SCAN, TYPRUN=HOLD, JCL check, scan JCL
TYPRUN is a parameter on the JOB statement. Its two common values do quite different things.
TYPRUN=SCAN tells JES to check the JCL for errors without running the job. The output lists the JCL and any errors found. It catches mistakes such as misspelled keywords, missing commas and wrong parameters. It does not catch everything: it cannot tell you that a dataset is missing or that a program will fail, because nothing is actually run.
TYPRUN=HOLD puts the job in the queue but holds it there until someone releases it, from SDSF or with an operator command. That is useful when a job must not start until something else is ready, or when you want to check it before it runs.
A habit worth building is to scan new or changed JCL before submitting it for real, especially for production jobs. It is quick and it finds the simple mistakes that would otherwise end in a JCL error.
Where can I learn this hands-on?
Right here, at ZedBank. You take a junior job at a simulated bank and learn each part of the work by doing it, with Zed beside you. There's nothing to install.
Start at ZedBankRelated
- JOB statementThe first statement in every job, giving it a name and telling the system who is running it and how to treat it.
- JCLJob Control Language: the language used to tell the mainframe what programs to run, in what order, and with what files.
- SubmitHanding JCL to the system to be run, which queues it as a job and gives it a job number.
- JES2The job entry subsystem: the part of z/OS that queues jobs, decides when they run, and collects their output.
- Held outputJob output kept on the spool for you to look at instead of being printed, or a job kept waiting until it is released.
- JCL errorA job that fails before running any program, because the JCL itself is wrong or something it names cannot be found.