I Uge 20 skrev jeg om, hvordan man kalder TSO-kommandoer fra PL/1 eller COBOL. Så skrev jeg også, at hvis man kører sine DB2-programmer vha. DSN, så vil TSO-kommandoer udstedt fra disse DB2-programmer også virke. Men hvad hvis nu, man vil udstede sine TSO-kommandoer fra et program, som ikke bruger DB2. Så er der en lang række muligheder, som jeg nu vil gennemgå.
Den lette løsning er at fortsætte med at benytte DSN. Det er nemlig ikke noget krav for at benytte RUN-kommandoen under DSN, at programmet skal udstede SQL-kald. Men det er måske lidt overflødigt og til dels misvisende at lade sit program blive forbundet til DB2, når det nu ikke laver nogen SQL-kald. Og så kræver DSN, at der kører en DB2 på den MVS, man vil afvikle programmet på, og hvis der kører flere DB2'er, så skal man også fortælle hvilken DB2, man vil forbinde sig til. Alt sammen ganske overflødigt.
Vi skal altså skrue et jobstep sammen, der kører TSO uden at køre DB2. Sådan et jobstep kan se således ud:
Det er selvfølgeligt lidt mere kompliceret end EXEC PGM=MYTSOPGM og et steplib, men det virker. Til jobbet skal du huske at tilføje de øvrige DD-kort som programmet eventuelt benytter sig af. Ulempen ved ovenstående job er, at man ikke bruger steplib til at eksekvere programmet via. Faktisk irriterer det mig grænseløst, at TSO ikke har en standard TSO-kommando til at eksekvere programmer på samme måde, som en EXEC PGM= gør. Jeg arbejdede en overgang hos IBM internt, og der havde man lavet en kommando kaldet INVOKE, som netop virkede ligesom EXEC PGM=, men den skal kunderne desværre ikke have glæde af.
Hvis man ikke lige har behov for at overføre parametre til sit program, så kan man benytte følgende stykke JCL i stedet:
Dette step vil virke præcist lige så godt som det første eksempel. Fordelen er, at programmet eksekveres fra steplib i stedet for fra et forudbestemt dataset. Læg mærke til, at både SYSTSIN og SYSTSPRT kan angives som DUMMY, men de kan ikke udelades helt, desværre.