- 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