I takt med at nutidens mainframes får flere og flere processorer (jeg kalder dem cylindre), bliver det også mere og mere almindeligt at software produkterne på mainframen udnytter dem ved at udføre opgaverne parallelt. MVS har nu altid haft gang i rigtig mange tasks på een gang, så derfor har både software produkterne og vores egne programmer til en vis grad måttet tage hensyn til eventuelle samtidighedsproblemer. En ting er at tage højde for samtidighedsproblemer og parallellitet, noget ganske andet er at teste for det eller udnytte det som ganske almindelig programmør. Hvordan får man for eksempel to eller flere jobs til at starte samtidigt og dermed eksekvere samtidigt. Det vil jeg nu komme nærmere ind på.
Når man ikke har adgang til at benytte OPC eller et lignende værktøj, så må man selv submitte sine jobs. Det sker som regel med kommandoen SUBMIT i ISPF EDIT/VIEW. SUBMIT virker i øvrigt også i ISPF BROWSE. SUBMIT kommandoen gør det, at den sender hele data indholdet fra EDIT/VIEW/BROWSE til JES. Det er så op til JES at finde ud af, om den synes, at det afsendte kan afvikles. Hvis ikke får man en JCL fejl. Nu er JES så snedigt indrettet, at man faktisk kan afsende mange jobs til JES på een gang. JES forventer at modtage et jobkort som den første record. Herefter gennemlæser den resten af de afsendte records og kontrollerer dem een for een. Hvis JES møder en // uden nogen øvrige data opfatter JES det som afslutningen på det første job. Herefter gennemlæser JES de resterende records og kontrollerer om nogen af dem er et jobkort. Hvis en record opfylder betingelserne for et jobkort, så begynder JES igen at fortolke de efterfølgende records som et nyt job og så fremdeles.
Ud fra ovenstående beskrivelse bliver følgende indhold i et dataset eller member altså til to jobs, når indholdet submittes:
Disse to jobs kører helt sikkert ikke ret længe, men illustrerer, hvordan man får sendt to jobs afsted til JES på samme tid. For at de rent faktisk også kommer til at køre samtidigt er der lige en del andre ting, der skal være på plads. For det første skal jobnavnet på de to jobs ikke være det samme. Hvis det er det, så kommer de med JES garanti til at køre efter hinanden. Næste detalje er, at der skal være tilknyttet mindst to såkaldte initiatorer til den jobklasse, som jobbene afsendes til, eller også skal de afsendes til hver sin jobklasse. I eksemplet kræves der altså mindst to initiatorer tilknyttet jobklasse 1. Sidste detalje er, at der ikke skal være andre jobs i gang, der kan spærre for eksekveringen. Hvis der for eksempel er to initiatorer tilknyttet jobklasse 1, og der allerede kører et helt andet job i jobklasse 1, så vil de to jobs i eksemplet blive afviklet efter hinanden i stedet for samtidig med hinanden. Det er altså ikke helt uden udfordringer at få to eller flere jobs til at starte og eksekvere samtidigt, selv når man kan submitte dem samtidigt.
Det er farligt at skrive tip, der indeholder jobkort, da opsætningen af jobkort og jobklasser varierer utroligt meget fra installation til installation. Jeg har derfor med vilje udeladt accounting parameteren (den første parameter efter JOB), som nogen steder er påkrævet, men langt fra alle. Det er heller ikke sikkert, at CLASS=1 vil virke på din installation, ej heller MSGCLASS=H. Til gengæld vil NOTIFY=&SYSUID sikre, at NOTIFY bliver sendt til den user, der submitter jobbet. Det er i øvrigt ikke nødvendigt at afslutte et job med // på en tom linie. I eksemplet kan linien helt undværes, da et nyt jobkort automatisk afslutter det foregående job.
I SDSF findes der en kommando kaldet INIT, som kan vise sammenhængen mellem jobklasser og initiatorer, men mange installationer synes, at den kommando kun skal være tilgængelig for driften og systemprogrammørerne. Hvis du har adgang til TASID (prøv TSO TASID), så er der en option, der viser det samme som INIT kommandoen.