Rigtig mange installationer bruger OPC til at afvikle deres produktionsjobs. Når OPC bliver sat til at afvikle dit job, så får du adgang til en hel masse ekstra funktionalitet i dit JCL, som du ikke har med JCL, du selv submitter. Fordelen er, at du kan meget mere med dit JCL, mens ulempen er, at du er nødt til at bruge OPC til at submitte dit job for at afprøve, om dit JCL til OPC virker. Det er desværre en udfordring rigtig mange steder, hvor udviklerne ikke har adgang til OPC. Dette skal nu ikke forhindre dig i at benytte OPC-variable, da de kan sætte dit job i stand til lidt af hvert.
En af de ting, der er rigtig irriterende ved JCL, du selv submitter, er, at JCL-variable ikke kan benyttes i inline SYSIN-data. Det har OPC heldigvis rådet bod på ved at introducere OPC-variable. OPC-variable kendes på, at de typisk prefikses med et %-tegn for at adskille dem fra JCL-variable, der prefikses med et &-tegn. Allerede her starter udfordring nummer et. Når OPC submitter et job opfatter den også &-tegn som prefiks for OPC-variable.
Default er dog, at variable først erstattes med deres værdier (substitueres) efter den først JCL-kommentar med udseendet
Hvis du vil undgå, at JCL-variable substitueres af OPC efter ovenstående JCL-kommentar, så skal du anvende følgende JCL-kommentar:
Og du slår substitutionen til igen ved at benytte en:
Hvis du bruger en NOSCAN, så skal du huske at have en SCAN senere i JCL'et. Ellers bliver OPC sur og vil ikke submitte dit job.
Og endelig er du klar til at kunne benytte OPC-variable. Det super-fede ved OPC-variable er, at de kan benyttes overalt i dit JCL, også i inline data. Der findes to kategorier af OPC-variable, bruger-definerede og predefinerede. Bruger-definerede OPC-variable defineres typisk af de personer, der har ansvaret for OPC, og varierer derfor fra installation til installation. Predefinerede OPC-variable er altid til rådighed og defineres af OPC. Lad mig lige vise et eksempel:
Hvis du inkluderer ovenstående kommentar i dit JCL (under hensyntagen til SCAN/NOSCAN), så vil du i job-outputtet efter afviklingen af jobbet se kommentaren omdannet til:
hvor MYOPCJOB er erstattet med det rigtige jobnavn og MYOPCAPPLICATION er erstattet med navnet på den rigtige OPC-applikation.
Her til sidst er det vist på sin plads at nævne, at OPC er en af de produkter, der i den grad har været gennem IBM's markedsføringsvridemaskine. Det startede med at hedde OPC (og de fleste af os gamle mainframe tosser bruger dette navn). Så kom det til at hedde TME 10 OPC, og nu hedder det Workload Scheduler med forskellige fornavne, hvor IBM og Tivoli indgår i alle mulige forskellige variationer. Netop dette navneskifteri gør der svært at finde en fornuftig OPC-manual på nettet, men det er lykkedes mig at opspore en, som du får fat i ved at klikke her. Denne manual er til gengælde meget omfattende og rimelig nem at finde rundt i.