Rerun
Running a job again after it failed or produced wrong results, either from the beginning or from a chosen step.
Also written rerun a job, job rerun, resubmit, rerun versus restart
A rerun means running a job again. In support work it usually follows a failure or a problem with the data, once the cause has been fixed. People sometimes distinguish a rerun, which starts again from the beginning, from a restart, which starts from a later step.
The key question is what the first run already did. If it updated a database, wrote to a GDG or sent a file before failing, running it again could update the database twice, create an extra generation or send a duplicate file. Some jobs are safe to run any number of times. Many are not, and need data restored from a backup, or a step skipped, before a rerun.
The runbook for each production job should say how to rerun it safely. In practice, reruns are done through the batch scheduler, so it knows what happened and can release the jobs that follow.
The habit to build is simple: before rerunning anything in production, read the runbook, check what the failed run changed, and agree the plan with whoever owns the job.
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
- RESTART parameterA JOB statement parameter that starts a job from a named step, skipping the steps before it.
- Batch schedulerSoftware that submits production jobs automatically in the right order, at the right time, based on what has already succeeded.
- Production supportKeeping live systems running: diagnosing failures, fixing what broke, and getting the service back.
- RunbookThe written procedure for operating a system or responding to a known failure, step by step.
- Generation data groupA set of datasets holding successive versions of the same file, so today's copy, yesterday's and last week's all exist under one name.