Vyšlo v týdeníku CHIPweek č. 4/96, 23. ledna 1996
Vytištěno z adresy: http://www.earchiv.cz/a96/a604k150.php3

Dávkové zpracování

V minulém dílu jsme si řekli, že před nástupem počítačových sítí lidé používali své počítače neinteraktivně, prostřednictvím dávkového zpracování. Jaká ale je věcná podstata této techniky? Existuje v nějaké podobě ještě dnes, v době plné počítačových sítí? A mohlo by mít dávkové zpracování šanci přežít i do budoucna?

Pro správné pochopení podstaty dávkového zpracování je vhodné si znovu připomenout, čím bylo motivováno: nedokonalostí prvních počítačů. Dokonce nejen tím, že jejich cena byla tak vysoká, že o nějakém výlučném využitím jedním uživatelem se nedalo vůbec uvažovat, a jeden počítač tudíž muselo sdílet více uživatelů. Problém byl i v tom, že neexistovaly dostatečné softwarové a hardwarové prostředky pro podporu souběžného běhu více úloh (které by mohly patřit různým uživatelům), a stejně tak ještě nebyly na dostatečném stupni vývoje ani takové prostředky, které by umožňovaly jednotlivým uživatelům být v průběžném kontaktu se svými úlohami (tedy pozdější terminály, ale hlavně vše, co s jejich využitím souvisí - především pak systémová podpora ze strany operačního systému).

Obrázek 1.
Představa dávkového zpracování
Jedinou možností v takovýchto z dnešního pohledu pionýrských dobách pak bylo to, aby uživatel napsal svůj program v nějaké vhodně „trvanlivé" formě (například jej vyděroval do děrných štítků či na děrnou pásku), přidal ke svému programu všechna vstupní data, výsledek zabalil do „úhledného balíčku" (kterému se ne neprávem říkalo dávka), a teprve ten pak zadal počítači ke zpracování. Do svého „balíčku" přitom nesměl zapomenout přibalit také pokyny pro operační systém, aby tento věděl, co má s dávkou udělat - že má spustit v ní obsažený program, že mu má předat v dávce obsažená data, co má udělat s výsledkem, a další nezbytné pokyny. Vše se časem vyvinulo do takového stupně dokonalosti, že v jednom „balíčku" (dávce) mohlo být až několik programů (kterým se ale spíše říkalo úloha). Také prostředky popisu jednotlivých částí dávky se časem tak obohatily, že vytvořily celé jazyky pro popis úloh (jazyky JCL, Job Control Language).

Uživatel však stále neměl bezprostřední kontakt se svou úlohou - jakmile ji sestavil do tvaru dávky a zadal ke zpracování, jeho dávka se uložila někam do fronty dávek čekajících na zpracování a zde čekala než na ni došla řada. Okamžik spuštění uživatelovy dávky tak závisel na mnoha okolnostech, kromě priority samotné dávky i na souběhu dalších čekajících dávek ve vstupní frontě, na požadavcích na různé systémové zdroje (paměť, periferie) atd. Uživatel většinou ani nevěděl, kdy se jeho dávka konečně dostala na řadu. Ani to ostatně nebylo nutné, protože uživatelovy úlohy s ním přímo nekomunikovaly, a vše potřebné pro svůj běh (data i další pokyny ke zpracování) musely čerpat z příslušné dávky, či již najít někde připravené na daném počítači. I výsledek zpracování dávky pak opět musel mít takovou formu, aby jej bylo možné „zabalit" a někdy později předat uživateli - například ve formě vytisknuté výstupní sestavy, sady děrných štítků, svitku děrné pásky apod.

Uživatele systémů dávkového zpracování samozřejmě velmi zajímala tzv. doba obrátky, neboli doba od zadání celé dávky po získání výstupů. Především tato doba určovala rychlost, s jakou uživatelé mohli odladit případné chyby ve svých úlohách či datech, a dobrat se požadovaných výsledků. Pokud se doba obrátky pohybovala jen v hodinách, bylo to ještě velmi příznivé - častěji se totiž jednalo spíše o celé dny.

Přežilo dávkové zpracování?

Dávkové zpracování bylo za dobu své existence velmi propracováno, snad až k úplné dokonalosti. Jakmile ale došlo k nástupu interaktivních režimů práce a interaktivních systémů, které již dokázaly zajistit uživateli bezprostřední kontakt s jeho úlohou, dávkové zpracování rychle ztratilo na aktuálnosti.

Dávkové zpracování však nezaniklo úplně, a to ani po nástupu počítačových sítí. Alespoň v těch prvních, které bychom nejspíše řadili do kategorie rozlehlých sítí, bylo na možnost dávkového zpracování v síťovém prostředí pamatováno. Existovaly zde prostředky na to, jak na jednom uzlovém počítači sítě připravit celou dávku a pak ji odeslat ke zpracování na jiný uzlový počítač sítě. Dodnes se tomu říká Remote Job Entry (zkratkou RJE, doslova: vzdálené zadávání úloh), a lze se s tím setkat například v sítích SNA (Systems Network Architecture firmy IBM).

Možnosti RJE vychází vstříc tomu, aby uživatel jednoho počítače v síti mohl využít výpočetní kapacitu a další systémové zdroje jiného uzlového počítače v síti. To je samozřejmě velmi žádoucí, a je to aktuální dodnes - například v souvislosti s existencí superpočítačů, jejichž schopnosti mohou být využívány i „na dálku". Velmi ovšem záleží také na tom, zda „vzdálené dávkové zpracování" podporují i úlohy, které mají být takto zpracovány. Tedy zda mají spíše interaktivní charakter a předpokládají přímou komunikaci se svým uživatelem (a tudíž nejdou „zabalit" do dávky a odeslat), nebo zda mají neinteraktivní charakter a je možné je zpracovat ve formě dávky. V prvním případě, který je zřejmě častější, se pak místo technik typu RJE využívají spíše možnosti vzdáleného přihlašování (remote login) ke vzdálenému stroji, při kterém se uživatel na svém místním počítači dostává do postavení terminálu onoho vzdáleného stroje, a svou úlohu pak spouští a komunikuje s ní přesně stejně, jako kdyby pracoval přímo u některého z místních terminálů vzdáleného počítače.

Přežije dávkové zpracování?

Zajímavou otázkou jistě je, zda dávkové zpracování má šanci přežít i do budoucna, když například použití technik RJE je dnes spíše výjimkou, a také poptávka po nich je spíše minimální.

No, jistou šanci dávkové zpracování přeci jen má. I v dnešním prostředí počítačových sítí se značně pokročilými možnostmi totiž může být výhodné, když existuje nějaká možnost rovnoměrněji rozkládat zátěž mezi jednotlivé uzly - tak aby nedocházelo k tomu, že některé jsou beznadějně přetíženy, zatímco jiné nemají co na práci. A právě zde by jistá moderní obdoba „vzdáleného dávkového zpracování" velmi pomohla - kdyby přetížený uzel mohl vzít některou ze svých úloh, „zabalit ji" spolu se vším potřebným pro její zpracování do úhledného balíčku, a ten poslat méně vytíženému uzlu.

Takováto novodobá verze vzdáleného dávkového zpracování by ovšem zřejmě ztratila jeden svůj význačný charakteristický rys - totiž skutečnost, že dávku připravuje sám uživatel, který také explicitně rozhoduje o místě, kam bude odeslána a zpracována. Pokud totiž bude cílem dosáhnout optimálního a hlavně průběžněho rozložení zátěže celé sítě, musí se o to starat vhodný monitorovací a řídící program. Právě on tedy bude určovat, kde se jaká dávka skutečně zpracuje, a nejspíše se sám postará i o její správně „zabalení" do takové formy, jaká je vhodná pro zpracování na vybraném uzlu. Uživatel tak vlastně bude zadávat své úlohy ke zpracování síti jako takové, a nikoli konkrétnímu uzlu.

Mějme ale na paměti, že pokud dávkové zpracování v nějaké podobě skutečně přežije, bude to jen pro dosti specifický okruh úloh, které již ze své samotné podstaty mají neinteraktivní charakter - jako třeba rozsáhlé numerické výpočty. Drtivá většina dnes provozovaných uživatelských aplikací má naopak spíše interaktivní charakter, a pro ně tedy dávkové zpracování nemá smysl.