===================================================== How a PROC works - merging your JCL with the PROC JCL ===================================================== -IAN! idallen@idallen.ca The JCL that you submit is merged with the JCL from any PROCs that you use. Here are some simplified examples of what that looks like. Below is a simplified sample three-step (compile, link, GO) PROC listing from the SYS1.PROCLIB dataset. Real-world PROCs are usually much longer. //*** THIS IS THE COBOLCLG CATALOGED PROCEDURE ************* //COBOLCLG PROC //********************************************************** //COB2 EXEC PGM=IGYCRCTL,PARM=(LIST,OBJ),REGION=1024K //SYSPRINT DD SYSOUT=A //SYSLIB DD DSN=COBOL.SRCLIB,DISP=(SHR,KEEP) //SYSLIN DD DISP=(NEW,PASS),UNIT=DASD,BLKSIZE=4080, // SPACE=(4080,(100,100)) //********************************************************** //LKED EXEC PGM=IEWL,REGION=1024K //SYSPRINT DD SYSOUT=A //SYSLIB DD DSN=COBOL.OBJLIB,DISP=(SHR,KEEP) //SYSLIN DD DSN=*.COB2.SYSLIN,DISP=(OLD,DELETE) //SYSLMOD DD DSN=&&GOSET(GO),DISP=(NEW,PASS), // UNIT=DASD,SPACE=(1024,(500,100,1)) //********************************************************** //GO EXEC PGM=*.LKED.SYSLMOD,ADDRSPC=REAL,REGION=1024K //*** END OF COBOLCLG CATALOGED PROCEDURE ****************** Here are some examples of how your JCL affects the merged output when your JCL is combined with the JCL in the above COBOLCLG PROC: 1) Adding DDnames to a PROC step Consider the following sample JCL that uses the above COBOLCLG PROC: //MYJOB JOB 123456,'IAN ALLEN',CLASS=A //CLG EXEC PROC=COBOLCLG //COB2.SYSIN DD DSN=MY.SRC,DISP=(OLD,KEEP) //GO.INPUT DD DSN=MY.DATA,DISP=(OLD,KEEP) //GO.OUTPUT DD SYSOUT=A When the above JCL is merged with the JCL in the COBOLCLG PROC by JES, this is the fully merged result that gets put into the JES job queue: //MYJOB JOB 123456,'IAN ALLEN',CLASS=A //********************************************************** //COB2 EXEC PGM=IGYCRCTL,PARM=(LIST,OBJ),REGION=1024K //SYSPRINT DD SYSOUT=A //SYSLIB DD DSN=COBOL.SRCLIB,DISP=(SHR,KEEP) //SYSLIN DD DISP=(NEW,PASS),UNIT=DASD,BLKSIZE=4080, // SPACE=(4080,(100,100)) //SYSIN DD DSN=MY.SRC,DISP=(OLD,KEEP) # ADDED BY JES //********************************************************** //LKED EXEC PGM=IEWL,REGION=1024K //SYSPRINT DD SYSOUT=A //SYSLIB DD DSN=COBOL.OBJLIB,DISP=(SHR,KEEP) //SYSLIN DD DSN=*.COB2.SYSLIN,DISP=(OLD,DELETE) //SYSLMOD DD DSN=&&GOSET(GO),DISP=(NEW,PASS), // UNIT=DASD,SPACE=(1024,(500,100,1)) //********************************************************** //GO EXEC PGM=*.LKED.SYSLMOD,ADDRSPC=REAL,REGION=1024K //INPUT DD DSN=MY.DATA,DISP=(OLD,KEEP) # ADDED BY JES //OUTPUT DD SYSOUT=A # ADDED BY JES Notice the three added DDnames, each added to the correct step in the PROC. JES knows in which step to add the DDname because you code compound DDnames in your JCL that include the step name in front of the DDname. The step names tell JES where to merge in the DDnames. If you mis-spell the step name in your JCL (e.g. COBX.SYSIN), then JES cannot identify to which step in the PROC your DDname should be added; this causes a JCL error. 2) Over-riding existing DDnames in a PROC step Consider the following sample JCL that uses the above COBOLCLG PROC: //MYJOB JOB 123456,'IAN ALLEN',CLASS=A //CLG EXEC PROC=COBOLCLG //COB2.SYSIN DD DSN=MY.SRC,DISP=(OLD,KEEP) //COB2.SYSPRINT DD SYSOUT=B //LKED.SYSLIB DD DSN=MY.OBJLIB,DISP=(SHR,KEEP) //GO.INPUT DD DSN=MY.DATA,DISP=(OLD,KEEP) //GO.OUTPUT DD SYSOUT=A When the above JCL is merged with the JCL in the COBOLCLG PROC by JES, this is the fully merged result that gets put into the JES job queue: //MYJOB JOB 123456,'IAN ALLEN',CLASS=A //********************************************************** //COB2 EXEC PGM=IGYCRCTL,PARM=(LIST,OBJ),REGION=1024K //SYSPRINT DD SYSOUT=B # REPLACED BY JES //SYSLIB DD DSN=COBOL.SRCLIB,DISP=(SHR,KEEP) //SYSLIN DD DISP=(NEW,PASS),UNIT=DASD,BLKSIZE=4080, // SPACE=(4080,(100,100)) //SYSIN DD DSN=MY.SRC,DISP=(OLD,KEEP) # ADDED BY JES //********************************************************** //LKED EXEC PGM=IEWL,REGION=1024K //SYSPRINT DD SYSOUT=A //SYSLIB DD DSN=MY.OBJLIB,DISP=(SHR,KEEP) # REPLACED BY JES //SYSLIN DD DSN=*.COB2.SYSLIN,DISP=(OLD,DELETE) //SYSLMOD DD DSN=&&GOSET(GO),DISP=(NEW,PASS), // UNIT=DASD,SPACE=(1024,(500,100,1)) //********************************************************** //GO EXEC PGM=*.LKED.SYSLMOD,ADDRSPC=REAL,REGION=1024K //INPUT DD DSN=MY.DATA,DISP=(OLD,KEEP) # ADDED BY JES //OUTPUT DD SYSOUT=A # ADDED BY JES As before, we have three added DDnames. Note that the SYSPRINT DDname in the COB2 step has been replaced ("over-ridden") with the one from our JCL. Note that the SYSLIB DDname in the LKED step has been replaced ("over-ridden") with the one from our JCL. JES knows in which step to replace the DDnames because you code compound DDnames in your JCL that include the step name in front of the DDname. The step names tell JES where to merge in the DDnames. You might think of a cataloged procedure as a set of "default" JCL that will be used unless you over-ride parts of it with your own JCL. To over-ride a DDname in a procedure, you need to know the DDname and the step name in which it is used inside the procedure. When you code //stepname.ddname DD ... in your JCL, it causes JES to insert (add or over-ride) the DDname into the specified step inside the PROC. The resulting merged JCL is placed in the job queue and executed. Note that if you try to over-ride an existing DDname in a PROC but make a typing error in the DDname half of the compound DDname (e.g. LKED.SYSLOB), it will have no effect on the merged JCL and will cause no JCL error. The mis-spelled DDname will be added to the step that you specify; but, nothing will use it - this is not detected as an error. The existing default JCL in the PROC will remain unchanged.