Jeg har tidligere i uge 33/2000 skrevet om, hvordan man enkelt kan sætte en ISPF message fra en REXX. Nogle af de messages, som jeg i tidens løb har lavet, er resultatet af en returkode forskellig fra 0 fra en ISPF service. Nogle gange har jeg endog brugt tid på at lave den samme tekst som i de messages, som eksempelvis EDIT sætter op.
Nu er det heldigvis slut med at bruge tid på at finde sigende fejltekster til ISPF services. Det er nemlig således, at ISPF udfylder en variabel kaldet ZERRMSG med navnet på den message, som ISPF selv har sat op. Forestil dig, at du har lavet en REXX, som går i EDIT på det datasetnavn, som brugeren angiver efter selve kommandoen, eksempelvis TSO %MYEDIT a.b..c hvor a.b..c er datasetnavnet. Normalt ville jeg have brugt en masse krudt på at validere om a.b..c er et validt datasetnavn eller ej, og om det eksisterer eller ej, men nu ser min REXX således ud:
Denne REXX giver præcist de samme messages fra sig som ISPF editoren gør, når du stikker den et ulovligt datasetnavn eller et ikke-eksisterende datasetnavn. Den vil også fortælle dig, om den har gemt dine ændringer eller, om du ingen ændringer lavede. Hvis du vil benytte ZERRMSG i et COBOL eller PL/1 program skal du huske at lave en VDEFINE af ZERRMSG.
Endnu bedre er det, at den samme fremgangsmåde kan benyttes for samtlige ISPF services. Bemærk, at ISPF servicen CONTROL ERRORS RETURN giver dit program kontrollen tilbage uanset returkoden fra ISPF servicen. Det er ikke klart beskrevet i ISPF manualerne, hvornår ISPF nulstiller virkningen af en CONTROL ERRORS RETURN, så derfor udfører jeg normalt en CONTROL ERRORS CANCEL, der sætter ISPF tilbage til normal virkemåde. Normal virkemåde er, at hvis en ISPF service giver mere end 8 i returkode, så termineres programmet, der udsteder ISPF servicen, efter at ISPF har vist et panel, hvor ISPF efter bedste evne prøver at forklare, hvad der gik galt.
Brugen af CONTROL ERRORS RETURN redder dig dog ikke, hvis selve kaldet er angivet forkert, eksempelvis hvis jeg havde skrevet EDIT DATASUT... Så vil ISPF alligevel fremvise sit fejlpanel og prøve at terminere dit program. Det er blandt andet derfor, at jeg sikrer mig, at ZERRMSG ikke er blank, før jeg kalder SETMSG. Jeg har nemlig konstateret, at nogle ISPF services gør underlige ting, som kan få en efterfølgende SETMSG med en blank ZERRMSG til at fejle.