Page 1 of 1
One PROC used by dozens of jobs — best pattern to pass job-specific parms?
Posted: Sun Oct 05, 2025 12:18 am
by Aarohi Saxena
We want to avoid PROC duplication. SYMBOLICS help but get unwieldy.
```
//CARDSVC JOB (ACCT),'DAILY',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//STEP1 EXEC PGM=CARDCHK
//SYSIN DD *
* business rules here
/*
//INFILE DD DSN=CARDS.BACKUP.STAGING,DISP=SHR
//OUTFILE DD DSN=FIN.WORK.REJECT,DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(50,10),RLSE),RECFM=VB,LRECL=300
```
Patterns like INCLUDE members, PARM= on EXEC, or cataloged PROCs calling sub-PROCs — what scales best?
Re: One PROC used by dozens of jobs — best pattern to pass job-specific parms?
Posted: Wed Jun 24, 2026 6:09 pm
by BearGFR
Using symbols is the best solution. Yes, they can get 'busy' but not if you're smart about how you structure them. If the elements you need to vary are LPAR dependent (like in a parallel sysplex environment) then you can control using the 4-byte LPAR system name as part of the reference.
You can also use the dynamic symbol &JOBNAME (or perhaps an extracted substring of &JOBNAME, depending on your shop naming standards) to derive the name of an // INCLUDE member that will itself pull in a collection of // SET statements approriate to the job. You can use the same construct to add jobname-specific libraries to the effective PROCLIB concatenation for the JOB
Example:
//... JOB
//SYMS INCLUDE MEMBER=XXX&SYSNAME
--or--
//SYMS INCLUDE MEMBER=&JOBNAME
--or--
//SYMS INCLUDE MEMBER=&JOBNAME(1:4).XXXX
--or--
//... JOB
// JCLLIB ORDER=(HLQ.SYSTEM.&JOBNAME..PROCLIB,SYSx.&SYSNAME..CUSTOM.PROCLIB,.....etc..etc)
--or--
// SET JOBSYM=<somevalue>
// INCLUDE MEMBER=&JOBSYM
The better your shop naming standards are, the easier this will be to do. If you're careful you should be able to derive a set of standards for such things that allow you to "set it once and forget it". Note that there are parameter settings in your shop's JES parms that can affect how JCL symbols are resolved and substituted that can have an affect on how you code your JCl, so you may need to coordinate with your system programmer(s) on this.
In all of "my" JCL, I strive to structure it so that every element in the job that I might need to change is represented by a JCL symbol (// SET statement) that appears at the top/first page of the JCL member when I edit it.
Cheers,