Jeg er flere gange blevet spurgt om, hvordan man eksekverer SQL kald og ISPF kald fra samme program i batch. De af jer, der har prøvet, ved, at det ikke er helt enkelt. Der er forskellige måder at løse udfordringen på. Nogen bruger REXX kombineret med et af de mange forskellige DB2 interfaces til REXX. REXX er desværre ret performance tungt, både fordi det er et fortolket sprog og fordi SQL kaldene er dynamiske. Andre bruger et kompilerende sprog som COBOL eller PL/I og kombinerer det med CAF interfacet, som jeg før har gjort reklame for. Hvis man gerne vil fortsætte med at benytte DSN til sit COBOL eller PL/I batch program med både ISPF og SQL i, så kan man benytte nedenstående job-step:
I ovenstående stump JCL har jeg kun angivet de absolut nødvendige DD-navne, som ISPF og TSO kræver. Dog kan ISPLLIB udskiftes med STEPLIB. Inputtet til TSO på SYSTSIN vil connecte til DB2 subsystemet MYDB. RUN kommandoen vil sørge for, at når det første SQL kald udstedes, vil det blive udført ved hjælp af DB2 planen MYPLAN. Derudover gør RUN CP kommandoen intet andet end at vente på, at der kommer en TSO kommando i input. I eksemplet er TSO kommandoen en ISPSTART af program MYPGM, som helst skal findes i datasettet MY.LOAD.DATASET, hvis det da ikke findes på link-listen.
Programmet MYPGM kan udstede ISPF-kald og SQL-kald uden problemer under forudsætning af, at DB2 planen MYPLAN indeholder de DB2-packages, der beskriver SQL-kaldene og under forudsætning af, at ISPF-kaldene kun anvender ISPF komponenter, der findes i de angivne ISPF-dataset. Navnet på ISPF-datasettene kan variere meget fra installation til installation, så det er ikke sikkert, at navnene i eksemplet virker på din installation. Med ISPF leveres et sæt dataset, der indeholder de nødvendige ISPF-komponenter for at ISPSTART overhovedet vil virke. Herudover har din installation en række ekstra ISPF-komponenter, som man normalt gemmer i nogle andre dataset og konkatenerer dem på ISPF DD-navnene. Disse ekstra dataset behøver du normalt ikke i batch, med mindre du skal bruge ISPF-komponenter fra dem.
Eneste problem ved ovenstående step er, at det stort set altid vil give returkode 0 uanset hvor galt det går med eksekveringen af MYPGM. ISPF ignorerer nemlig alle forsøg på at sætte returkoden i MYPGM og giver i stedet returkode 0. Det problem løser du ved at lave en VPUT af ISPF-variablen ZISPFRC, som du sætter til den ønskede returkode. Mere herom senere.