Explain JCL Procedures (PROCs) and Symbolic Parameters in IBM Mainframes

A PROC is a reusable block of JCL steps. Symbolic parameters are the holes you fill in when you use it. Production batch runs almost entirely through PROCs

All topics

14 / 60

JCLintermediate

JCL Procedures (PROCs) and Symbolic Parameters

Understand how cataloged and in-stream PROCs let JCL be templated and reused across jobs via symbolic parameters.

A PROC is a reusable block of JCL steps. Symbolic parameters are the holes you fill in when you use it.

A PROC is a form letter template with blanks like {{CUSTOMER_NAME}} — the template itself never changes, but each mail merge run fills in different names and addresses without anyone retyping the letter body.

Key Concepts

Production batch runs almost entirely through PROCs rather than hand-written job steps.

    //COMPLINK PROC LIB='PROD.LOADLIB',SRC=
    //COMP     EXEC PGM=IGYCRCTL
    //SYSIN    DD DSN=&SRC,DISP=SHR
    //LINK     EXEC PGM=IEWL
    //SYSLMOD  DD DSN=&LIB,DISP=SHR
    //         PEND

Invoked with values supplied:

    //STEP1 EXEC COMPLINK,SRC='MY.SOURCE(PGMA)',LIB='TEST.LOADLIB'

Substitution happens at invocation, not by editing. The PROC's own LIB='PROD.LOADLIB' is a default. The LIB= on the EXEC overrides it for this run only, and the PROC on disk is untouched.

LIB='PROD.LOADLIB'LIB=EXEC

That is the standard trace question: given a default and an override, the override wins, and it wins only for that invocation.

Cataloged or instream. A cataloged PROC lives as a member in a procedure library and is shared by every job that names it. An instream PROC is defined at the top of a job between PROC and PEND, and is available only within that job.

PROCPEND

Why this matters operationally. One PROC encoding "compile, link and run this kind of program" is used by hundreds of jobs, each supplying only what differs.

Change a compiler option in that one PROC and every job picks it up at its next run. The alternative is editing hundreds of job members and missing some.

Overriding a DD inside a PROC uses the step name:

    //STEP1 EXEC COMPLINK
    //COMP.SYSIN DD DSN=OTHER.SOURCE(PGMB),DISP=SHR

COMP.SYSIN means "the SYSIN in the COMP step of the PROC". Overrides must appear in the same order as the steps in the PROC, which is a frequent source of JCL errors that read as though a DD is unknown.

COMP.SYSIN

The trap with symbolics. An unresolved symbolic does not fail loudly — it substitutes as nothing:

    DSN=&HLQ..CUSTOMER.MASTER      with HLQ unset
    -> DSN=.CUSTOMER.MASTER        an invalid name, or worse, a valid one

Set defaults in the PROC for every symbolic, so a forgotten parameter produces a sensible dataset rather than a surprise.

What the interviewer is probing.1. "Why use a PROC?" Probing: the purpose. Stalls: "Shorter JCL." Moves up: one maintained definition of a job step shared by many jobs, with symbolics supplying what differs.

2. "What is the difference between an instream and a cataloged PROC?" Probing: the distinction. Stalls: "Location." Moves up: instream lives inside the job and is for testing; cataloged lives in a PROCLIB and is the shared production form.

3. "How do you override a DD inside a PROC?" Probing: the practical skill. Stalls: "You cannot." Moves up: code the DD on the EXEC step qualified as procstepname.ddname, in the same order as in the PROC.

4. "What is the trap with symbolic parameters?" Probing: experience. Stalls: "None." *Moves up:* an unresolved symbolic fails at conversion with a JCL error, and a defaulted one can silently point a production job at the wrong dataset.