mainframe jcl
DESCRIPTION
Kilka słów o Job Control Language JCL sterowaniu pracami i kolejkowaniu prac wsadowych.TRANSCRIPT
- 1 -
Job Control Language
Język sterowania zadaniami
w systemach Mainframe
Opis podstawowych mechanizmów JCL.
Zasad działania i kolejkowania prac wsadowych
- 2 -
17 listopada 2007
Job Control Language - język sterowania zadaniami. Można powiedzieć, że jeżeli chodzi o linuxy i unixy to
powłoka graficzna. W pierwszych unixach spotkaliśmy się z shellem. Systemy te w tamtych systemach są do końca
interaktywne. W przypadku z/OS-a sytuacja rozwijała się w drugą stronę. Były to systemy wsadowe. Zawierał czytnik
kart perforowanych, puncher, drukarkę ni o jakieś dyski i system operacyjny. I tak naprawdę ta komunikacja z
systemem której używaliście na początku a więc komunikacja z systemem której używaliście na początku TSO/ISPF
wykształciła się dużo później. W związku z tym jest to chyba w tej chwili jeden z ostatnich systemów który ma to do
siebie że całość prac trzeba opisywać, zaalokowane zasoby, wykonywane kolejno programy, całość (taką specyfikację)
trzeba przygotować. Dopiero po przygotowaniu i wskazaniu systemowi, że ma taką pracę wykonać system to
wykonuje. Jest to swego rodzaju niedogodność dla wielu którzy się przyzwyczaili do interaktywności ale zauważmy, że
bardzo szybko w unixie pojawił się demon clone który przyjmuje zadania do wykonania o określonej porze też z
udziałem użytkownika. W związku z tym okazuje się, że tego typu prace nawet w dniu dzisiejszym są potrzebne. Czyli
przygotowujemy zadanie, opisujemy jego zasoby, opisujemy programy które mają się wykonywać jeden po drugim,
opisujemy zależności między tymi programami o czym dzisiaj sobie powiemy. A więc jeżeli program pierwszy się nie
wykona to wykonaj program drugi, jeżeli się wykona to wykonaj program trzeci i idziemy sobie do domu.
Wykonywanie tego programu trwa czasami kilka godzin a czasami kilka dni. Wcale nie jest to przesada, bo czasami
reorganizacja dużej bazy danych, przy czym duża nie oznacza wcale, że ma dużo danych w sensie wpisowym ona może
mieć dużo zależności między danymi, czyli jakieś wywołania, zależności między itd. To może potrwać kilka dni i to
nikogo nie dziwi w systemie z/OS. Jako ciekawostkę mogę powiedzieć, że takim drugim systemem który co prawda nie
jest typowo wsadowy i zadaniowy ale także jest inny od pozostałych jest system na ASA400 w tej chwili się nazywa
iSeries to jest system z kolei nastawiony głównie na bazy danych bo system w ogóle przychodzi z bazą danych już
wbudowaną.
Z punktu widzenia systemu z/OS zawsze musimy brać pod uwagę specyfikę urządzeń jakie istnieją w tym
systemie. Czy to będą urządzenia rzeczywiste, czy wirtualne, czy logiczne (wirtualne w przypadku z/VM-a a w
przypadku z/OS-a mówimy o urządzeniach logicznych) dlaczego... Dlatego, że z punktu widzenia VM-a ta maszyna
rzeczywiście widzi readera albo punchera, to, że pod spodem siedzi system operacyjny który go obsługuje to nie ma
znaczenia. Natomiast w przypadku z/OS-a wielokrotnie mówimy o urządzeniach logicznych. Co to znaczy...? Kiedyś to
był prawdziwy reader, w dniu dzisiejszym system korzysta ze zbioru danych, czyli nie traktuje tego jako readera tylko
traktuje to jako zbiór danych ale cała specyfika przetwarzania a więc 80 znakowe rekordy, przetwarzanie rekord po
rekordzie i tak implikują, że jest to urządzenie podobne do readera tak, że jest to reader logiczny. Zawsze będą to jak w
jakimś modelu terminale, taśmy i dyski. I to tutaj ma o tyle znaczenie, że o ile w przypadku Windows czy Unixa o
dyskach mówimy tylko na etapie montowania filesystemu o tyle tutaj o dyskach mówi się stale. Każdy zbiór znajduje
się na jakimś dysku lub na jakiejś tasmie. Nie można zapomnieć o dysku, nie można zapomnieć o taśmie. To jest
niejako nieodłączna część adresowania zbioru danych na których operujemy. Jeżeli mówimy o zbiorze danych to
mówimy o jego nazwie, ale mówimy też o dysku na którym się znajduje i typ dysku na którym jest rozmieszczony.
Dlaczego typ dysku jest ważny... Dlatego, że na dzień dzisiejszy operujemy jednym rozmiarem ścieżki choć operuje się
czasami dwoma rozmiarami ścieżki w 3390 i 3380 i te dwa rozmiary ścieżki są różne. W związku z tym w momencie
przydziału przestrzeni dla zbioru musimy brać pod uwagę, że na jednym typie dysku to się zmieści na przykład 10
rekordów po 4 kb a na drugim dysku zmieści się 12 tych rekordów. Czyli nie możemy powiedzieć na przykład, że
alokujemy 2 ścieżki. W jednym przypadku będziemy mieli 80% tego drugiego przypadku. Tak, że pamiętać trzeba
zawsze, że poza nazwą zbioru jego cechami jest jeszcze gdzie on się znajduje, na jakim typie dysku czy jakichś taśm.
Tak samo zresztą jest z taśmami bo taśmy też mają różne gęstości, różne charakterystyki.
Dlaczego nie zdąża to w innym kierunku? To znaczy dlaczego nie ma tu modelu Unixowego czy
windowsowego? Otóż proszę zapamiętać. Tutaj istnienie ilości dysków typu 1000 lub 2000 dysków w jednym systemie
nie jest niczym szczególnym. W związku z tym gdybyśmy próbowali nad tym zapanować na poziomie filesystemu,
montowania, przemontowywania i zarządzania tą przestrzenia na podstawie filesystemu w praktyce okazało by się to
bardzo trudne dla każdego administratora. W związku z tym jest pojęcie filesystemu ale nikt nie mówi tylko i wyłącznie
o filesystemie jako ciągłej przestrzeni dyskowej ale mówi wręcz o dyskach o zbiorach na dysku.
Tak jak powiedziałem z/OS jest na tyle nietypowy, że wyróżniamy w nim trzy główne komponenty.
1. prace wsadowe "batch"
2. praca interaktywna czyli przy terminalu, przy czym ten terminal to było jeszcze niedawno 3270. Na
dzień dzisiejszy można powiedzieć, że jest to terminal w postaci przeglądarki internetowej
3. prace tak zwane stamp to stamp - czyli w świecie unixowym to są deamony w świecie windwsowym
to są serwisy i nie wykonujące jednej konkretnej roboty.
Z drugiej strony z punktu widzenia systemu mamy do czynienia z trzema poziomami logicznymi:
1. najwyższy poziom to jest aplikacja np. program przetwarzania subkonta
2. na niższym poziomie jest usługa, serwis. Usługa rozumiana w sensie takim, ze to jest grupa
programów które same z siebie nie wykonują konkretnej pracy ale świadczą na przykład usługę
połączenia TCP/IP, VTAM, usługa obsługi bazy danych - baza danych nie obsługuje siebie sama dla
siebie tylko robi to dla innych.
- 3 -
3. na samym dnie tego wszystkiego ale najważniejszy jest system a więc usługi niskopoziomowe.
Obsługa zbiorów, obsługa blokowania, semafory, czy obsługa procesora i pamięci.
Zawsze w z/OS-ie jest przetwarzanie jakichś danych. Czy to będzie przetwarzanie transakcyjne, czy to będzie
przetwarzania "bathowe". I teraz ponieważ mamy przetwarzanie danych to musimy mówić standardowo o wyjściu,
wejściu, obszarach tymczasowych. Takiemu modelowi podporządkowana także jest konstrukcja języka który opisuje
dane zadanie. czyli Job Control Language. Cała praca obsługiwana czy zdefiniowana jest komendą JOB. Komenda
JOB czy raczej instrukcja JOB definiuje pracę jako całość. Jako niepodzielną całość. Dwie pozostałe komendy
rozdzielają pracę jakby na część statyczną i dynamiczną. Dynamiczna jest w stanie exec która definiuje sam program
wykonywany. Część statyczna DD (Data Definition) reprezentuje dane na których operuje program. Oczywiście w
przypadku zdania DD mówimy tak naprawdę o dwóch elementach. Elemencie wejściowym i elemencie wyjściowym.
Razem mają to do siebie, że zakładają pełna strumieniowość. Strumieniowość - czyli bierzemy dane z jakiegoś wejścia,
przetwarzamy i wysyłamy na jakieś wyjście. Klasyczne podejście znane państwu chociażby unixa, tutaj jednak
reprezentowane przez troszkę inny model. Mamy kilka etapów. Ponieważ na etapie wykonywania planów taka pracę
przygotowuje człowiek to człowiek może się pomylić. Wobec tego wszystkie etapy pracy począwszy od opisu zadania
przez człowieka są gdzieś dokumentowane, przechowywane w maszynie w sprzęcie, muszą być nadzorowane. Jeśli
pisze się instrukcję JSL-a pisze się do systemu. To nie oznacza, że system zacznie od razu wykonywać zadanie.
Najpierw system musi wziąć dane i przeanalizować pod względem składniowym. Czy się nie pomyliliśmy w składni.
Czy nie daliśmy spacji gdzie spacji być nie powinno, czy nie zrobili błędu w długości nazwy zbioru bo zbiór ma
określoną charakterystykę. Jeśli jest to wiele prac. Tak jak na przykład was jest 12 osób a system ma jeden procesor,
to rzeczą oczywista jest , że system nie jest w stanie wasze wszystkie prace przetworzyć w tym samym czasie. Zawsze
jest jakiś czas na analizę składniową. Żeby nie zatrzymywać operatora w działaniu JCL każdy plik źródłowy
wprowadza do spoola, czyli do obszaru dyskowego na którym przechowywane są wszelkie etapy pomocnicze, dane
wejściowe, tzw. "instream", dane pośrednie i dane wyjściowe które generuje program. Kiedy procesor będzie wolny
Analizuje wprowadzony plik JCL-a pod względem składniowym, zmienia symbole logiczne na rzeczywiste
wartości, sprawdza spacje, kropki itd. To jest pierwszy etap konwersji (pierwszy etap: input, drugi etap: konwersja).
Jeżeli to konwertowanie się powiedzie system znowu zachowuje sprawdzony i przekonwertowany wynik pracy (job) w
spoolu i informuje jądro systemu, że taka a taka praca jest gotowa do wykonania. To nie jest tak, że system od razu
wykonuje wszystkie prace. To jest zupełnie inaczej niż w unixach gdzie wpisujemy nazwę programu i praca zaczyna się
wykonywać. Tutaj nie. Tutaj praca zaczyna się wykonywać kiedy zasoby dostępne dla tej pracy są wolne. W
szczególności tzw. inicjator, który bierze pracę, ze spoola i zaczyna wykonywać program. W momencie kiedy zaczyna
wykonywać program praca może być zakończona albo w sposób naturalny, czyli kiedy zakończy wykonywać
wszystkie swoje elementy, albo w sposób nienaturalny kiedy napotkała jakiś błąd krytyczny i wtedy następuje tzw.
"abend" (abnormally end) czyli nietypowe przerwanie programu. Tak czy inaczej w trakcie wykonywania program
potrzebuje pewnych danych wejściowych. Program może wziąć je z ................. albo ze spoola. W trakcie analizy i
pobierania tych danych program generuje różnego rodzaju logi (też zapisuje je do spoola). Oczywiście może zapisywać
też zbiory dyskowe, ale zawsze będzie generowała jakieś logi do spoola. Kiedy program się kończy zarówno te logi jak
i wszystkie inne pozostają w spoolu. Nie są niszczone dlatego, że zakłada się, że praca wsadowa jest niezależna od
zalogowanego użytkownika. W związku z tym użytkownik musi mieć szansę przyjść i obejrzeć po jakimś czasie jak ta
praca została wykonana. Czy były jakieś komunikaty o błędach, czy były jakieś błędy krytyczne. Czy wszystko
powiodło się zgodnie z planem, ile czasu to chodziło, jakie zabrało zasoby itd. I dopiero w momencie decyzji jeśli
program wygenerował jakąś liczbę użytkowników, użytkownik ten który wygenerował tą pracę może na przykład
zażądać wydrukowania jej na drukarkę albo wysłania do innego systemu. Dopiero kiedy użytkownik stwierdzi, że
wszystkie operacje związane z wyjściowymi plikami zostały wykonane wykonujemy operację punch, czyli wyrzucenie
pracy ze spoola i dopiero w tym momencie pracę wyrzucamy. Taki jest etap przetwarzania. Nad całością tego etapu
zarządza tym wszystkim, nadzoruje to wszystko program który się nazywa JES (Job Entry Subsystem). W Polsce
używamy FAT w wersji 2 Jest jeszcze wersja 3. Właściwie nie powinno się mówić wersje. Po prostu są to dwa osobne
programy. Tylko nazwy są podobne. Ponieważ JES sam z siebie jest też programem analizującym wobec tego JES
rozumie komendy JCL-owe. Tak naprawdę to JES część komend JCL-owych wysyła niżej do systemu operacyjnego, do
jądra. Bo JES jest właśnie taka usługą. Natomiast niektóre komendy są JES-a, więc JES te komendy połyka i zamiast
................ wykonuje odpowiednie operacje. Czyli jest takim rodzajem filtru. I teraz komendy które JES wykonuje są
zaznaczone tutaj gwiazdkami. I przechodzimy do poszczególnych elementów JCL-a.
1. Element pierwszy tak jak powiedziałem to jest JOB STATE. Instrukcja Job. Instrukcja Job zamyka pewien
etap pracy. To znaczy możemy w źródle JCL-a mieć 3 instrukcje Job. 3 dwie lub 5. Natomiast w sposób
naturalny każda nowa instrukcja JOB otwiera nową pracę do wykonania. Czyli każda nowa praca będzie miała
swój identyfikator itd. Job jako instrukcja jest pewnym rodzajem nawiasu otwierającego. Następny Job jest
pewnym rodzajem nawiasu zamykającego i otwierającego następną pracę. Ponieważ Job definiuje pewna pracę
w systemie i definiuje także zasoby związane z całą tą pracą. Najpierw informacyjne. Kto i na jakim koncie
wykonywał będzie daną pracę. Ja już o kontach parę razy mówiłem. Przypominam, chodzi o rozliczanie
poszczególnych użytkowników z prac. Czyli ja jako użytkownik mogę być obecny w systemie jako Piotr K.
Ale wykonuję dwie prace. Jedną wykonuje na okoliczność uczelni a drugą wykonuję na okoliczność firmy
zewnętrznej. Ponieważ to nie ja jestem obciążany za koszt pracy maszyny tylko moi pracodawcy, w przypadku
pierwszej pracy obciążana jest uczelnia, a w przypadku drugiej pracy obciążana zostaje firma zewnętrzna.
- 4 -
Żeby te dwie sytuacje rozróżnić wprowadzone jest pojęcie accounting information, to jest ciąg znaków jakiś
tam. Dalej w przypadku kiedy wrzucam pracę wsadową to oczywiście ja mam swój identyfikator, ale te
identyfikatory są z reguły siedmio znakowe minimum i tak jak w państwa przypadku to są identyfikatory
związane z indexami. Mnie nic nie mówią. Ja oczywiście mogę bazując na informacjach otrzymanych z
dziekanatu wyszukać kto to jest, czy wpisać do racaf-a imię i nazwisko i sprawdzić to. Nie zrobiłem tego.
Natomiast dobrą praktyka jest wprowadzanie swoich inicjałów. Na przykład imienia i nazwiska dla operatora.
Bo to pokazuje informatorowi kto puścił danego Job-a. Operator nie wie, że s14348 to jest pan s lub pani y,
natomiast to się ukazuje jako dodatkowa informacja. Każda praca trafia do pewnej klasy i te klasy maja
przyporządkowane losowo. Klasy to są od A do Z lub cyferki od 0 do 9. Teraz w zależności do jakiej klasy
trafimy możemy trafić wręcz do innego systemu. Bo czasami jest tak, że mamy dwa lub trzy systemy i jeden
system obsługuje klasy A, B, C, drugi D, E, F, a trzeci I, J, K. Teraz dobra, ktoś powie co to za różnica? Ano
taka różnica, że w przypadku na przykład systemu B obsługującego trzy klasy mamy do dyspozycji bibliotekę
taśmową a w przypadku pozostałych systemów jej nie ma. Czyli jeśli uruchomimy zadanie w nieodpowiedniej
klasie to zadanie nam stanie bo nie będzie miało dostania się do biblioteki taśmowej, bo akurat do tego
procesora biblioteka taśmowa nie jest podłączona. Biblioteka taśmowa nie podlega współdzieleniu w
przeciwieństwie do typów. No i dalej jeszcze wymagania dotyczące pamięci, i ewentualnie co ma zrobić praca
jeśli jeden z jej kroków na przykład się załamie. Czy ma iść dalej, kontynuować, czy ma przerwać, to jest tak
zwany conditional..... (nie usłyszałem drugiej części nazwy).
2. EXECUTE DATA czyli instrukcja exec. Instrukcja exec reprezentuje jeden program wywołany w czasie
pracy. Praca z założenia jest sekwencją programów wykonywanych jeden po drugim. Każdy z tych
programów nazywa się krokiem (step). I każdy nowy krok rozpoczyna się od instrukcji exec. I znowu
instrukcja exec zawiera przede wszystkim wskazanie jaki program wykonać Po drugie co zrobić jeśli coś stało
się nie tak na przykład z poprzednim krokiem, po trzecie dostarcza parametrów do tegoż programu.
3. DATA DEFINITION opisuje ogólnie rzecz biorąc zbiory danych, nie tylko na dyskach. Określa gdzie szukać
zbioru danych, gdzie szukać zasobów, czy to jest drukarka, czy to jest zbiór dyskowy, czy zbiór taśmowy i
charakterystykę tych zbiorów. Zdanie DD ma pewną bardzo szczególną cechę, mianowicie każde zdanie DD
ma swoją nazwę. tzw DD NAME. Ja juz o tym wspominałem ale powiem jeszcze raz, program pisany w
systemie z/OS nie jest jak plik z danymi który będzie wykonywany. W związku z tym w programie umieszcza
się nazwę symboliczną zbioru danych. Ta symboliczna nazwa zbioru danych jest jakby etykietą zbioru. Poza
etykietą zbioru jest jeszcze powiedziane, że zbiór ma mieć charakterystykę np. RB80 czyli rekordy 80 bajtowe
w dodatku zblokowane. Natomiast w trakcie wykonania ta etykieta jest związana z taka samą nazwą zdania
DD. Jeżeli program powie w trakcie wykonania programu, że czyta dane ze zbioru SYS.UT1 a właściwie ze
zdania DD NAME to właściwie jeżeli użytkownik na etapie przygotowania JCL-a powie że SYS.UT1 to jest
zbiór ABC na dysku XYZ to, to będzie dla programu w tym momencie SYS.UT1. Ale następny użytkownik
biorąc ten sam program powie, że SYS.UT1 w JCL-u to jest XYZ na dysku ABC czyli odwrotnie. I w tym
momencie do wykonania tego drugiego programu dane już będą inne.
Tak jak powiedziałem JOB może być wielokrokowy. Kroki rozpoczynają się od zdania exec i teraz wszystko co
jest po zdaniu exec i określa się mianem DD dotyczy tego kroku. W momencie kiedy nastąpi nowe zdania exec
rozpoczyna się nowy krok i wszystkie nazwy DD po tym execu dotyczą następnego kroku. W przypadku kiedy
następuje błąd JCL-a w trakcie analizy zadania wykonywany krok w którym nastąpił błąd JCL-a kończy pracę zadania.
Czyli następny krok juz się nie wykona. Chyba, ale o tym za chwilę, że są odpowiednie instrukcje tzw. "conditional
statement". Może się tak zdarzyć, że program skończy się nietypowo, bo zabraknie mu na przykład pamięci do
zaalokowania, wówczas następne kroki pracy są pomijane. Trzeba odróżnić to od tego. "To" jest na etapie analizy.
Analizujemy JCL-a i w momencie kiedy wykrywamy w kroku drugim JCL-error następne zdania nie podlegają
analizie. A "to" jest sytuacja kiedy program już jest wykonywany. Czyli analiza przebiegła poprawnie i w momencie
kiedy program "deva1" kończy się nietypowo "abnormalnie" abendem to pozostałe programy a więc w tym przypadku
"pgf2'" już się nie wykona.
Każdy program - przyjęło się w systemie z/OS zwraca wartość od zera do 4095.
Przyjęło się, że te wartości są w krokach. Są cztery, a więc 0;4;8;12;16.
0 - oznacza poprawne zakończenie programu
4 - zakończenie programu w którym wystąpiły jakieś anomalia - na przykład, powiedzieliśmy, że czytamy ze
zbioru ale zbiór był pusty. To dla programu może być coś nietypowego. Wówczas program się zakończy,
natomiast nie powie "return to 0" natomiast coś mu nie pasowało i powie "return to 4".
Jeżeli program nie może spełnić jakichś swoich żądań, brakuje mu coś, przeanalizował składnię języka C bo jest
kompilatorem skończyło się składnią zwróci kod 8 - job zakończył się niepoprawnie
Jeżeli program, też kompilator języka C ma wykonać pewne działanie, ale nie ma bibliotek to już nie jest błąd
słaby, to jest błąd większy bo ich nie dostarczyliśmy, kończy się z kodem 12. Czyli to oznacza, że to jet już
duży błąd z punktu wykonywania programu
Jeżeli program skończy się w trybie natychmiastowym, bo na przykład zabrakło mu pamięci to z reguły jest to
albo abend albo kod 16.Jeśli potrafi przechwycić abenda (bo jest tak czasami) i wtedy nadaje kod 16. Ale jeżeli
program milczy z powodu tego typu błędu to wtedy daje się abend.
- 5 -
Czyli im wyższa wartość kodu powrotu tym gorzej.
Tak jak powiedziałem są dwa JES-y. My będziemy się zajmować tylko JES2. Po lewej stronie macie państwo
wypisane komendy JES-a związane z działaniem JOB-a. Co to znaczy? To znaczy, że to nie są komendy związane z
przygotowaniem pracy tylko tak zwane komendy interaktywne. Na przykład COMAND pozwala nam w trakcie pracy
JOB-a podać komendę do systemu operacyjnego. To nie jest związane z samym JOB-em ale na przykład chcemy
wpisać w bloku, że teraz rozpoczyna się krok drugi. O tym jeszcze będziemy mówić.
Czyli reasumując mamy trzy podstawowe typy komend JCL-a:
JOB
EXEC
DD
Po co sobie wymieniliśmy te klasy? Jest kilku użytkowników którzy mają kilka JOB-ów.
J 11 J 21 J 11
J 12 J 22 J 21
J 13 J 23 J 12
J 14 J 24 J 22
Robią to niezależnie od siebie. Każdy siedzi przy terminalu i klepie. Wysłanie polecenia pracy do wykonania
to jest to jest komenda SUB. Wyobraźmy sobie, że tak się ułożyło, że wysyłają te prace naprzemiennie. Jeżeli wysyłają
je do tej samej klasy zadania powiedzmy, że do klasy "A" to w spool-u wygląda to tak jak powyżej. Teraz z klasa
zawsze związany jest program który się nazywa inicjatorem, który obsługuje pewne klasy. Niech obsługuję klasę "A". I
ten inicjator na razie jest jeden. Co robi program... Program w pętli przeszukuje kolejne klasy "A", bierze pierwszy
program do wykonania i go wykonuje. Jak się skończy bierze drugi program do wykonania i go wykonuje. Czyli w tym
momencie, w tej sytuacji bardzo mocno uproszczonej prace są wysyłane do systemu według kolejności zgłoszenia.
Sytuacja troszkę bardziej skomplikowana Mamy inicjator "A" ale uruchomiony dwa razy. Co się dzieje?
Każdy z tych inicjatorów (oczywiście stosując odpowiednie metody blokowania dostępu itd.) pobiera dane z systemu.
Jest tak, Pierwszy inicjator wolny wziął pracę J11 i ją wykonuje. Drugi inicjator wolny wziął pracę J21 i ją wykonuje. I
teraz uwaga... Praca J21 jest krótsza i się kończy wcześniej niż J11. Co robi inicjator? Bierze następną wolną pracę a
więc J12 i ją wykonuje. Czyli już można powiedzieć tak, Została zachowana kolejność wprowadzania prac do systemu,
czyli J12 będzie przed J22 ale to wcale nie znaczy, że ona się szybciej skończy. Czyli jest nadal szeregowanie ale już
nie ma pojedynczego wykonania.
Sytuacja następna, każda z tych prac może mieć tzw. priorytet (najoring) i wówczas te prace umieszczane są w
kolejce tak jak zostały wprowadzone, ale program inicjatora bierze pod uwagę priorytet pracy. Im wyższy priorytet
pracy tym szybciej zostanie ona wybrana. Czyli każdy inicjator "A" wyszukuje prace w kolejce A o wyższym
priorytecie. Jeżeli J22 ma wyższy priorytet to zostanie wykonane jako pierwsze. Oczywiście teraz jeżeli J13 zostało
wprowadzone do systemu ale dwie prace już się wykonują w inicjatorach to ono będzie następne do wykonania ale
inicjator nie przerwie nam tej pracy ale ją skończy.
No i sytuacja najbardziej skomplikowana. Mamy dwie klasy. Klasę A i klasę B. Teraz jeśli nie mamy
inicjatora obsługującego klasę B to te prace będą czekały dotąd aż operator inicjatora nie uruchomi lub nie zmieni
istniejącego inicjatora na obsługującego klasę B. Jak może zmienić? Może zamienić albo może dodać. I teraz może
dodać do inicjatora drugiego, ale może dodać też na początek BA. Wówczas inicjator zaczyna analizować najpierw
kolejkę B (zgodnie z tymi zależnościami) a dopiero potem kolejkę A. Biorąc pod uwagę wszystkie zbiory B itd. I
dlatego widać, że ta klasa wykonywania JOB-a jest bardzo ważna.
Jednak każdy dodany nowy inicjator to jest jeszcze jedna praca wykonywana równolegle w systemie. I nie ma
jednoznacznej odpowiedzi na to pytanie.
Jeśli wysyłają zadania do jednej klasy to
wygląda to właśnie tak
- 6 -
- Która klasa byłaby ważniejsza? Dodanie nowego inicjatora, czy dodanie nowego?
- To zależy, dlatego, że proszę pamiętać, że każdy następny inicjator dodany to jest jeszcze jedna praca wykonywana
równolegle w systemie i nie ma jednoznacznej odpowiedzi na to pytanie. Bo jeżeli ma pan większość prac które dużo
komunikują się w wejściem/wyjściem i teraz ma pan sytuację, że dostawia pan następny inicjator to w tym momencie to
jest ok działanie. Dlaczego....? Dlatego, że i tak większość prac stoi czekając na procesor tzn stoi z procesorem czekając
na IO. W związku z tym dokładając jeszcze jeden inicjator, uruchamiając jeszcze jedną pracę te okresy w których
procesor stoi on oddaje następnym pracom. A teraz sytuacja inna. Ma pan wszystkie prace które są „CPU żerne”, No i
w tym momencie jak pan wrzuci trzecią pracę do ogródka to one wszystkie będą rywalizowały między sobą o jeden
procesor. No i w tym momencie jest pytanie. Czy zależy nam na tym żeby te prace skończyły się w miarę szybko, czy
żeby jedna się skończyła w miarę szybko a potem wykonać drugą... Nie ma jednoznacznej odpowiedzi na to pytanie. To
zależy od charakterystyki przetwarzania. Czasami robi się tak, że daje się tylko jeden inicjator w jednej klasie właśnie
po to żeby joby jeden po drugim zostały wykonane w kolejności. To jest świadome. To jest duża odpowiedzialność albo
wysoko wykształconego operatora, albo systemowca. To jest dobry moment na podkreślenie, że my to tak często w
sposób taki negatywny rozumiemy pojęcie pracy operator bo jeszcze wielu osobom się kojarzy na zasadzie papier...
odpowiedź... Tak nie jest. To jest gość który siedzi przy konsoli i czasami decyduje o tym co się dzieje w systemie i
musi to rozumieć. Jeśli zarządza na przykład kasetami i dyskami, to też musi rozumieć implikacje pewnych rzeczy.
Wygląda to jeszcze bardziej skomplikowanie ale na nasze potrzeby dzisiejsze nam wystarczy :).
A teraz prosty przykład z życia:
Jeżeli mamy wykonać jakąś pracę od punktu A do punktu B na stu metrach ale jest powiedziane, że co pięć metrów
musimy stanąć i poczekać aż ktoś przyniesie kubek wody i ją wypijemy to czy ma znaczenie czy nam się ktoś plącze
między nogami czy nie? Tylko na tych etapach co 5 metrów. A jeżeli teraz jest sytuacja taka, że w ciągu tych pięciu
metrów nikt się nie plącze między nogami a pan stoi a ktoś inny przechodzi przed nami, czy to przeszkadza? Czy to
wpłynie na czas wykonanej przez nas pracy? W niewielki sposób. Natomiast jeśli będziemy musieli zasuwać od
momentu startu jak najszybciej do mety to jak ktoś nam będzie przeszkadzał i mówił „to teraz ja... to teraz ja...” to to
będzie ewidentnie nam przeszkadzało i opóźni wykonanie przez nas pracy. Ten pierwszy przykład to jest oczekiwanie
na dostarczenie danych a ten drugi przykład nie czekamy na nic. Mamy liczyć coś, robić coś jak najszybciej. Dwie
różne skrajne sytuacje bo nigdy nie jest tak, że proces zawsze czeka na dane albo zawsze ciągle liczy. Dopóki nie
zaczynają rywalizować między sobą zadania o procesor w sensie takim, że każdy chce jak najwięcej to do tej pory nie
są wstrzymywane i do tej pory nic im nie przeszkadza. Jedyne co pomoże to zwiększenie ilości procesorów, żeby każdy
dostał swój.
W tej chwili zajmujemy się składnią poszczególnych instrukcji. Część dla państwa na tyle ważna, że będziecie
państwo dzisiaj próbować wykonywać pewne zadania i mogę powiedzieć na podstawie doświadczenia z dnia
wczorajszego, zwracajcie uwagę na spacje, kolumny, przecinki i tym podobne rzeczy.
Format JCL-a. Zawsze zaczynamy od kolumny pierwszej z dwoma slashami. Zawsze w kolumnie trzeciej
zaczyna się nazwa, jeżeli jest. Natomiast jeżeli jej nie ma to kolumna trzecia musi być pusta. Musi mieć spacje bo
inaczej potraktowane zostanie to jako nazwa. Komendy JCL-a wyglądają następująco. Dwa slashe nazwa spacja
operacja spacja parametr i teraz jeżeli nie starcza nam miejsca to dajemy przecinek i od następnego wiersza znowu dwa
slashe spacja nowa rzecz. I kontynuacja wiersza musi się znaleźć w kolumnach od czwartej do szesnastej. Jeżeli
znajdzie się w siedemnastej system już nie zauważy, że jest to kontynuacja wiersza. Tu musi być przecinek. W
kolumnie 72-iej wstawiamy ?????
Przykład:
Jak są specyfikowane parametry? Są dwojakiego rodzaju. Tak samo jak w TSO. Najpierw występują parametry
pozycyjne a więc ich znaczenie wynika z ich pozycji, potem występują parametry kluczowe - ich znaczenie wynika z
nazwy klucza. K1=A, K2=B. Parametry kluczowe mogą zawierać podparametr. I znowu obowiązuje zasada jak wyżej
czyli podparametry mogą się składać z pozycyjnych i kluczowych. Jeżeli parametr ma podparametry to bierzemy je
same. Każde zadanie składa się z trzech podstawowych elementów. Pierwszy jest tzw. Job Statement i Job Statement
wygląda w podstawowej wersji tak jak tutaj. To jest tzw. Karta Jobowa. Karta Jobowa bo kiedyś to była karta
perforowana. Na początku mamy nazwę Joba, potem słowo JOB, potem parametry pozycyjne z których my będziemy
korzystać. Są dwa. Pierwszy to jest Account info może być wypełniony dowolnie, i drugi to jest informacja o
programiście który uruchamia Joba. Może być Imię Nazwisko itp. Potem po przecinku następują już parametry
kluczowe. Message level o którym powiem zaraz i klasa w jakiej ma być Job uruchomiony. Jeżeli nie ma klasy
domyślną klasą jest klasa A. Nazwa programisty to jest od jednego do dwudziestu znaków. Parametr klasy, po tym
wstępie myślę, że jest już zrozumiałe. Parametr Message. Otórz każdy Job generuje logi, różnego rodzaju. Teraz te logi
starsze znajdują się w pewnych klasach. Logi są rodzajem wydruku. Wydruki generalnie znajdują się w pewnych
klasach. Dlaczego wydruki znajdują się w pewnych klasach? Z tego samego powodu co Joby. A więc wydruk może iść
na przykład na drukarkę automatycznie i się automatycznie wydrukować. Może automatycznie zostać wysłany do
systemu zdalnego, może zostać zatrzymany do obejrzenia przez programistę systemowego, różne operacje mogą być z
nim robione. W związku z tym jeślibyśmy logi wrzucali do różnych miejsc nie mielibyśmy specyfikacji co z nimi
zrobić. W związku z tym logi czy wydruki z pól dzielimy na klasy i każdej klasie przyporządkowujemy pewną
charakterystykę. Na przykład „wydrukuj”, „zatrzymaj do obejrzenia” tzw. hold, albo wyślij do innego ośrodka, albo
wydrukuj na puncherze, jeżeli mamy puncher, różnego rodzaju operacje. Albo wydrukuj i zachowaj, wydrukuj i
wyrzuć, dlatego są klasy Teraz logi generowane przez klasę mogą być mniej lub bardziej szczegółowe i o tym mówi
message level. I kiedy uda się wam uruchomić joba to zmieńcie sobie na message level 00 na message level 01,
- 7 -
message level 11 i zobaczcie jak będą różniły się zawartością. Mamy jeszcze dwie sytuacje kiedy są parametry które
mogą się w jobie przydać. Mianowicie Mobifile= i identyfikator użytkownika TSO. s... cośtam lub identyfikator
państwa kolegów lub sysuid. Jeżeli państwo wpiszecie sxxxxx to zawsze to będzie sxxxxx