Question

I have JCL, which is executing one catalog procedure. In catalog procesdure one COBOL-DB2 pgm is being executed.


Below is my JCL

//A JOB (@),'CALL DB2',NOTIFY=&SYSUID
//JS010 EXEC TESTPROC

Below is my TESTPROC

//TESTPROC
//PS010 EXEC PGM=IKJEFT01,,DYNAMNBR=20
//STEPLIB DD DSN=TEST.LOADLIB,DISP=SHR
//SYSTSPRT DD SYSOUT=*                     
//SYSPRINT DD SYSOUT=*                     
//SYSUDUMP DD SYSOUT=*                     
//SYSTSIN  DD DSN=TEST.PDS(TESTPGM), 
//            DISP=SHR            
//SYSOUT DD SYSOUT=*

below is my SYSTIN data --TESTPGM

DSN SYSTEM(TEST)                    
RUN PROGRAM(TESTPGM) PLAN(TESTPLAN)
END 

My query is can I use symbolic parameters in place of TESTPGM and TESTPLAN in SYSTIN data member TESTPGM?

Regards, Saisha :)

Was it helpful?

Solution

As mentioned below you could have the PDS Member name become a symbolic value and then define each member in the PDS to point to a different program. Using your JCL as an example:

//TESTPROC PROC MYPGM=
//PS010 EXEC PGM=IKJEFT01,,DYNAMNBR=20
//STEPLIB DD DSN=TEST.LOADLIB,DISP=SHR
//SYSTSPRT DD SYSOUT=*                     
//SYSPRINT DD SYSOUT=*                     
//SYSUDUMP DD SYSOUT=*                     
//SYSTSIN  DD DSN=TEST.PDS(&MYPGM), 
//            DISP=SHR            
//SYSOUT DD SYSOUT=*

In the above example your EXEC statement would envoke the proc as:

//JS010 EXEC TESTPROC,MYPGM=TESTPGM

Another option, you could over-ride the SYSTSIN DD directly as follows:

//A JOB (@),'CALL DB2',NOTIFY=&SYSUID
//JS010 EXEC TESTPROC
//PS010.SYSTSIN DD *
DSN SYSTEM(TEST)                    
RUN PROGRAM(TESTPGM) PLAN(TESTPLAN)
END
/*
//

One other suggestion... In your final implementation you might want to consider separating the

DSN SYSTEM(TEST)

from the

RUN PROGRAM(TESTPGM) PLAN(TESTPLAN)
END

The reason is that you may find you want to run the program in multiple DB2 environments, not just SYSTEM(TEST). To do this, simply add another parameter DB2SYS= and modify as follows:

//TESTPROC PROC DB2SYS=MYTEST,MYPGM=
...
//SYSTSIN  DD DSN=TEST.PDS(&DB2SYS),DISP=SHR
//         DD DSN=TEST.PDS(&MYPGM),DISP=SHR

where PDS Member MYTEST has the DSN SYSTEM(TEST) statement already coded.

OTHER TIPS

The short answer is no. If you have symbolic parameters in the control cards in the PDS your SYSTSIN DD statement references, they (the symbolic parameters) will not be resolved.

One way around this is to have a separate program, executing in a separate step within your procedure prior to your PS010 step, that takes in parameters and text and writes a temporary file. The symbolic parameters will be resolved in that program's PARM=.

//PS001    EXEC PGM=LOADPARM,PARM='DSN SYSTEM(&DSNSYS)'
//SYSPRINT DD  SYSOUT=*
//OUTPUT01 DD  DISP=(,PASS), 
//             DSN=&&DSNSYS, 
//             AVGREC=U, 
//             LRECL=80,  
//             RECFM=FB, 
//             SPACE=(80,1)
//****

The hypothetical program LOADPARM would simply take its input parm and write it to OUTPUT01, being careful to pad it on the right with blanks. In PS010 you would then have a SYSTSIN that looks like...

//SYSTSIN  DD  DISP=(OLD,DELETE),DSN=&&DSNSYS
//         DD  DISP=SHR,DSN=TEST.PDS(TESTPGM)

...where the TESTPGM member looks like...

RUN PROGRAM(TESTPGM) PLAN(TESTPLAN)
END

In this manner, your cataloged procedure is ignorant of which DB2 subsystem it is accessing. That information is supplied in the execution JCL with the DSNSYS symbolic parameter.

There are other ways to approach this problem, for instance you could have a symbolic parameter that resolves to a known member in a shared PDS, having one member per DB2 subsystem.

Nope, we cant use the symbolic parameters inside SYSTSIN. Instead of bifurcating the SYSTSIN card into two and generalizing the DB2 subsytem i prefer to maintain separate test datacards with symbolic parameter for that member name and switch it whenever needed.

But the automating the DB2 subsystem may not result desired values all the times. Anyhow thats good effort made.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top