Explain JOBLIB and STEPLIB: Load Module Search Order in IBM Mainframes

21 / 60

JCLintermediate

JOBLIB and STEPLIB: Load Module Search Order

Understand how JOBLIB and STEPLIB direct the system's search for executable load modules and why their scope and precedence matter.

EXEC PGM=SOMEPGM requires the system to find a load module called SOMEPGM. JOBLIB and STEPLIB say where to look.

JOBLIB is a company-wide employee directory checked for every meeting all day, while STEPLIB is a sticky note taped to one specific meeting room door overriding just that one meeting's contact list — and if both exist for the same meeting, everyone follows the sticky note, not the company directory.

Key Concepts

JOBLIB applies to the whole job.

    //MYJOB  JOB ...
    //JOBLIB DD DSN=PROD.LOADLIB,DISP=SHR
    //STEP1  EXEC PGM=PGMA

STEPLIB applies to one step, and takes precedence there:

    //STEP2   EXEC PGM=PGMB
    //STEPLIB DD DSN=TEST.LOADLIB,DISP=SHR

For STEP2 the JOBLIB is ignored entirely. Not searched afterwards — ignored. That is the detail people miss, and it means a step-level STEPLIB must list every library that step needs, including ones the JOBLIB provided.

The search order.

    1. STEPLIB, if this step has one
    2. otherwise JOBLIB, if the job has one
    3. the system link list and LPA

It applies to dynamic CALLs too, not only the main program. A dynamically called subprogram is found through the same chain, which is what makes concatenation order matter so much.

The classic scenario. "You deployed a fix to a subprogram and it still behaves like the old version."

    //STEPLIB DD DSN=TEST.LOADLIB,DISP=SHR     <- old copy still here
    //        DD DSN=PROD.LOADLIB,DISP=SHR     <- the fix is here

Concatenations are searched in order. The old module is found first and loaded, and the corrected one is never reached.

Nothing reports this. The job runs, uses the wrong version, and the only symptom is that a deployment had no effect. It is the standard cause of "works in test, fails in production" and its reverse.

How to confirm which module actually loaded. The job log records the library each module came from, and ISRDDN (or a similar tool) shows the concatenation as allocated. Checking that is faster than reasoning about which library should have won.

ISRDDN

The practical habit. Keep concatenations short and ordered deliberately — the library being tested first, production behind it — and know that adding a library to the front of a STEPLIB changes resolution for every module in that step, not just the one you meant.

What the interviewer is probing.1. "What is the search order for a load module?" Probing: the fundamentals. Stalls: "The library." Moves up: STEPLIB if present, otherwise JOBLIB, then the system link list — STEPLIB on a step overrides JOBLIB for that step.

2. "Why does this matter for testing?" Probing: the practical use. Stalls: "It does not." Moves up: a STEPLIB pointing at a test load library lets you run a new module against production JCL without touching the production library.

3. "What is the classic failure here?" Probing: experience. Stalls: "None." Moves up: a forgotten STEPLIB in production JCL, so the job quietly runs a test module — or an old module because a library was not refreshed.

4. "What does concatenating libraries mean?" Probing: the mechanism. Stalls: "Joining them." Moves up: they are searched in the order coded, so the first match wins — which is how an obsolete copy in an earlier library shadows the current one.