In week 20 I wrote a tip about executing TSO commands from PL/I or COBOL. I also wrote that if you execute DB2 programs using the DSN command processor you do not have to worry about the execution of TSO commands. What if your program does not execute SQL statements and therefore does not use DB2. Then you can still execute TSO commands from your PL/I or COBOL program, but you will have to consider how to execute your program.

The easy solution is to continue to run your program using DSN. DSN does not require your program to execute SQL statements in order to use the RUN command. It may seem a little unnecessary and misleading to connect your progam to DB2 when it does not execute any calls to DB2. Furthermore DSN requires a DB2 subsystem to be running on the MVS system where you want to execute your program. If more DB2 subsystems run on the MVS you have to choose one of them in order to connect. All of this is quite superfluous.

What we need is a batch job step executing TSO without executing DB2. Such a job step may look like this:

//TSOBATCH EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
    CALL 'MY.LOAD.LIBRARY(MYTSOPGM)' 'MYPARMSTRING'
/*

This is of course a bit more tricky than EXEC PGM=MYTSOPGM and a steplib, but it works. You must of course remember to add the DD cards your program might use. The disadvantage of the job step above is that it does not use steplib in order to locate the program. You can replace MY.LOAD.LIBRARY with a * and add a steplib DD card to acheive the same effect as a normal EXEC PGM=MYTSOPGM.

If you do not need to transfer parameters to your program you may use the following piece of JCL instead:

//TSOBATCH EXEC PGM=IKJEFT01,PARM='MYTSOPGM'
//STEPLIB  DD DISP=SHR,DSN=MY.LOAD.LIBRARY
//SYSTSPRT DD DUMMY
//SYSTSIN  DD DUMMY

This step will work just as well as the first example except for the parameter. You may use DD DUMMY on both SYSTSPRT and SYSTSIN, but TSO requires the presence of both of these DD names.