Articles

JCL Interview Questions: Dataset Disposition, Conditional Steps, and Safe Restarts

Practice JCL interview questions with DISP outcomes, COND truth tables, persistent intermediates, and restart checks that prevent duplicate effects.

A batch job stops after its second step. The interviewer asks whether you can resubmit it with RESTART=TRANS. Your first task is to determine what that step will actually find: a cataloged input, a deleted temporary dataset, an existing output with the same name, or business updates already committed by a later attempt.

For JCL interview questions, treat restart as a dataset-and-effect problem as well as a step-selection problem. DISP describes allocation status and termination actions. Conditional execution decides which steps run. Neither mechanism, by itself, makes partial application output safe to repeat.

The following cases are original exercises grounded in IBM z/OS JCL documentation. They are not candidate reports, production job instructions or claims about an employer’s interview format.

How do the three DISP positions differ?

Official fact: IBM defines DISP as describing a dataset’s status and what should happen after normal or abnormal termination. The termination category matters independently of a program’s return-code value. IBM z/OS 3.1 DISP reference.

For the common form DISP=(status,normal,abnormal), read each position separately. NEW requests a new dataset; OLD requests an existing dataset with exclusive use; SHR requests shared use; MOD commonly supports appending to an existing sequential dataset and has creation behavior when it does not exist. Confirm dataset type and allocation details rather than applying the sequential-file explanation to every resource. IBM status subparameter.

The second and third positions describe disposition, not program success. CATLG records the dataset in the catalog; KEEP retains it; DELETE requests deletion under the applicable rules. Cataloging an output does not certify that its contents satisfy your business contract. IBM normal-termination disposition.

Consider DISP=(NEW,CATLG,DELETE). A normally terminating program that returns RC8 still takes the normal disposition path. An actual abend takes the abnormal path. RC8 can reject the business result while the step still terminates normally and takes CATLG.

A scheduler’s red status can make RC8 and an abend look identical even though one retained your output and the other deleted it. Ask for the actual step completion messages, not just the scheduler’s high-level failure label.

Walk through a three-step job

Original exercise: run R260 has three program steps. EXTRACT produces a persistent sequential input, TRANS validates and transforms it, and LOAD applies accepted rows to a business store. Dataset names include the run identifier. Application policies treat RC0–4 as acceptable and RC8 as rejection; those thresholds are chosen for this exercise, not universal IBM meanings.

Step and dataset	DD disposition	Observed outcome	Restart implication
EXTRACT creates APP.R260.RAW	NEW,CATLG,DELETE	RC0, normal end	RAW is retained and cataloged for a later run
TRANS reads RAW	SHR,KEEP,KEEP	Input can be reused	Verify identity and contents before resubmission
TRANS creates APP.R260.STAGED	NEW,CATLG,DELETE	RC8, normal end	STAGED can remain cataloged even though validation failed
LOAD reads STAGED	SHR,KEEP,KEEP	Bypassed by policy	No LOAD execution is established by this trace

The question is not simply whether the failed output exists. Ask whether it is complete and accepted. Suppose TRANS wrote sixty rows before detecting a malformed trailer and returning RC8. Its normal disposition can preserve those sixty rows, but your business gate must still prevent LOAD from treating them as the accepted batch.

If you resubmit TRANS unchanged, its NEW output requests the name of a dataset that may already exist. That is an allocation problem before the program’s transformation logic even starts. Do not describe RESTART as automatically replacing that output.

A safe proposal uses an agreed new attempt output or a controlled cleanup/replacement procedure after preserving necessary evidence. Define who owns the prior dataset and which downstream consumers may already reference it before proposing deletion. The interview exercise calls for a recovery decision, not a destructive command to run.

Does COND mean “run when true”?

No. Official fact: a satisfied return-code test in the COND parameter causes bypass; an EXEC-level bypass affects that step, while a JOB-level test can bypass the remaining steps. IBM also distinguishes bypass from abnormal termination. IBM bypassing or executing steps based on return codes.

For this original example, consider COND=(4,LT,EXTRACT). Compare the literal four with EXTRACT’s return code: if 4 < EXTRACT.RC, the test is true and this step is bypassed.

EXTRACT.RC = 0: 4 < 0 is false -> not bypassed by this test
EXTRACT.RC = 4: 4 < 4 is false -> not bypassed by this test
EXTRACT.RC = 8: 4 < 8 is true  -> bypassed by this test

The words “by this test” matter. Other conditions and a preceding abend can still determine execution. Do not label a false COND test as an unconditional promise that the step will run.

With multiple tests, explain each comparison and whether a satisfied test causes bypass. Read the comparison as “four is less than EXTRACT’s return code” before choosing the skip branch. Translating COND into an ordinary-language skip rule before interpreting it avoids silently reversing the operands.

A return-code policy should be program-specific. RC4 can mean an acceptable warning for one utility and an unacceptable business condition for another. Your JCL answer needs the invoked program’s documented contract.

When is IF/THEN clearer?

An IF expression describes the branch you want to execute. For the original policy, a skeleton is:

//IFGOOD IF (TRANS.RC LE 4) THEN
//LOAD   EXEC PGM=APPLOAD
//*      Required DD statements belong here
//       ENDIF

This is a teaching fragment, not a submit-ready job. The preceding TRANS step, JOB statement, libraries, DD definitions and installation requirements are omitted deliberately.

Official scope: IBM’s JCL relational keywords include RC, RUN and abend-related tests. An unqualified RC refers to the highest preceding step return code, so use a step-qualified reference when your policy concerns one producer. IBM relational-expression keywords.

Original counterexample: an unrelated diagnostic step returns RC8 while TRANS returns RC0. Testing global RC can reject the load even though the intended producer met its threshold. Conversely, qualifying the producer does not validate the produced data; it just makes the control dependency explicit.

If you permit an alternate branch after an abend, state that policy separately. EVEN and ONLY alter behavior after abnormal termination; neither proves that the step’s inputs survived or that the program is safe to run. A cleanup or diagnostic step needs an input contract too.

What survives across a resubmitted job?

Official fact: a temporary dataset such as &&WORK belongs to the job’s temporary-data lifecycle. IBM describes how dispositions including KEEP or CATLG on temporary datasets are treated and how those datasets are deleted at job termination. PASS between steps is not a promise of availability in a later resubmitted job. IBM temporary datasets.

If TRANS depends on an EXTRACT-created &&WORK, a resubmission starting at TRANS cannot simply assume that skipped EXTRACT will supply it again. The recovery design needs a persistent, identified intermediate or an earlier restart point that recreates the input.

For APP.R260.RAW, verify the producing attempt, copybook version, row count and business totals before reuse. APP.R260.RAW from one attempt is not interchangeable with a newer extraction made from changed source data. Record the actual dataset name, volume/catalog evidence, schema version, row count and relevant business totals.

For a GDG-based design, record the concrete generation that the prior attempt consumed. A relative reference is convenient during normal execution; recovery must establish which historical object the application intends to reuse. Do not infer that every later submission resolves relative names to the same data.

What does RESTART actually select?

Official fact: IBM documents deferred restart through the JOB statement, selecting a step, a procedure step, or a checkpoint when the relevant operands and support are present. A procedure-step form uses the job step and the internal procedure step name. IBM z/OS 3.2 RESTART parameter.

A step restart begins execution at that selected point. It is not a restoration of all in-memory program state or a reversal of every earlier external effect. Checkpoint restart is a separate mechanism; saying “restart” does not establish that the program took a usable checkpoint.

Check the retained input and output allocation before choosing TRANS, or the next attempt can fail before your repair runs.

For the R260 case, name the prerequisites explicitly: accepted RAW survives; the TRANS attempt has a safe output allocation plan; validation and control totals are rerun; LOAD has not already applied the same accepted batch, or has a supported repeat-handling contract. Only then can you explain why the selected restart point is appropriate.

Conditions in a restarted execution also deserve review. Do not assume that a skipped earlier step contributes the same observed return code as in the previous attempt. An explicit acceptance record for the persistent intermediate is a different kind of evidence from a return code generated in the current run.

What if LOAD abends after partial updates?

Original second scenario: TRANS finishes successfully. LOAD commits forty of sixty intended rows, then abends. Its input dataset remains because the DD requests KEEP on either termination path. That retained input says nothing about which business updates are already durable.

If LOAD appends all sixty rows on resubmission, the first forty can be duplicated. A MOD output does not make the append idempotent. Replacing a report might be acceptable under a documented replacement policy, while repeating a payment instruction could create another externally visible effect.

Choose a recovery contract appropriate to the application: a run-and-record identity with duplicate detection, a verified application checkpoint, an all-or-nothing transaction where genuinely supported, or reconciliation before replay. These are design options, not features supplied automatically by JCL.

For an external action whose response was lost, distinguish “not confirmed” from “did not happen.” Capture the stable request identity and consult the external system’s supported status/retry contract. A second job submission is not evidence that the first action was canceled.

How do you present a safe restart answer?

Start with one observable claim: “TRANS returned RC8 normally, so I must inspect its cataloged output before choosing a restart.” Then describe the data dependency, output naming plan and business acceptance gate. Explain what changes if the event was an abend instead.

The saved local Python controls check the constructed CATLG/DELETE branches, literal-four comparisons against RC0/4/8, and a forty-of-sixty replay ledger. They do not submit JCL, simulate JES or validate installation-specific allocation and recovery behavior. In a real project, use the actual job log, catalog and application reconciliation evidence.

Keep cleanup and acceptance separate. A successful cleanup utility can clear an allocation conflict while leaving the original business failure unresolved. The reviewer needs to know why your next attempt will process the intended input and why its result will not be applied twice.

Practice the dependency and recovery reasoning

Question	Practice focus
Count Completed Jobs in a Serial Multi-Worker Pipeline	Trace which stage completed rather than assuming the job finished
Design a Dependency-Aware CI/CD Pipeline	Make producer prerequisites explicit before running a dependent step
Design a Metrics Ingestion Pipeline	Separate received data from accepted durable output
Design Chargeback Ingestion and CSV Delivery	Reconcile repeated batch delivery with stable identities
Design a Parallel and Resumable Model Downloader	Explain checkpointed work and incomplete artifact publication

Start with Design a Parallel and Resumable Model Downloader, then compare its resumable artifact contract with the persistent input your restarted JCL step needs.

For JCL interview questions, finish with the exact restart point, the datasets it requires and the evidence that makes its repeated effects acceptable. That is a complete answer to “can we rerun it?”

Sources and Further Reading

Research checked October 5, 2026. Dataset names and acceptance thresholds are original examples; no job was submitted.