Several times I have been asked about how to execute SQL statements and ISPF services from the same program running in batch. Those of you who has made it work knows that it is not easy. There are different ways to solve the problem. Some uses REXX combined with one of the many DB2 interfaces for REXX. Unfortunately REXX uses lots of CPU ressources because of the interpreted execution and the dynamic execution of SQL statements. Others use COBOL or PL/I combined with the CAF interface I have written some tips about. If you want to continue using DSN in combination with your COBOL or PL/I batch program you may use the following job step:

//TSOBATCH EXEC PGM=IKJEFT01
//ISPPROF  DD UNIT=VIO,SPACE=(TRK,(1,1,1)),RECFM=FB,LRECL=80
//ISPMLIB  DD DISP=SHR,DSN=SYS1.SPFIPO.ISPMLIB
//ISPPLIB  DD DISP=SHR,DSN=SYS1.SPFIPO.ISPPLIB
//ISPSLIB  DD DISP=SHR,DSN=SYS1.SPFIPO.ISPSLIB
//ISPTLIB  DD DISP=SHR,DSN=SYS1.SPFIPO.ISPTLIB
//ISPLLIB  DD DISP=SHR,DSN=MY.LOAD.DATASET
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
    DSN SYSTEM(MYDB)
    RUN CP PLAN(MYPLAN)
    ISPSTART PGM(MYPGM)
    END
/*

In the above piece of JCL I have only used the DD names necessary for ISPF and TSO to execute. You may use STEPLIB instead of ISPLLIB. The input specified in SYSTSIN connects the job step execution to DB2 subsystem MYDB. The RUN command specifies that when the first SQL statement is executed, it will be executed through the DB2 plan MYPLAN. Besides that the RUN CP PLAN command does nothing else than wait for a TSO command to show up in the input data stream for SYSTSIN. In this example the TSO command ISPSTART shows up and executes the program MYPGM which must be located in MY.LOAD.DATASET unless it is located on the link list.

The progam MYPGM may execute ISPF services and SQL statements without any further challenges given that the DB2 plan MYPLAN references the DB2 packages that describes the executed SQL statements and that the ISPF services only uses ISPF components located in the specified ISPF datasets. The names of the ISPF datasets may vary a lot from installation to installation, so probably the dataset names used here does not exist on your installation.

ISPF is delivered with a set of datasets containing the ISPF components necessary to make ISPSTART work. Additionally most installations concatenates extra datasets with components for different ISPF products and home made stuff. Normally you do not need those extra datasets in batch unless you need to reference ISPF components in those datasets.

The only problem with the above step is that it most likely always will terminate with a return code of zero, no matter how wrong the execution of MYPGM went. ISPF will ignore all normal attempts to set the return code in MYPGM and instead terminate with return code zero. You solve this problem by making a VPUT of ISPF variable ZISPFRC which you assign the desired return-code. More about this later.