One PROC used by dozens of jobs — best pattern to pass job-specific parms?

JES2/3, JCL, utilities.
Aarohi Saxena
Registered Member
Posts: 25
Joined: Sun Mar 02, 2014 1:11 am

One PROC used by dozens of jobs — best pattern to pass job-specific parms?

Post 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?
 
User avatar
BearGFR
New Member
Posts: 8
Joined: Wed Jun 24, 2026 4:58 pm
Contact:

Re: One PROC used by dozens of jobs — best pattern to pass job-specific parms?

Post 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,

 
BearGFR
Image
Post Reply Previous topicNext topic

Create an account or sign in to join the discussion

You need to be a member in order to post a reply

Create an account

Not a member? register to join our community
Members can start their own topics & subscribe to topics
It’s free and only takes a minute

Register

Sign in

Return to “JCL - Job Control Language.”