OS02V12.RTF,2KI.4.16.
2. AZ OPERÁCIÓS RENDSZEREK FUNKCIÓI
Az operációs rendszerek funkcióit (szolgáltatásait) a szakirodalom nem egységesen definiálja. Eleve megkülönböztethetünk azonban alacsony- és magas szintű funkciókat. Az alacsony szintű funkciók szolgáltatásait a programokból úgynevezett rendszerhívások segítségével vehetjük igénybe, míg a magas szintűeket vezérlőnyelvekkel és segédprogramokkal (rendszerközeli szoftverelemekkel) érhetjük el. A funkciókat osztályozhatjuk az alábbiak szerint: * primitívek: elemi,- atomi,- tovább nem bontható funkciók; * összetettek: több primitív funkcióra épülő bonyolultabb funkciók; * fő funkciók: relatíve önálló egységet képező, együttműködő funkciók összessége. Az operációs rendszeri funkciókat természetesen programok valósítják meg. Az operációs rendszerekben önkényesen az alábbi három fő funkció jelölhető ki: * rendszeradminisztráció, * programfejlesztési támogatás és * alkalmazói támogatás. A programfejlesztési támogatás és az alkalmazói támogatás a rendszeradminisztrációs funkciókra épül, ezért a vonatkozó rétegszerkezetet a 2.1. ábra mutatja. +---------------------------+---------------------------+ | Programfejlesztési │ Alkalmazói | | támogatás │ támogatás | +---------------------------+---------------------------+ | | | Rendszeradminisztráció | | | +-------------------------------------------------------+ 2.1. ábra. Az operációsrendszeri szoftver rétegződése
2.1. Rendszeradminisztráció Rendszeradminisztrációnak nevezzük magának az operációs rendszernek a működtetésével kapcsolatos funkciókat. Ezek közvetlenül semmire sem használhatók, csak a hardverlehetőségek kibővítését célozzák, illetve a hardver kezelését teszik kényelmesebbé. A rendszeradminisztráción belül a következő összetett funkciókat jelölhetjük ki: * processzorütemezés: a CPU-idő szétosztása a rendszer- és a felhasználói feladatok (taszkok, folyamatok) között; * megszakításkezelés: a hardver-szoftver megszakításkérések elemzése, állapotmentés, a kezelőprogram hívása; * szinkronizálás: az események és az erőforrásigények várakozási sorokba állítása; * folyamatvezérlés: a programok indítása és a programok közötti kapcsolatok szervezése; * tárkezelés: a főtár, -- mint kiemelten kezelt erőforrás, -- elosztása; * perifériakezelés: a bemeneti/kimeneti (B/K ill. I/O) igények sorba állítása és kielégítése; * adatkezelés: az adatállományokon végzett műveletek segítése (létrehozás, nyitás, zárás, írás, olvasás stb.); * működés-nyilvántartás: a hardver hibastatisztika vezetése és a számlaadatok feljegyzése; * operátori interfész: a kapcsolattartás az üzemeltetővel.
A konkrét operációs rendszerek a funkciókat másképpen oszthatják fel. Így például az IBM OS operációs rendszerek változataiban négy fő funkciót szoktak megkülönböztetni: a munkakezelést, a taszkkezelést, az adatkezelést és a rendszerstatisztikát. Az IBM OS munkakezelése tulajdonképpen a mi felosztásunk szerinti alkalmazói támogatáshoz tartozik. A taszkkezelés körülbelül a mi felosztásunk szerinti rendszeradminisztráció folyamatvezérlési funkcióját fedi le, bár a háttérben feltételezi a processzorütemezést, a megszakításkezelést, a szinkronizálást és a tárkezelést. Az OS adatkezelési funkciója sem pontos megfelelője a mi felosztásunkban szereplőnek, mert tartalmazza a perifériakezelést is (fizikai szintű I/O kezelést). A rendszerstatisztika egyrészt a hardverkarbantartást segíti, másrészt a számítóközpont ügyvitelét támogatja (számlázás a felhasznált erőforrások alapján). Mi a hardverkarbantartás igényeivel itt nem foglalkozunk. A felhasználóbarát operációs rendszerek (CP/M, PC/MS--DOS, UNIX stb.) használatakor alig kell foglalkozni a funkcionális felosztás részleteivel. Ezeket az operációs rendszereket a boltból készen veszik, és nagyon kevés felhasználó kísérletezik a rendszer módosításával. Továbbá módosítás esetén a rendszer nem lenne kompatibilis a piacon készen kapható programokkal, ami a hétköznapi alkalmazók számára nem kívánatos. Az operációs rendszerek tervezésekor az elemi funkciók kijelölése bonyolult feladat. Függ a hardver erőforrásoktól és az alkalmazói igényektől. Némely feladatra (például szerszámgépvezérlés, folyamatvezérlés) rendkívül egyszerű funkciókból felépülő "operációs rendszer" is elegendő. Az esetek túlnyomó többségében azonban ez nem így van. Mindenesetre a bonyolultabb funkciók működése mindig az elemi funkciókra épül, ezért a bonyolultabb funkciókat magasabb hierarchiaszinten tételezzük fel. Az elemi funkciókat és a hierarchiaszinteket úgy kell meghatározni, hogy a kialakuló rendszer minél kevesebb ismétlődést tartalmazzon, és minél rugalmasabban tudjon alkalmazkodni a felmerülő igényekhez. Az elemi és összetett funkcióknál egyaránt fontos kérdés, hogy mely funkciók kerüljenek egymás melletti hierarchiaszintre, és melyek legyenek különböző hierarchiaszinten. A rendszeradminisztrációs funkciókat a rendszermag valósítja meg, amelynek a szolgáltatásait a már említett rendszerhívásokkal érhetjük el. Erről részletesen később, főként a 6. és 7. fejezetben lesz szó.
2.2. Programfejlesztési támogatás Ahhoz, hogy egy számítógépet használni lehessen, előbb programokat kell hozzá készíteni. Az operációs rendszerek egyik speciális feladata ennek a programfejlesztésnek a támogatása. A programfejlesztési támogatás funkciói azonban csak kis részben tartoznak a szűkebb értelemben vett operációs rendszer funkciói közé. Oda soroljuk viszont a rendszerhívásokat, amelyekkel a rendszeradminisztrációs szolgáltatásokat igénybe tudjuk venni. A programfejlesztést leginkább a számítógépes rendszer nyelvi szintje támogatja (szövegszerkesztők, programnyelvi eszközök). A továbbiakban nem a funkcionális felosztás részleteiből, hanem magának a programozási tevékenységnek az elemzéséből indulunk ki, a végén pedig összefoglaljuk a talált funkciókat. 2.2.1. A programozási munka részfeladatai A következő részfeladatok merülnek fel: 1) a probléma elemzése (adatszerkezetek, algoritmusok), 2) esetleg az algoritmus felbontása több részprogramra, 3) a (rész)program(ok) megírása alkalmas programnyelven, 4) a (rész)program(ok) belövése (modulteszt), 5) a részprogramok összeépítése (integrálás), 6) átadás üzemeltetésre. 2.2.2. Támogatások a problémaelemzéshez A problémaelemzéshez az operációs rendszerek általában nem nyújtanak külön támogatást. A korai
rendszerekben nem is voltak ilyen eszközök. A későbbiekben megjelentek a problémadefiniáló nyelveket értő fordítóprogramok, továbbá adatdefiniáló és adatmanipuláló nyelvekkel igyekeztek segíteni az adatbázis-technikában használatos adatelemzést. Ezeket később az ún. integrált programfejlesztő rendszerek speciális problémadefiniáló eszközei és programgenerátorai követték. A problémaelemzés fázisában először a feladat nyers vázlatát (informális specifikációját) adják meg, amelyet követ az ennél jóval precízebb formális specifikáció. Ez az integrált programfejlesztő rendszerekben adatbázisba kerül. A formális specifikációt még egyszer ellenőrzik, hogy kielégít-e minden megrendelői igényt. A véglegesített formális specifikáció alapján kezdődhet az implementálás. Eközben kiválasztják a megfelelő szoftvertechnológiát (Jackson, Warnier, heurisztikus stb.), valamint a (rész)feladat(ok)hoz legjobban illeszkedő programozási nyelvet, majd megindulhat a programtervezés és a programozás (részei: a programírás, a belövés, a rendszerpróba és az átadás). 2.2.3. A programírás támogatása Említettük a részprogramokat. Az algoritmusok részprogramokra bontásával (a módszer neve: moduláris programozás) kisebb programokat kell belőni. Bonyolultabb feladatokat pedig rendszerint nem is lehet egyetlen programmal megoldani, ezért ezek megírását több programozó együttműködésével, ún. team(illetve csoport-)munkában végzik. A részekre bontásból további előny származik, ha észrevesszük, hogy a részfeladatok többször felhasználható programjaiból programkönyvtárakat hozhatunk létre. A későbbi feladatokban már e könyvtárakra támaszkodhatunk, mert belőlük a szükséges elemek átvehetők az új program(ok)ba. Ezzel programozói kapacitásigényt takaríthatunk meg, ami a szoftverkrízisként emlegetett veszély elhárításában jelentős szerepet játszhat. (A szoftverkrízis: az igényelt új és módosítandó programok száma rohamosabban nő, mint a programozói kapacitás!) A programok írására olyan programozási nyelveket használnak, melyeket a nyelvi szint már említett programnyelvi eszközei, a fordítóprogramok és az interpreterek értelmezni tudnak. (Ezek közül a feladat megoldásához legjobban illeszkedőt kell kiválasztani.) A fordítóprogram megérti az adott programozási nyelven írt programot, és ha hibátlan, lefordítja olyan kódra (úgynevezett gépi kódra), amelyet a hardver értelmezni tud. A korai számítógépeken az így előkészített programmal már meg lehetett oldani a feladatokat. Az interpreter soronként értelmezi az adott programnyelven írt kódot -- többnyire -- anélkül, hogy gépi kódra fordítaná. Ezért ha interpretert használunk, a forrásnyelvű program azonnal használható feladatok megoldására. A fordítóprogramokat és az interpretereket nem tekintjük a szűkebb értelemben vett operációs rendszer részének. Persze a személyi számítógépek interpreter típusú BASIC rendszere egyben az adott gép operációs rendszere is. Benne integrálódnak a nyelvi funkciók és -- az egyszerűbb hardver és a kisebb igényű alkalmazás miatt szűk körű -- operációsrendszeri funkciók. A moduláris programozás és a programkönyvtárak használata létrehozott két speciális programot: * az ún. programszerkesztőt, amely programok modulokból való összeállítását végzi, és * a betöltőprogramot, amely a programokat közvetlenül a futáshoz készíti elő. Létrejöttüket az alábbiakban igyekszünk megindokolni. Vizsgáljuk meg először a programkönyvtárakat, amelyeket több szinten is használhatunk. A legalacsonyabb szint a forrásnyelvű könyvtárak alkalmazása, amikor a programok forráskódját (vagy annak egy részét) valamilyen módon könyvtárakból nyerjük. Egyes fordítóprogramok beépített forráskód-generálási lehetőségeket tartalmaznak (ezt preprocesszor- vagy makrotechnikának nevezik). A forráskönyvtárak használatát támogatják a programírásra használt szövegszerkesztő programok is, amelyekkel a szükséges könyvtári programrészek bemásolhatók programunkba.
A fordítóprogramok eleinte a gépbe közvetlenül betölthető, komplett gépi kódú programokat generáltak (ezekben mind az utasításkódok, mind az operanduscímek véglegesek voltak). Később a fordítókat megtanították arra, hogy a forrásprogramot ne fordítsák le azonnal tiszta gépi kódra, hanem félig fordított kódot (a forráskódból kiindulva úgynevezett célkódot, más néven tárgykódot, angolosan object-kódot) állítsanak elő (amelyben a hardver utasítások gépi kódja szintén végleges, de a címek átcímezhetők maradnak). Ezáltal kevesebb kódot kell a fordítóval generáltatni, mert a programhoz a félig fordított programrészek tárolására használt tárgyprogram-könyvtárból hozzá lehet másoltatni a program működéséhez szükséges kész, további modulokat (az első ilyen modulok a perifériakezelő szubrutinok voltak). A tárgyprogram-könyvtárban tárolt, tárgykódú, lefordított modulok jóval kisebb helyet igényelnek, mint a forrás-szövegek, ami újabb előny. Eleinte ezek a tárgyprogram-könyvtárak egy-egy fordítóprogramhoz kapcsolódtak, és a fordítóprogram maga vette elő a szükséges modulokat. Hamarosan rájöttek arra is, hogy a programkönyvtári programok (szubrutinok) belső formátumát uniformizálni kell, mert akkor egy program különböző moduljait a részfeladathoz legjobban illő programnyelven lehet megírni. A különböző nyelveken írt modulok lefordítása után keletkező tárgymodulok az azonos formátum miatt egyetlen monolit programmá fűzhetők össze. Az összeállításhoz új program kellett: a programszerkesztő, amelyet az angol linkage editor elnevezés alapján kapcsolatszerkesztőnek is hívnak -- a szövegszerkesztőktől megkülönböztetendő. Ez az egyes programmodulokat (fő- és alprogramokat, szubrutinokat) egyetlen (vagy néhány) végrehajtható programmá fűzi össze. A korai rendszerekben ezt a végrehajtható modult végcímzett programnak is hívták, mert a program a végrehajtásakor a főtárnak pontosan arra a helyére került, amit a szerkesztő kijelölt neki. Ezen a multiprogramozás kialakulása után változtatni kellett, mert ott az a célszerű, ha a programok a főtár bármely helyén működőképessé tehetők. Ezért a mai programszerkesztők nem készítenek végcímzett programokat, hanem a végrehajtható programban megtartják a tárgymodulokban található, átcímzéshez szükséges (relokációs) adatokat. Az összeszerkesztett programok futás előtti átcímzéséhez pedig egy újabb program kellett: az ún. betöltőprogram. Ez teszi lehetővé, hogy a végrehajtandó program a kijelölt tárhelyen működőképes legyen. Ezt nevezzük dinamikus áthelyezésnek. A programszerkesztőnek, a betöltőprogramnak és a tárkezelőnek nyilvánvalóan egyeztetett formátummal kell dolgoznia. Ezért, bár ezek a programok eredendően a nyelvi szinthez csatlakoznak, központi szerepük miatt a szűkebb értelemben vett operációs rendszer részének tekintik őket, tehát operációsrendszeri funkciók. A betöltő olykor ténylegesen az operációs rendszer magjában helyezkedik el (kézenfekvő módon a tárkezelés részeként). Itt kapcsolódnak a témához a rendszerhívások vagy más néven rendszerszubrutinok. A programozás során legsűrűbben használt funkciók programját nyilván érdemes állandóan a tárban tartani, és szubrutinként használni. A perifériák kezelése már a korai időkben is olyan bonyolult volt, hogy meghajtóikat eleve szubrutinként használták a programozók. Később az operációs rendszerek -- védelmi okokból -- ki is vették a programozók kezéből a perifériák közvetlen kezelésének a jogát. Mindezek miatt az operációs rendszerbe épült sok hasznos, vagy a védelmi rendszer miatt másképp megoldhatatlan funkció kódja, amelyek szolgáltatásait a már emlegetett rendszerhívások segítségével vehetjük igénybe. Mivel a tárvédelem az operációs rendszer szubrutinjainak normális behívását megakadályozná, speciális módszert kell használni a rendszerfunkciók hívására. A behívást rendszerint a hardver erre specializált utasítására, a szoftvermegszakításra alapozzák, ha egyáltalán van ilyen utasítása a hardvernek (az INTEL 8080-nak például nincs, ezért a CP/M-ben trükkökhöz kell folyamodni: szubrutinugrás az 5-ös címre). A paramétereket regisztereken vagy veremtárokon át adják át a hívott funkció szubrutinjának, majd az eredmények ugyanilyen módon jutnak vissza a hívóhoz. Tipikus szoftvermegszakító utasítások: SVC (IBM 360/370 és a velük kompatibilis gépek: ESZR, SIEMENS, ICL, HITACHI stb.), TRAPS (PDP 11, MSZR), INT (INTEL 8086 család). Ezeket általában nem közvetlenül használják, hanem valamilyen makrohívás keretében. A makró neve ilyenkor jellemző lehet az elvégzendő funkcióra (például TIME, WAIT, GETMAIN, MESSAGE stb.), és a makrokifejtés szervezi meg a makrohívás paraméterlistáján felsorolt változók átadását, majd a kívánt kódú operációs-rendszeri funkció behívását a
szoftvermegszakító utasítással. A legalacsonyabb szintű funkciók első sorban ASSEMBLY nyelven állnak rendelkezésre, de az utóbbi időben terjednek az olyan lehetőségek, hogy magas szintű nyelvek is el tudják érni az alacsony szintű funkciókat. Tipikus eset a C rendszerprogramozási nyelv, amely a UNIX kapcsán fejlődött ebbe az irányba. A UNIX kernel szolgáltatásait alapvetően C függvények formájában szokták megadni, bár párhuzamosan ASSEMBLY szintű definíciók is használatosak. Ma már nem megy csodaszámba például, hogy a TURBO PASCAL-ból elérhetjük az MS--DOS funkciókat. Egyszerű funkcióhívási példát mutat a 2.2. ábra (IBM PC). Program Operációs rendszer +-----------+ +------------+ | | | Szoftver >>>4*nn>>>> Ugrótábla | | v | megszakítás > | | | | INT nn >>>>>>>>>>>>>>>> | | | |...........| | | | | Folytatás <<<<<<<<<<<<<<<< |.....v......| | | | < | INTnn rutin| | v | <<<<<<<<<<< IRET | | | |............| +-----------+ +------------+ 2.2. ábra. Szoftvermegszakítás Programkönyvtárak végrehajtható programmodulokból is készíthetők. Ezeket bináris könyvtáraknak nevezik, és szintén nem tartják őket a szűkebb értelemben vett operációs rendszer részének, jóllehet olykor a rendszermagot, és az operációs rendszer más részeit is bináris programkönyvtárakban tárolják (UNIX, MS-DOS stb.). Az operációs rendszerek funkcióit megvalósító rendszermag (kernel, supervisor, monitor stb.) legnagyobb része mindig a tárban található (rezidens rész), köré azonban igen sok program csatlakozik a működés folyamán. Ezek időlegesen vesznek részt a munkában, emiatt tranziens (átmeneti) programoknak hívják őket. Az ilyen tranziens programokat szükség esetén a rendszermag a tranziens programkönyvtárból hívja be, amely szintén bináris programokat tartalmaz. A műveletek gyorsítására egyes tranziens programokat állandóan a főtárban tartunk az úgynevezett rezidens területen. A rezidens területen található programok esetében egy különleges operációsrendszeri támogatást, a kódmegosztás lehetőségét kell megemlíteni. Ennek lényege, hogy multiprogramozott környezetben egyes kódokat egyidejűleg több feladat (folyamat) is használhat. Amikor az egyik feladat munkája valamely okból a hívott kód közepén megszakad, az operációs rendszer a kód használatát más feladatnak is kiadja úgy, hogy egyrészt nem várja ki, amíg az előző feladat végigfut a kódon, másrészt külön munkaterület biztosításával újraindítja a hívott kódot. Ez megköveteli olyan kódok írását, amelyek bármikor újraindíthatók, aminek konkrét feltétele az, hogy a kódok önmagukat ne módosítsák működés közben, tehát minden állapotinformációt munkaterületen kezeljenek. Az operációs rendszerrel közölni kell, hogy a kód újraindítható vagy sem. Az újraindítható kódokat az operációs rendszer csak egyetlen példányban tartja a főtárban, akkor is, ha azt többen használják. Ez jelentős tármegtakarítást eredményezhet. Vannak olyan operációs rendszerek, melyekben a magas szintű nyelvek fordítói újraindítható kódokat generálnak (pl.: UNIX). A multiprogramozható operációs rendszerek elemi funkcióit megvalósító programok igen nagy százalékban (mondhatni szükségképpen) újraindíthatók (megoszthatók). A UNIX operációs rendszer olyan új elvet valósított meg, amely a moduláris programozást végrehajtási szinten -- ún. bináris programkönyvtárakkal -- támogatja. A UNIX-ban is van programszerkesztő és betöltőprogram (operációsrendszeri funkcióként), de az összeszerkesztett, végrehajtható programokat a parancsnyelv segítségével összefűzhetjük egy adott feladat megoldására, és az egyes bináris programok önállóan oldják meg a részfeladatokat. Ezért egy probléma megoldásához nem kell őket nagy méretű monolit programmá összefűzni. A UNIX itt említett végrehajtható (bináris) könyvtárait inkább az alkalmazói támogatás segédprogramjaihoz sorolhatnánk. Mindenesetre a UNIX alapelve a sok egyszerű, hasznos kis segédprogram
alkalmazása, amelyek univerzálisan felhasználhatók, és kombinációjukkal számtalan bonyolult feladat megoldható. A kis modulok belövése után elmarad a monolit programoknál szokásos integrációs teszt, ami a rendszerek gyors megvalósításához jelentős segítség. A tárigények is csökkennek, ami multiprogramozott környezetben szintén előnyökkel jár. A programkönyvtárak a nyelvi szinten helyezkednek el, de kezelésükhöz a legtöbb operációs rendszer speciális könyvtárkezelési funkciókat biztosít (az adatkezelési funkció részeként). 2.2.4. Támogatás a programok belövéséhez A programozói munka legszorgosabb része a programbelövés. Ezért ehhez a munkához a programozó szeretne minél több támogatást kapni. A programbelövést az operációs rendszerek és a programozási nyelvek a nyomkövetési (angolul debug, trace) funkciókkal támogathatják. Nyomkövetés több szinten végezhető. A legkézenfekvőbb megoldást már korán megtalálták: a programba -- az algoritmushoz funkcionálisan hozzá nem tartozó -- speciális kimeneti ("tesztprint") utasításokat, úgynevezett nyomkövető utasításokat lehet beépíteni az adott programnyelv szabályai szerint. Sajnos, mint minden kódot, a nyomkövető utasításokat is be kell lőni, ami néha a hibás adatmező-tartalmak miatt nem túl könnyű, elég sok vesződséggel jár. További bonyodalmak adódhatnak akkor, amikor a végleges programból ki kell hagyni ezeket a kimeneti formátumot rendszerint igen erősen zavaró utasításokat. A nyomkövetés kihagyása újabb belövési igényt támaszt. A nyomkövető utasítások mellékhatása ugyanis ideiglenesen kiküszöbölheti a program algoritmushibáit, ezért a korábbi hiba a nyomkövetés eltávolítása után ismét előjöhet. A nyomkövető utasításokkal majdnem minden belövési probléma megoldható, de olykor csak igen fáradságosan. A nyomkövető utasítások nyelvi szintű eszközök. Már a korai időkben rendelkezésre állt egy másik módszer: hibás futás esetén az operációs rendszer tárkivonatot (vagy az elterjedt angol kifejezéssel dumpot) készít, ami nem más, mint az operatív tárban található programok és adatok tárcellánként számokkal kódolt, formázott listája. További lehetőségként a programozó is kezdeményezhette a tárkivonatok készítését. A korai rendszerekben ezért kiterjedten alkalmazták a belövéshez a dumpelemzést. Ehhez azonban a belső tárolási formátumok, és az operációs rendszer működési részleteinek alapos ismeretére volt szükség. E módszerrel tulajdonképpen minden hibát el lehet hárítani, de igen nagy szellemi erőfeszítéssel. Az operációs rendszerek bonyolultságának növekedtével ez a módszer egyre jobban kiszorul a belövési technikából, s alkalmazásának csak az amúgy is ismeretigényes alapszoftver-munkák esetében van még néha értelme. A tárkivonat készítése operációsrendszeri funkció, mert alkalmazói szintről az operációs rendszer védelmi rendszerén át csak így lehet hozzáférni a keresett információkhoz. A legkorszerűbb nyomkövetési technika nem tesz további terheket a programozó vállára, hanem a meglevőket is igyekszik levenni. A nyomkövetési eszközöket két nagy csoportba sorolhatjuk: hardver- és szoftver nyomkövetési támogatások. A hardver nyomkövetési támogatás azon alapul, hogy a hardver speciális utasítás(ok) végrehajtása esetén megszakítja a program futását, és ebben a pillanatban elemezhető a program állapota. Ezt a támogatást főként a korábbi dumpelemzés helyettesítésére lehet használni, ezért ugyanolyan mély ismereteket igényel, mint a dumpfejtés, így fő alkalmazási területe az alapszoftver-gyártás. Ezt a funkciót az operációs rendszer speciális megszakítás-kezelő alrendszerrel szokta támogatni, de a lebonyolításhoz magasabb szinten működő monitor, debugger programra is szükség van. A szoftver nyomkövetési támogatás nyelvi szinten áll rendelkezésre. Az interpreterrel értelmezett nyelvek például eleve tartalmaznak beépített nyomkövetési alrendszert. Az interpretereknél a nyomkövetési igényt egy nyelvi utasításpárral lehet be és kikapcsolni. A legelterjedtebb a programlogika működésének ellenőrzésére alkalmas TRACE ON/OFF parancspár, amely a feltételes és feltétlen programelágazások követését teszi lehetővé. Ebből már lehet következtetni egyes programváltozók
(vezérlőváltozók) értékének alakulására. Bonyolultabb lehetőség a szimbolikus dump: az interpreter a gépkezelő (aki rendszerint maga a programozó) manuális beavatkozásakor (BREAK = megszakítás) vagy programhiba miatti leállás esetén egy parancs hatására kilistázza az összes érvényes változó tartalmát. Ennél is bonyolultabb lehetőség az értékadások nyomkövetése, amelynek bekapcsolásakor az interpreter kilistázza minden olyan programváltozó új értékét, ami értéket kap. Ez olykor-olykor éppen olyan nehezen áttekinthető listát eredményez, mint a régi dumpok. Ilyenkor jó, ha az interpreter szelektált értékadási nyomkövetésre is képes, azaz megmondhatjuk neki, hogy éppen mely változók értékeire vagyunk kíváncsiak. A fordítóprogramoknál a helyzet egy kicsit más, mert az eddig említett nyomkövetési technikák legjobban interaktív környezetben érvényesülnek (ezért említettük először az interpreteres lehetőségeket). Persze a fordítóprogramokba is be lehet építeni hasonló automatikus nyomkövetési funkciókat. Ilyenkor az előbb említettekhez képest más lehetőségek is adódnak. Például elég korán bevezették az úgynevezett feltételes kommentárokat. Ezek olyan megjegyzésként kódolt programutasítások, amelyeket a fordító egy adott opció bekapcsolt állapota esetén a forrásprogram részének tekint, egyébként nem. Így ezekbe a feltételes megjegyzésekbe helyezhetjük el a korábban már említett nyomkövető utasításokat. Miután a nyomkövetés segítségével kijavítunk egy hibát, nem kell mást tenni, mint kikapcsolni a feltételes fordítási opciót, és megszabadulhatunk a nyomkövető kiírások "dzsungelétől". A nyomkövető utasítások benne is maradhatnak a programban, és egy esetleges későbbi hibaelemzésnél újra felhasználhatók. Egyes nyelveknek van mind interpreteres, mind fordítóprogramos támogatása. Ezek egyesítik az interaktív programbelövés előnyét a hatékony programlétrehozás lehetőségeivel. Ez persze csak akkor igaz, ha a fordítóprogram pontosan meg is érti azt, amit az interpreter változat elfogad. Ellenpéldaként említhető az az eset, amely a DOS alatt működő dBASE III adatbázis kezelő rendszerrel történt meg. A dBASE-nek interpreteres programértelmezője van, de egy idegen cég fordítóprogramot (CLIPPER) írt hozzá. Az természetesen bizonyos interaktív parancsokat nem tudott kezelni, ami érthető volna. A rosszabb, hogy javítani is akartak az eredeti dBASE III nyelven. A dBASE III újabb változatába ezek egy része szintén belekerült, de természetesen más jelentéssel. Így a CLIPPER ezeket nyilvánvalóan félreértette. Ilyen inkompatibilitási problémák esetén arra vagyunk utalva, hogy programíráskor csak a két nyelvjárás közös elemeit használjuk, különben le kell mondanunk az interpreteres fejlesztés adta kényelmekről. (A CLIPPER-t később hozzáigazították a dBASE-hez, de mi az esettel csak az interpreter-fordítóprogram inkompatibilitásokra szerettük volna felhívni a figyelmet.) A nyomkövetési technika különleges eszközei a keresztfejlesztő rendszerek, amelyek olyan szoftverek belövését támogatják, amelyek nem a fejlesztőgépen, hanem egy másik -- esetleg még éppen csak kidolgozás alatt álló -- számítógépen fognak futni. Ezek adatátviteli kapcsolatot is igénylő elég bonyolult hardver-szoftver környezetet jelentenek. 2.2.5. A programintegrálás támogatása A programok összeépítése modulokból tartogat még egy olyan munkafázist, amellyel foglalkozni kell. Ez az úgynevezett integrációs teszt. Ennek halovány támogatását jelenti maga a szerkesztőprogram, amely hibajelzést ad, ha valamely modul hiányzik a komplett program összeállításához. A program algoritmushibáinak kiszűrésében, a hivatkozott változókban és adatstruktúrákban felmerülő ütközések kiderítésében azonban nem sokat segít. Az integrációs tesztben rendszerint újra kell kezdeni a nyomkövetést. A problémákon igyekeznek segíteni az integrált programfejlesztő rendszerek, melyek megpróbálják megőrizni az adatok és adatszerkezetek konzisztenciáját. Az algoritmushibák kivédésére programhelyesség bizonyítási (verifikálási) módszereket, programgenerátorokat, és programstruktúra visszafejtő, automatikus programdokumentáló programokat használnak. Ez utóbbiak tulajdonképpen alkalmazói szintű funkciók.
2.2.6. A programfejlesztési támogatás fő funkcióinak összefoglalása A programfejlesztési támogatás fő funkciói tehát a következők: * rendszerhívások: a programokból alacsony szintű operációsrendszeri funkciók aktivizálására, * szövegszerkesztők: a programok és dokumentációk írására, * programnyelvi eszközök: fordítóprogramok és interpreterek a nyelvek fordítására vagy értelmezésére, * szerkesztő- és betöltőprogramok: a programmodulok összefűzésére illetve tárba töltésére (végcímzés), * programkönyvtári funkciók: a különböző programkönyvtárak használatára, és * nyomkövetési rendszer: a programok belövésére. Ezek részben vagy egészben megtalálhatók az integrált programfejlesztő rendszerekben.
2.3. Alkalmazói támogatás Az alkalmazói támogatás funkciói a számítógépes rendszer több szintjén valósulnak meg, és az alábbi fő funkciókra bonthatók: * operátori parancsnyelvi rendszer: a számítógép géptermi üzemvitelének támogatására; * munkavezérlő parancsnyelvi rendszer: a számítógép alkalmazói szintű igénybevételének megfogalmazására; * rendszerszolgáltatások: az operációs rendszer magjával közvetlenül meg nem oldható rendszerfeladatokra; * segédprogramkészlet: rutinfeladatok megoldására; * alkalmazói programkészlet: az alkalmazásfüggő feladatok megoldására. 2.3.1. Az operátori nyelvi rendszerek Az operátori és a munkavezérlő parancsnyelvek elvileg a nyelvi szinthez tartoznak, de fontosságuk és a megvalósításukhoz igényelt, mélyebb szintű operációsrendszeri funkciók (beolvasók, ütemezők) miatt a szűkebb értelemben vett operációs rendszer részének tekintjük őket. A számítógépek történetében kimutatható, hogy az operációs rendszerek az üzemeltetési problémák könnyítésére jöttek létre. A korai számítógépek nagyon lassúak voltak, és kezelésük is igen bonyolult tevékenységet igényelt, ezért többnyire maguk a programozók kezelték a gépet. A gépek sebessége azonban rohamosan nőtt, így hamarosan tarthatatlanná vált, hogy két munka között a (méregdrága) gép hosszabb ideig álljon (például azért, mert a programozó gondolkozott a felmerült hibán). Az állásidők egy része abból adódott, hogy a munkák közötti váltás manuálisan, nem "elektronikus tempóban" ment végbe, más része a felhasználók gyakorlatlanságából és ügyetlenkedéséből származott. Voltak elkerülhetetlen veszteségidők is, mint például a különböző fordítók betöltéséhez szükséges idők, amit azonban jobb munkaszervezéssel ritkítani lehetett. Ebből jutottak arra a következtetésre, hogy szükség van olyan személyzetre, aki kizárólag a gép megtömésén fáradozik, és akinek helyismerete és munkatapasztalata nagyban segíteni tudja a programozók munkáját is. Hamar kiderült, hogy az üzemeltető személyzet munkájából sok mozzanat automatizálható, sőt automatizálandó az emberi tévedések csökkentésére. Az automatizáló programcsomagot nevezték el operációs rendszernek. Maga az elnevezés is az üzemeltetésre utal. Az első operációs rendszerekben tehát központi szerepet játszottak az operátori parancsnyelvek. Később ezekből vált ki a munkák (kötegek) összeállításának megfogalmazására szolgáló munkavezérlő nyelv, de az interaktív rendszereknél megint visszatérés figyelhető meg egy közös vezérlőnyelvhez.
Az operátori parancsnyelv a géptermi, futásideji események vezérlésére szolgál. Kifejezetten a géptermi személyzet munkáját segíti. Részleteiben itt nem foglalkozunk vele, csak megjegyezzük, hogy a programozási nyelvekhez viszonyítva igen primitív, erősen a konkrét hardver--szoftver környezethez illeszkedő stílusa van. A túl korai kialakulás nyomai máig is érződik rajta. Szabványosítása a jelenlegi tényhelyzetben szinte reménytelen. 2.3.2. A munkavezérlő-nyelvi rendszerek A munkavezérlő parancsnyelv (röviden munkavezérlő nyelv, angolul Job Control Language, a továbbiakban: JCL) a számítógépre szánt munkák csomagokba (kötegekbe) gyűjtésére, összeállítására, számítógépes zsargonban job-ok (dzsobok, munkacsomagok, munkák) írására szolgál. A munkacsomagokat tipikusan nem az üzemeltető személyzet írja, bár ez sem kizárt. A munkavezérlő nyelv az alkalmazók és a programozók munkáját segíti. Megjegyzendő, hogy a munkacsomagokba rendszerint operátori parancsokat is be lehet iktatni. A két nyelv tehát keveredik. A munkavezérlő nyelvek, amelyeket vezérlőáram olvasó programok fogadnak, horizontális jellegűek, mert kevés számú, de bonyolultan paraméterezhető parancsokra épülnek. Ezek sem hasonlítanak a programozási nyelvekre, akárcsak az operátori nyelvek. A legtöbb interaktív rendszerben, ahol tipikusan nincsenek munkacsomagok, az operátori és a munkavezérlő nyelv egyetlen parancsnyelvvé olvadt össze. Ezekben is lehet azonban munkacsomagokat összeállítani az úgynevezett parancsállományok alkalmazásával, amelyekben parancsnyelven írt szövegek vannak, és ezek helyettesítik a terminálról kiadható parancsokat. Az interaktív parancsnyelvek, amelyeket parancsértelmező programok fogadnak a terminálokon, vertikális jellegűek, mert szerteágazó, egyébként egyszerű paraméterezésű parancsokra építenek. A parancsnyelvek további jellegzetességei: a programnyelvekre hasonlító szintaxis, algoritmikus jelleg (feltételes végrehajtás, ciklusszervezés, aritmetikai,- logikai,- karakteres műveletvégző képesség, változók és parancsparaméterek kezelése) és erőforráskorlátokat is beállíthatnak (munkaterület mérete, jogkörök, a kezelhető könyvtárak stb.). Újabban tért hódít az ún. grafikus interfész, melyet elsőként az APPLE MACINTOSH valósított meg. Szokták ikonvezérelt felhasználói interfésznek is hívni, mert a grafikus képernyőn megjelenő „ikonokkal” (képecskékkel) igyekszik szimbolizálni az igénybe vehető szolgáltatásokat. (A hardver kapcsán már volt szó róla, de az új hardverelemek -- egér, grafikus képernyő -- jóval kisebb szerepet játszanak benne, mint a szükséges szoftver). A grafikus interfészen át tartott munka során először érezheti igazán a felhasználó, hogy nem olyan barátságtalan számítógéppel van dolga, ami rögtön a kezére üt, ha elgépel valamit, mert a lehető legkevesebb alkalmat adja neki a tévesztésre. Az alkalmazó kifejezetten a problémára koncentrálhat, nem kell folyton számítógépes zsargonban fogalmaznia. Ilyen kapcsolatot az IBM PC-ken a GEM és a WINDOWS tesz lehetővé. Nem véletlen, hogy az OS/2 Presentation Manager-e is ugyanezt fogja tudni. Az AT&T a UNIX PC-n a UNIX SYSTEM V. verziót szintén grafikus interfésszel látta el, de még a kis COMMODORE 64-en is van már ilyen a GEOS formájában. Ezek arra mutatnak, hogy a grafikus interfész megállíthatatlanul terjed. Mégsem kell azt hinni, hogy a vezérlőnyelveknek ezzel bealkonyult. Programfejlesztésnél például könnyebb egyetlen, jól paraméterezett paranccsal áttérni a szükséges üzemmódba. A problémához ingadozó viselkedéssel kihasználhatjuk mindkét interfésztípus előnyeit. 2.3.3. A rendszerszolgáltatási funkciók A rendszerszolgáltatások alapja az a programkészlet, amely az operációs rendszer szolgáltatásainak igénybevételét közvetve teszi lehetővé. Ezek a programok általában nem a rendszermaghoz tartoznak, hanem folyamatokként futó külön programok (beolvasók, nyomtatók, ütemező, iniciátor/terminátor stb.). Az 5. fejezetben erről részletesebben lesz szó.
2.3.4. A segédprogramkészlet A segédprogramkészlet -- amelyet rendszerközeli szoftvernek is neveznek -- nem tartozik a szűkebb értelemben vett operációs rendszerhez és bináris programkönyvtárak útján valósul meg. Segédprogramokkal, egyszerű paraméterezéssel, sok rutinfeladat (állománylétrehozás, másolás, törlés, rendezés stb.) oldható meg. Egyes operációs rendszerekben a segédprogramok döntő szerepet játszanak (UNIX, CP/M, PC/MS--DOS, OS/2 stb.), mert a vezérlőnyelv parancsainak kibővítésére használják. Pontosabban: amit a parancsértelmezője közvetlenül megért, azt belső parancsnak, a program-könyvtárból előveendő parancsokat pedig külső parancsnak szokták nevezni. 2.3.5. Alkalmazói programcsomagok Az alkalmazói programkészlet vagy a hardvergyártótól, vagy független szoftvergyártóktól készen vásárolható programcsomagokból áll, esetleg maga az alkalmazó fejleszti ki őket a saját igényei szerint. Egyes interaktív operációs rendszerekben az alkalmazói programok is beépülnek a vezérlőnyelv (külső) parancskészletébe, ami egységes kezelésmódot biztosít.
2.4. Mintapéldák 2.4.1.
Az IBM 360/370/30XX/43XX és az ESZR--I/II/III sorozat operációs rendszerei
Az IBM cég -- mint már említettük -- a hatvanas évek közepén vezette be 360-as gépcsaládját, melyek modelljei egy -- szoftver szinten erősen, hardver szinten kevésbé -- kompatibilis sorozatot képeztek. Az erős szoftverkompatibilitást egyrészt a sorozat gépeire kidolgozott operációs rendszerek, másrészt szigorúan szabályozott szoftverfejlesztési alapelvek biztosították. Az IBM egy újítás bevezetésekor maximálisan igyekszik figyelembe venni régi felhasználóinak érdekeit. Ez jelentősen kötötte a fejlesztők kezét (amit Amdahl, a sorozat főkonstruktőre nem tudott elviselni, kilépett, új céget alapított -- sikerrel!). E kötelmek azonban a felhasználóknak nagy biztonságot adtak, mert hosszú távon számíthattak arra, hogy programjaikat nem kell minden újabb operációsrendszeri módosítás átvétele után módosítani, sőt esetleg újraírni, mint az a korábbi időkben napirenden volt. Az IBM politikájának megfelelően a későbbi új sorozatok (370/30XX/43XX) gépein ugyanazon operációs rendszerek fejlettebb változatai futnak. Tulajdonképpen sok operációs rendszer készült a 360/370-es sorozatú gépekre, de ezekből csak három típus maradt talpon: a DOS, az OS és a VM/370. Ezeknek viszont rengeteg verziója alakult ki a hardverfejlődés követésére. Az ESZR sorozat és a dugasz-kompatibilis gépeket gyártók (amerikai, japán és európai cégek) gépein szintén az említett operációs rendszerek kompatibilis változatai futnak, így elterjedtségük a nagygépes kategóriában döntő jellegű. Ezért bár a folytonos újítások ellenére eléggé elavultak, megismerésüket fontosnak és tanulságosnak véljük. Különösen azoknak, akik nagygépes rendszerekkel állnak valamilyen kapcsolatban. DOS operációs rendszer A DOS (Disk Operating System = lemezrezidens operációs rendszer) a kis teljesítményű (kevés tárral rendelkező, lassú) gépek tipikus univerzális, kötegelt üzemmódú multiprogramozható operációs rendszere. Rendszeradminisztrációs funkciói statikusak, de a kezelésmódból adódó egyszerűbb kivitelezés lehetővé teszi, hogy a rendszeradminisztráció kapacitásigénye ne csökkentse túlzottan az amúgy is kis teljesítményű hardver átbocsátóképességét. A későbbi változatok rugalmassága nőtt, és támogatást kaptak új hardverlehetőségek, melyek közül a legjelentősebb a virtuális tár bevezetése volt. Ez a DOS egészen új változatának, a DOS/S-nek a kezdetét jelentette. Több jel arra mutat, hogy az IBM igyekezett volna megszabadulni a DOS-tól, de a lelkes felhasználói tábor nem engedte kihalni. Ha az IBM úgy nyilatkozott, hogy ennek, vagy annak az újdonságnak a támogatását a
DOS-ba már nem veszi fel, akkor mindig akadt egy ügyes felhasználó, aki ezt megtette. Az IBM ugyanis az önmaga szabta szabályok szerint köteles támogatni a felhasználókat minden olyan fejlesztés elvégzésében, amit ő nem végezne el, -- a támogatásba beleértve a forráskódok rendelkezésre bocsátását is(!). A DOS forráskódja elég kis méretű volt ahhoz, hogy "ne tudjon ellenállni a buzgó bitfaragók kísérletezéseinek" (én is foglalkoztam vele: Zs.P.). Ez odavezetett, hogy ma nincs a világon két tökéletesen kompatibilis DOS installáció. A DOS operációs rendszer részei mágneslemezen találhatók. Indításához a mágneslemeztár legkisebb fizikai című blokkjában van egy program, amely az indítógomb hatására betöltődik a főtár legalsó részére, majd automatikusan elkezd végrehajtódni. Ez a kezdeti programbetöltő program, amely végrehajtása során a mágneslemezről betölti a főtárba az operációs rendszer magprogramját. Ezt IBM szóhasználattal supervisornak (felügyelőprogramnak) nevezik, és ez szolgáltatja a 2.1.-ben elemzett rendszeradminisztrációs funkciókat. A DOS nyelvi szintjén a következő nyelvek és nyelvi fordítók találhatók: FORTRAN, az IBM legkorábbi szoftver csúcsteljesítménye (ez volt az első magas szintű nyelv, amely bebizonyította a magas szintű nyelvek létjogosultságát -- sokan máig is lelkesednek érte); ALGOL (az első precedens a nemzetközi szabványosításra a számítástechnikában, de az IBM, bár megalkotásában tevékenyen részt vett, nem szerette -- DOS változata nem is IBM eredetű!); COBOL (nyelv az ügyviteli munkák támogatására -- és a rossz nyelvek szerint: a nagybetűk írásának a gyakorlására), majd a 360-as sorozatra újonnan létrehozott IBM-szülött nyelv: a PL/I (Program Language One = első programnyelv), melyet az IBM az előbb felsorolt három nyelv ötvözeteként, univerzális nyelvként igyekezett bevezetni (más gépsorozatokon alig terjedt el). A PL/I-et az IBM számos alsóbb szintű operációsrendszeri funkcióval is megtámogatta, így az tényleg elég jól funkcionál a sorozat gépein, különösen, ha a legújabb optimalizálós változatokat nézzük. További nyelvekhez is készültek fordítóprogramok a DOS rendszerben. Ezek egy része interaktív alrendszerként interpreteres formában jelent meg. Manapság minden lényeges nyelvre van valamilyen DOS alatt használható fordítóprogram vagy interpreter. A DOS-os fordítóprogramok, a fentebb elemzett okok miatt, félig fordított kódot, azaz tárgykódot generálnak, aminek szabványos formátuma van, ezért elvileg a programszerkesztő (IBM terminológiával: Linkage Editor) bármely nyelven írt kódmodul tárgyprogramját hozzá tudja szerkeszteni a komplett programokhoz. Ezt az ideális állapotot rontja, hogy a futáskor minden nyelvi fordító speciális nyelvi végrehajtási környezetet tételez fel. Így az assembly nyelvű modulok hozzáfűzése okozza a legkisebb gondot. A későbbi változatokban ezen úgy igyekeztek segíteni, hogy a nyelvi fordítóknak be lehet jelenteni, hogy milyen, más forrásnyelvből fordított modulok hozzáfűzésére kell felkészülniük. Igazi programfejlesztési támogatást először az interaktivitást biztosító távfeldolgozó hardver megjelenése hozott. Létrehoztak interaktív alrendszereket (pl.: APL), amelyekben szövegszerkesztők is megjelentek. Fejlődést jelentett az RJE (Remote Job Entry= távoli kötegelt munkabevitel) megjelenése is, mert bár csak a kötegelt üzemmód határait terjesztette ki a géptermen kívülre, de ezzel decentralizálta a hardvererőforrásokat, ami a programfejlesztésekre igen kedvező hatású volt. A programfejlesztés támogatásának újabb lépcsőjét az adatbázis-technika kialakulása jelentette (DL/I = Data Language One = első adatkezelő nyelv -- PL/I mintára!). Az adatbázis-technika a DOS/VS-ben rendszeradminisztráció szintű támogatást kapott: bevezettek egy új adatkezelési módszert, a VSAM-ot (Virtual Storage Access Method = virtuális adatelérési módszer). VSAM használatával a programozónak csak a logikai adatszerkezetre kell figyelnie. Látszólag, azaz virtuálisan, elrugaszkodhat a fizikai tárolási szerkezettől. (A VSAM, de még inkább a DL/I, alkalmazásakor a fizikai tárolási szerkezettel nem az összes programozónak, hanem csak egy személynek, az adatadminisztrátornak kell foglalkoznia.) A DOS/VS legfejlettebb programfejlesztési támogatása az ETSS (Entry Time-sharing System = interaktív időosztásos alrendszer), amely közeli és távoli terminálokon vehető igénybe. A terminálkapcsolatokat a rendszeradminisztráció a VTAM (Virtual Telecommunication Access Method = virtuális távfeldolgozási elérési módszer) adatkezelési technikával támogatja. Ez elődje a későbbi hálózati adatkapcsolati szabványoknak (SNA stb.).
A nyomkövetési támogatás a DOS-ban kezdetben csak a dumpot jelentette. A fordítóprogramokba később beépítettek szoftver nyomkövetési eszközöket is. A DOS operációs rendszer programfejlesztést támogató funkcióit még további programtermékek egészíti ki, amelyek nem is mind az IBM-től származnak. Az ESZR-en belül szintén jelentős DOS és DOS/VS fejlesztéseket hajtottak végre, és még továbbiak vannak folyamatban. A hazai kutatóhelyek pl. elől járnak az integrált programfejlesztő rendszerek kidolgozásában (SZÁMALK, SZKI). A DOS alkalmazói támogatásában megtaláljuk a 2.3.-ban felsorolt minden fő funkciót. Így van operátori parancsnyelv, van munkavezérlő nyelv (JCL-utasítások), amelyek annyiban keveredhetnek, hogy a munkakötegben is megadhatók operátori parancsok, és az operátori konzolról is beadhatók JCL-utasítások, illetve a futás közben hibásnak bizonyult JCL-utasítások konzolról javíthatók. A JCL beolvasóprogramja egyben magas szintű ütemezői feladatokat is ellát rendszerszolgáltatásként. A rutinfeladatok megoldásához sok segédprogram áll rendelkezésre (DITTO -- másoló, SORT/MERGE -- rendező, összefésülő stb.). Az IBM igen széles skálán biztosít alkalmazói programcsomagokat. A jobbakat sajnos csak bérelni lehet, megvenni nem. OS operációs rendszer Az OS (IBM System 360/370 Operating System = az IBM 360/370-es sorozatú gépeinek operációs rendszere) a nagyobb teljesítményű modellek üzemeltetésére és univerzális használatra szánt, de alapvetően kötegelt üzemmódú, multiprogramozható operációs rendszer. Rendszeradminisztrációs funkciói jóval dinamikusabb üzemeltetést tesznek lehetővé, mint a DOS rendszer. Ennek ára a rendszeradminisztráció jóval nagyobb kapacitásigénye, amely a kisebb modelleknél oda is elvezethet, hogy az alkalmazói program alig halad a nagy rendszeradminisztrációs terhelés (IBM terminológiával: overhead) mellett. A modellméretek függvényében az OS-nek három változatát lehetett használni: * PCP-t (Primary Control Program= egyáramú vezérlő), * MFT-t (Multiprogramming with Fixed number of Tasks = multiprogramozás fix (maximált!) számú taszkkal), és * MVT-t (Multiprogramming with Variable number of Tasks = multiprogramozás változó számú taszkkal). A PCP kihalt, mert csak igen kis kapacitású modelleken lehetett használni, az MFT és az MVT pedig jelentősen átalakult a virtuális gépek megjelenésével. Az MFT utóda az OS/VS1, míg az MVT-nek két utóda is van az OS/ VS2 keretében: az SVS (Single Virtual Storage = egyetlen virtuális táras rendszer), és az MVS (Multiple Virtual Storage = több virtuális táras rendszer). Az OS operációs rendszerek indítása hasonló a DOS-éhoz, de a betöltési folyamat elég hosszú lehet, mert induláskor az OS feltérképezi a teljes hardver-szoftver környezetet, "rátelepszik" az összes erőforrásra. Működés közben az állapotváltozásokat folyamatosan nyomon követi. A nagy rendszerterhelés hátterében ez húzódik meg, azonban igen jelentős előnyöket jelent a felhasználónak, hogy szinte semmit nem kell a "rendszer szájába rágni", az mindent tud magától (ugye, milyen régi a Plug&Play? -- ZSP,2K.9.28.). Az OS rendszeradminisztrációs funkcióit megvalósító rendszermagot is supervisornak nevezik. Ez azonban jóval bonyolultabb és jóval nagyobb, mint kisöccsének, a DOS-nak a supervisora. (Jobban ellen is áll a rendszerprogramozók inkompatibilitást generáló kísérletezéseinek, illetve "exit" (kilépési) pontokkal rendszabályozza a módosítási lehetőségeket.) A funkciókat kiszolgáló programok igen nagy része tranziens, amelyek közül az adott installációban leggyakrabban használtakat induláskor be lehet hozni a főtár rezidens területére. Az OS támogatja a kódmegosztást, azaz az újraindítható programokat. Az OS alatt használható programozási nyelvek köre és alkalmazásuk filozófiája azonos a DOS-nál mondottakkal. Az OS tárgykódú moduljai kevésbé nyelvfüggők, mint a DOS-belieké. Az OS-ben a programszerkesztő mellett létezik egy megtévesztő nevű program is, a loader. Ez nem azonos a 2.2.-ben tárgyalt betöltővel, bár angolul azt jelenti. Inkább speciális szerkesztőprogramnak tekinthető, amely nem készít háttértáron elhelyezhető programmodult, hanem egyenesen a főtárba helyezi az összeszerkesztett programot. A
főtárba töltéshez persze igénybe veszi a rendszeradminisztráció tárkezelő moduljának programbetöltő funkcióját. Ez példa arra, hogy az egyes számítógépgyártók mennyire eltérő tartalommal használhatják ugyanazt az elnevezést. A terminológia szabványosítása folyamatban van, de világszabvány (ISO) szinten elég lassan halad (a szakirodalom pedig, sajnos, alig figyel rá!). Az OS programfejlesztési támogatása jóval fejlettebb, mint a DOS-é. Itt is persze inkább az interaktivitást biztosító eszközök emelhetők ki. Már az MFT-ben megvalósították az úgynevezett CRJE (Conversational Remote Job Entry = interaktív távoli munkabeviteli alrendszer) szolgáltatást. Ez szövegszerkesztőt is tartalmaz, ezért interaktív programbevitelt tesz lehetővé, ami jelentős előny a régi lyukkártya-technikához képest, hiszen nem kell bíbelődni terjedelmes kártyakötegekkel. Az MVT-ben hozták létre a legfejlettebb programfejlesztési támogatást nyújtó szoftverkörnyezetet, amelyet a rendszeradminisztráció TSO (Time-sharing Option = időosztásos lehetőség) alrendszere támogat. Az IBM gépeken eredetileg volt külön időosztásos operációs rendszer (TSS) is, de inkább a korábbi OS operációs rendszer alrendszereként megkonstruált időosztásos támogatás vált be (többek között azért, mert az üzemeltetésnek kényelmetlenebb volt állandóan operációs rendszereket váltogatni a gépen). A TSO nem csak interaktív szövegbevitelt biztosít, hanem lehetővé teszi a programok on-line belövését, méghozzá a hardver nyomkövetési támogatást is beleértve. (A nem interaktív programnyelvi eszközök csak dumpot, és szűk választékú szoftver nyomkövetést támogattak!) Az OS rendszerek adatkezelése igen rugalmas. A programokat maximálisan perifériafüggetlennek írhatjuk meg, és a hozzárendelés csak az utolsó pillanatban, a program futásakor történik meg. A DOS/VS-ben említett adatelérési módokat (VSAM, VTAM) az OS verziók is támogatják, de lényeges újdonságok nem jelentek meg bennük. Az IBM operációs rendszerekre jellegzetesen elmondható, hogy felfelé kompatibilisek: az egyszerűbb rendszerek felügyelete alatt készült programok (relatíve kevés módosítással) újrafordítás után használhatók a bonyolultabb támogatást nyújtó változatokkal is. Az OS alkalmazói támogatása a DOS-hoz hasonló. Az operátori nyelv elég bonyolult. Csak ezzel lehet biztosítani az üzemeltetés maximális rugalmasságát. Ehhez hozzájárul, hogy a támogatott hardvereszközök köre is szélesebb, mint a DOS-ban. A munkavezérlő nyelv erősen elvált az operátori nyelvtől, ezért a hibás JCLutasítások például konzolról nem javíthatók úgy, mint a DOS-ban. A hibás JCL-utasítást tartalmazó munkacsomagot a rendszerolvasó rögtön kirekeszti a feldolgozásból. A JCL-utasítások között azonban elhelyezhetők operátori parancsok, amelyeket -- jogosultság esetén! -- az operációs rendszer azonnal végre is hajt. Az OS munkavezérlő nyelvét később részletesen is tárgyaljuk. Megjegyzendő, hogy az OS interaktív alrendszereinek (például a TSO-nak) a szolgáltatásait teljesen más filozófiájú parancsnyelvekkel támogatják. Az OS rendszerszolgáltatásait több rendszerelem bonyolítja le (beolvasó, kiíró, főütemező stb.). Az OS-ben még kiterjedtebb a segédprogramok köre. Ezek közül a jobbakat és sok alkalmazói programcsomagot szintén csak bérelni lehet. Az ESZR felhasználók támogatására hazánkban központi fejlesztési alapból beszerzett, nem IBM eredetű szoftverek is rendelkezésre állnak. VM/370 virtuális gépes operációs rendszer A VM/370 (Virtual Machine = virtuális gépeket emuláló) párhuzamosan több operációs rendszert is támogató, különleges időosztásos operációs rendszer, amely -- fő feladatként -- DOS/VS és OS/VS programok egyidejű használatát teszi lehetővé úgy, hogy a támogatandó operációs rendszerek számára a hardvert virtuálisan több gépre osztja fel. Az ehhez szükséges hypervisor funkciókról később lesz szó (14. fejezet). Itt megemlítendő azonban a programfejlesztést támogató CMS (Conversational Monitor System = interaktív felügyelőrendszer) szolgáltatás, amely kizárólag a VM/370 felügyelete alatt működő speciális operációs rendszer. Egyéb olyan szoftverek is vannak, amelyek csak a VM/370 szolgáltatásai mellett használhatók. A CMS és az említett további szoftvercsomagok működésekor összeköttetést lehet teremteni a VM/370 alatt futó DOS, vagy OS
operációs rendszerek között, vagy a VTAM/SNA (System Network Architecture = számítógép-hálózati architektúra) kapcsolaton át egy egész számítógép-hálózattal. 2.4.2. AZ OS MUNKAVEZÉRLŐ NYELVÉNEK ALAPELEMEI Az OS munkavezérlő nyelve három fő és néhány kiegészítő un. JCL-utasításra épül. A fő JCL-utasítások: * JOB utasítás, a munka alapinformációinak definiálására; * EXEC utasítás, a hívandó rutinok aktivizálására; * DD utasítás, a használandó adatállományok megadására. A munkákról -- mint korábban említettük -- feltételezzük, hogy azok több lépésből állnak. Ennek megfelelően minden munkát egy JOB utasítás vezet be, amelyet egy vagy több (pontosabban lépésenként egy-egy) EXEC utasítás, majd lépésenként változó számú (adatállományonként egy vagy több) DD utasítás követ (ha egyáltalán kell DD utasítás). Az OS JCL-utasítások általános alakja öt mezőből áll: 1. 2. 3. 4. 5. mező //
<űr><művelet><űr><űr><megjegyzés> Az első mező fix hosszúságú, és a benne kódolandó két perjel a JCL-utasítások megkülönböztetésére (azonosítására) szolgál. A rendszerolvasó parancsértelmezője ennek alapján veszi észre őket, ami egyben korlátozást is jelent, mert emiatt adat és programkártyák normálisan nem kezdődhetnek ezzel a két karakterrel. A második a névmező, amely változó hosszúságú, hossza 1 -- 8 karakter lehet. Értelmezése műveletenként változó. A JOB parancsban a munkanevet, az EXEC parancsban a lépésnevet, a DD parancsban a DD-nevet adja meg. A további mezőket űrmezők választják el egymástól, amelyek egy vagy több szóközből (IBM terminológiával "SPACE" vagy "BLANK") állnak. A harmadik a műveletmező, amely ugyancsak változó hosszúságú, és tartalma a már említett JOB, EXEC, DD, vagy más műveleti kulcsszó lehet. A negyedik az operandusmező, amely szintén változó hosszúságú, és az egymástól vesszővel elválasztott műveleti paraméterek megadására szolgál. Az ötödik a magyarázatmező, amely az operandusmezőt követő űrmező után a rekord végéig tart. Megjegyzendő, hogy a JCL-utasítások írási szabályait a lyukkártya-technikához igazították, minthogy az IBM 360-as sorozat megjelenésekor döntően ezt az adathordozót használták a JCL-utasítások megadására. A lyukkártyák beosztása a következő: 1..... .16...
71. 72. 73.-80. >
Az utasításmező tehát az 1.-71. pozíciókra terjed ki. Ebben írhatók a JCL-utasítások mezői, ha elférnek. Ha az utasítás operandusai nem férnek el egy utasításmezőben, vagy egyes paramétereket külön kártyán szeretnénk megadni -- a jobb áttekinthetőség, vagy a könnyebb módosíthatóság miatt, -- akkor a 72. pozíción folytatásjelet (FJ) kell megadni, ami szóköztől különböző bármely karakter lehet. A parancs szétvágása a paramétereket elválasztó vesszőknél lehetséges úgy, hogy a vessző után egy űrmezőt alkalmazunk. Az űrmező után a 71. pozícióig írhatunk kommentárt is. A parancs folytatását valahol a következő kártya 2.-16. oszlopán kell elkezdeni. Az utolsó rekord FJ mezejét üresen kell hagyni (tipikus hibalehetőség a JCL-utasítások írásakor!). A sorvégi megjegyzések írásánál is vigyázni kell, nehogy a 72. pozícióra szóköztől eltérő karakter kerüljön (ez is jellegzetes JCL-hiba), mert az értelmező a következő kártyát folytatásként írt kommentárként értelmezi(!). A
73-76. kártyapozíciók -- opcionálisan -- az úgynevezett kártyacsomag azonosító (Az), a 77.-80. (vagy együtt a 73.-80.) pozíciók a kártyasorszám (Ssz) tárolására szolgálnak. Interaktív környezetben írt munkacsomagoknál sem lehet eltekinteni ezektől a fő szabályoktól, csak az űrmezőkben tabulátor karaktert is használhatunk. Az utolsó tabulátorpozíción ilyenkor folytatásjel található, mert interaktív környezetben a pozicionálás körülményes, és egyértelműen feleslegesnek érezzük. (Ezekből a borzasztó szabályokból talán érezhető, mennyire visszahúzó hatása van egy régi technológiai bázis folyamatos fenntartásának!) A JCL-utasításoknak vannak kötelező és választható (opcionális) mezői és paraméterei. A szabályok műveletkódonként eltérőek. Így például minden utasításban kötelező a műveletmező megadása. A JOB és az EXEC utasításban kötelező a címkemező, de máshol opcionális. Az elhagyott (opcionális) paraméterek úgynevezett alapértelmezett értéket kapnak. Ezek vagy fix értékek, vagy az OS generálásakor (tehát első üzembeállításakor) a rendszerprogramozó állíthatja be őket. Némelyek operátori paranccsal is módosíthatók, azaz hozzáhangolhatók a pillanatnyi üzemi viszonyokhoz. A számítóközpontok mindig tájékoztatni szokták alkalmazóikat a náluk beállított értékekről, illetve a megkövetelt előírásokról. Ha ezeket valaki nem tartja be, akkor azt az OS valamilyen módon bünteti (a munkát kidobja, vagy nagyon lassan halad stb.). A következőkben a műveletkódokat és a betű szerint írandó utasításrészeket nagybetűkkel, a konkrétan megadandó adatok fogalmát pedig kisbetűkkel írjuk. A feltételesen írható paraméterek szögletes zárójelbe kerülnek. A kiválasztandó paramétereket kapcsos zárójelek között soroljuk fel, és az egyes tagokat függőleges vonal választja el. (Ezek a szokásos metanyelvi szabályok.) A JOB utasítás A JOB utasítás egy munkaköteg elejét jelzi és azonosítja. Néhány jellemző paraméterével az alábbi módon kódoljuk: //job-név JOB <paraméterek> A paraméterek OS verziónként változóak, és azokon belül is egyesek kötelezőek, mások pedig nem. Itt a következőket mutatjuk be: [számlázási információk] [programozónév] [CLASS=munkaosztály] [MSGCLASS=kimenetosztály] [MSGLEVEL=([0│1│2│[,0│1])] [PRTY=prioritás] [TIME=(percek,másodpercek)] [REGION=nK] A számlázási információk az üzemeltetésnek kellenek. Ebből tudják, hogy milyen munkaszámra számolhatják el a teljesített számítógépes szolgáltatások díját. Megadási módjuk erősen számítóközpont-függő. Ugyanakkor a programozónévre inkább a felhasználóknak van szüksége, hogy az eredménylistákat könnyebben megtalálják. Az alkalmazó (vagy a programozó) a munkájához erőforrásokat szeretne lekötni. Az OS-ben az üzemeltetés A,B,C stb-vel jelölt munkaosztályokat jelöl ki, amelyekhez a rendszergeneráláskor erőforrásokat rendelnek (például tárigény, időigény). (Ez is számítóközpont-függő, a konkrét számítógépen az üzemeltetés tud tájékoztatni a helyi beállításokról.) Az alkalmazónak kell kiválasztani azt az osztályt, amely elegendő erőforrást biztosít munkája teljesítéséhez. Az operátorok az osztályok erőforrásait módosíthatják, és a munkákat is átsorolhatják más osztályba, ha az üzemmenet úgy kívánja. Ez igen rugalmas rendszerhasználatot eredményez.
Az OS-ben a nyomtatást igénylő üzenetek -- és az eredménylisták -- konkrét perifériái (többnyire sornyomtatók) is osztályokhoz vannak hozzárendelve (szoftver SPOOLING). Ezek a kimenetosztályok. Így szükség lehet a kimenetosztály megadására. Az MSGLEVEL paraméterrel szabályozhatjuk, hogy az összes rendszerüzenetre kíváncsiak vagyunk-e, vagy csak kevesebbre, sőt majdnem semmire. Rendszerint nem kell megadnunk, mert a rendszergeneráláskor logikus -- vagy a számítóközpontban előírt -- értékre állítják be. A paraméterek konkrét jelentésére itt nem térünk ki. A PRTY paraméterrel kérhetünk a munkaosztályra rendszergeneráláskor beállított sürgősségi (prioritási) értéktől eltérő értéket. Az OS-ben a magasabb számértékek jelentik a sürgősebb munkát. A számítóközpontok általában tiltják a PRTY használatát, mert téves adat megadása esetén a munka nagyon megzavarhatja az üzemmenetet! A TIME paraméterrel korlátozhatjuk a program futásához felhasználható maximális CPU-időt. Ez programbelövésnél hasznos, mert az OS spoolingos, multiprogramozott környezetében nehéz csak úgy észrevenni egy végtelen ciklusba esett programot. Munkaosztályonként itt is ésszerű értékeket szoktak beállítani rendszergeneráláskor, de erre a paraméterre oda kell figyelni! A REGION paraméterrel az operációs rendszernek előre jelezhetjük, hogy a munkánk elvégzéséhez mekkora tárméretre lesz szükség. Ez az ütemezőt befolyásolja majd, amikor arról dönt, hogy be tudja-e ütemezni a munkát végrehajtásra. Amíg nincs elég tár, addig a munkát várakoztatja. Jellemző, hogy ezt a paramétert csak a dinamikusabb erőforrás gazdálkodást megvalósító MVT verziók használják, de azoknál megadása kötelező is. A paraméterek jelentésének részleteiről és a további paraméterekről az irodalomban, de leginkább a konkrét installáció gépkönyveiben és üzemeltetési utasításaiban érdemes tájékozódni. Az EXEC utasítás Az EXEC utasítás egy részfeladat megoldásához használandó program vagy ún. JCL-eljárás behívására és indítóparamétereinek megadására szolgál. Kódolása: //lépésnév EXEC <paraméterek> <megjegyzés> Az EXEC utasítás paraméterezése is erősen függ az OS verzióktól, és ezek közül is csak néhányat tudunk megvizsgálni futólag. Tipikus EXEC paraméterek: {PGM=programnév │ [PROC=]eljárásnév} [COND(feltétel)] [DPRTY=diszpécserprioritás] [PARM=programparaméterek szövege] [REGION=(érték0 K,érték1 K)] [TIME=(percek,másodpercek)]
(kötelező és első!)
Egy EXEC utasítással vagy egy bináris programot (PGM paraméter), vagy egy JCL-eljárást lehet aktivizálni, amely úgynevezett eljáráskönyvtárban található (PROC paraméter). Az eljáráskönyvtárban -- mint várható -- rutinfeladatokhoz könnyen paraméterezhető, szöveg alakú JCL-utasítások vannak. A COND paraméter, amely a JOB utasításban is szerepelhet, feltételtől teszi függővé a munkalépés végrehajtását. Így szabályozni lehet, hogy a köteg olyan munkalépései, amelyek az előző lépések helytelen működése következtében szintén rosszul működnének, ne hajtódjanak végre. Az operációs rendszer nyilvántartja az egyes lépések úgynevezett válaszkódját, amelyet az utoljára futó program hagy hátra. Ha ez az érték nulla, akkor nem volt hiba, egyébként a válaszkód értékétől függően súlyos vagy kevésbé súlyos a hiba. A COND feltételben a válaszkódokat tudjuk megvizsgálni, és ha azok nem megfelelők, akkor a munkalépés
végrehajtását megakadályozhatjuk, nehogy hibát hibára halmozzunk. A feltételek konkrét megadási módját itt nem részletezzük, de megjegyezzük, hogy az egy kicsit nyakatekert. Más korai munkavezérlő nyelvekre is jellemző az ilyen, az operátori nyelvek kapcsán már említett, gyermekbetegség, hogy nem ügyeltek a nyelv kényelmes használhatóságára. A DPRTY paraméter a JOB utasítás PRTY paraméteréhez hasonló. Vele korlátozott mértékben szabályozhatjuk a prioritást. Értéke hozzáadódik a munkaosztály alapértelmezés szerinti prioritásához. Ezzel a lassúbb munkalépéseket kicsit meggyorsíthatjuk. A PARM paraméterrel szövegfüzért adhatunk át a hívott programnak, amely ennek függvényében választhatja meg működésmódját. A REGION paraméter az egész kötegre érvényes hatállyal a JOB utasításban is megadható, de főként lépésenként dönthető el a pontos értéke, a program futásához igényelt valós és virtuális tárigény (partíció, régió) megadására szolgál. Az EXEC parancsnak további kiterjedt paraméterezése van, amely szintén függ az OS verzióitól. A részletekért ismét a kézikönyvekre utalunk. A DD utasítás A DD utasítás az adatállományok fizikai adathordozójának definiálására szolgál. Paraméterezése igen bonyolult. Ez a programok perifériafüggetlenségének ára. Kódolása: // DD <paraméterek> <megjegyzés> Ebben a fejezetben csak a legegyszerűbb paraméterekre térünk ki. Az OS-ben ugyanis igen könnyű olyan programok munkacsomagját megírni, amelyeknek egy szekvenciális bemenete és egy listakimenete van. Ilyenkor a bemenő adatokat közvetlen a kötegben helyezik el. Az ilyen munkakötegek szerkezete: <JOB utasítás> <EXEC utasítás> ... /* adatszeparátor kártya // NULL JCL-utasítás, kötegvége jel A bemenetet az úgynevezett szabványos bemenetről várjuk. Ennek speciális DD neve van: SYSIN. Azt, hogy az adatok a kötegben közvetlenül a DD utasítás után állnak, a következő paraméterezéssel lehet megadni: //SYSIN
DD
*
Ebben a DD utasításban a * egy úgynevezett pozícionális paraméter. A pozícionális paramétereket mindig előírt sorrendben kell megadni. Ezektől eltérően a KULCSSZÓ=valami alakú kulcsszavas paramétereket, tetszőleges sorrendben is megadhatjuk, mert a kulcsszó mindig pontosan mutatja, hogy melyik paraméternek adunk értéket. Ha a bemenő adatok között JCL-utasítások is vannak, akkor * helyett DATA paramétert kell megadni.
DUMMY paraméter megadásával üres bemenetet is generálhatunk. Ilyenkor a program állománynyitáskor azonnal EOF (End of file = adatok vége) feltételt talál. Így egy programot adatok nélkül is kipróbálhatunk (ha ennek egyáltalán van értelme). TSO állományoknál DYNAM (dinamikus) paramétert kell használni, mert a TSO-ban még később történik az állomány-hozzárendelés, mint kötegelt esetben. Munkacsomag íráskor még nem is lehet tudni, hol lesz az állomány, ez csak végrehajtás közben derül ki. A DD utasításnak ez az egyetlen pozícionális paramétere. Használatakor a kulcsszavas paraméterek előtt kell megadni. A következő tanulságos DD utasítás a kimenetet leíró utasítás. Az OS filozófiája szerint a listák az úgynevezett szabványos kimenetre kerülnek. A szabványos kimenetnek szintén speciális DD-neve van: SYSPRINT. A szokásos DD utasítás: //SYSPRINT DD SYSOUT=kimenetosztály Itt lehet megadni, hogy a lista melyik kimenetosztályba kerüljön. A kimenetosztályok tulajdonságait az üzemeltetés szokta meghatározni, mint arról korábban a JOB utasításnál már volt szó. Rendszerint különböző típusú sornyomtatókat vagy a nyomtatókon használatos speciális beállításokat (más vezérlőszalagot, 1-2-4 példányos papírt stb.) jelentenek. Különleges kimenetosztály terminálok esetében az R (remote = távoli) osztály, ha a felhasználó a termináljára kéri vissza az eredményt (egy számítóközpont persze kijelölhet más betűt is ennek az osztálynak!). A lehetséges kimenet-osztályokról mindig a szolgáltatást nyújtó számítóközpontban kell tájékozódni. A DD utasítás további paramétereivel a logikai adatállományokhoz konkrét fizikai adathordozón elhelyezett adatállományokat kapcsolhatunk hozzá, és állományvédelmi rendszabályokat írhatunk elő, de ezekkel kapcsolatban ismét a kézikönyvekre utalunk, illetve, az OS vezérlőtáblázatai kapcsán a 6. fejezetben még lesz róluk szó. 2.4.3. Az IBM PC operációs rendszerei Az IBM PC-ken négy (természetesen lemezrezidens) operációs rendszer terjed igazán: * * * *
PC--DOS/MS--DOS, amely egyfelhasználós, interaktív, monoprogramozott operációs rendszer; CP/M86, amely szintén egyfelhasználós interaktív, monoprogramozott operációs rendszer; XENIX, amely többfelhasználós, interaktív, multiprogramozható operációs rendszer (UNIX); OS/2, amely egyfelhasználós, interaktív, multiprogramozható operációs rendszer (az MS-DOS vonal folytatása).
Ezek közül legnagyobb teret a PC--DOS/MS--DOS páros nyert, és világcsúcsszámba menő, becsülhetően (1988-ban) tízmilliós, installációs számával valószínűleg hosszú távon is verhetetlennek bizonyul. A siker az egyszerű alkalmazói interfésznek köszönhető. Elnevezésükről annyit megemlítünk, hogy a PC--DOS az eredeti IBM PC-k operációs rendszere, amelyektől eltérő névvel különböztették meg a másolatgépek (klónok) operációs rendszereit, licensz okok miatt. Végül mindkét változat a Microsoft cégtől ered, de a PC--DOS-nak extra ROM-támogatása is van. A továbbiakban a rövidség kedvéért az elterjedt DOS elnevezést használjuk. A (közben sikertelenné vált!) PS/2 modellekkel az IBM új operációs rendszert akart bevezetni (OS/2), ami a DOS-hoz képest annyit javított a helyzeten, hogy kihasználja a privilegizált üzemmódokkal rendelkező INTEL mikroprocesszorok lehetőségeit, például lehetővé teszi védelmi rendszer kiépítését, és igazi multiprogramozást enged meg egyetlen felhasználónak (multitasking). Az IBM PC-ken igazi (többfelhasználós) multiprogramozott környezetet csak a UNIX változatok biztosítanak. Ezek közül legelterjedtebb (volt!) a Microsoft(!) cég XENIX operációs rendszere, és ennek verziói (XENIX SYSTEM V., SCO XENIX, XENIX/386), de valószínű, hogy az IBM a RISC gépére adaptált UNIX változatát, az AIX-ot némi módosításokkal át fogja vinni a PS/2 sorozat nagyobb modelljeire. Mi itt célszerűen csak a DOS-t mutatjuk be, amely paramétereivel legjobban hozzáidomult a hardver adta korlátokhoz (és a potenciális alkalmazók intelligencia szintjéhez??). Tény, hogy a UNIX-ok többet tudnak, de ennek ára is van: rengeteg erőforrást elvesznek az amúgy is szűk konfigurációtól, az alkalmazóktól túl sok számítógépes ismeretet
követelnek, ráadásul nem eléggé "bolondbiztos" üzemet biztosítanak (az állományrendszer megsérülése többnyire csak egy jó "superuser" rendelkezésre állása esetén élhető túl!). A DOS-ba, mint majd látjuk, szerencsére igen sok jót átmentettek a UNIX-ból, ami messzebbre helyezi azt a szituációt, amikor tényleg a UNIX-hoz kell folyamodni a PC-ken (azóta igen!). A DOS rendszeradminisztrációs funkciók egyrészt ROM-ban (PC-DOS), másrészt mágneslemezen találhatók. A DOS indítása bekapcsolás, vagy RESET után a ROM indítórutinjának automatikus behívásával történik. A betöltés során inicializálódnak a RAM-tár rendszerterületei, majd az A: lemezegységről, vagy ha abban nincs lemez, a C: fixlemezegységről behívódnak az IBMBIO.COM, IBMDOS.COM rendszeradminisztrációs funkciókat támogató programok. Ezután behívódik a COMMAND.COM parancsértelmező program, amely a parancsnyelvet fogadja, és jobbára az alkalmazói támogatás funkcióit biztosítja. A COMMAND.COM (a DOS 3.30-as verzióig) eredendően egy sororientált parancsértelmező, amely írógépes terminál típusú interfészt biztosít. Ezt a szabványos parancsértelmezőt azonban le lehet cserélni, és már terjednek helyette a különböző képernyő-orientált, menüvezérléses parancsértelmezők (amelyeket videoshelleknek szokás nevezni -- NC). Ezek közül a legfejlettebb a Microsoft WINDOWS, amely mellesleg multiprogramozást (multitaskingot) is lehetővé tesz egy felhasználónak az OS/2-höz hasonlóan, de nem támaszkodik az INTEL 80286 védelmi rendszerére (azóta a 4.0-val már a DOS-ban is megjelent a képernyős parancsértelmező). Mi az eredeti parancsértelmezőt vizsgáljuk meg, mert célunk az interaktív parancsnyelvi lehetőségek bemutatása. (A képernyős kapcsolat bemutatása jelenleg egyébként is meghaladná könyvünk kivitelezési lehetőségeit.) A DOS parancsértelmezője kétféle, belső és külső parancsot tud értelmezni, mint erről korábban a bináris programkönyvtárak kapcsán már volt szó. A belső parancsok algoritmusa a parancsértelmezőbe van beépítve. A külső parancsok értelmezőprogramját mágneslemezen kell tárolni, DOS-állományként, amelyek elnevezésére a CP/M operációs rendszerből örökölt szabályok érvényesek: maximálisan nyolc karakteres név, és egy ponttal (.) elválasztva maximálisan három karakteres névkiterjesztés (más néven minősítés, típusnév) adható meg. A kiterjesztés megadásával jelezhető a parancsértelmezőnek, hogy a hívandó értelmezőprogram melyik típusba tartozik. A DOS-ban három ilyen programtípus létezik, amelyek kiterjesztési kódjaikkal megadva a következők: * COM típusú bináris programok, * EXE típusú bináris programok és * BAT típusú szöveges parancsállományok. A bináris programokat a parancsértelmező betölti a tárba, és elindítja, a szöveges parancsállományok szövegét pedig elkezdi értelmezni úgy, mintha azokat a billentyűzetről adták volna meg. A belső parancsok között vannak olyanok is, amelyek csak parancsállományból használhatók, mert interaktív végrehajtásuk értelmetlen. A DOS-nak nincs kifejezett programfejlesztő alrendszere, interaktív természete mégis rendkívül kedvező környezetet nyújt a programfejlesztéshez. Minthogy a programozási nyelvek fordítói külső parancsokként aktivizálhatók, és bináris könyvtárakban tarthatók, gyakorlatilag minden programozási nyelv hozzáférhető. A programfejlesztési támogatás az operációs rendszerrel támogatott hardver nyomkövetési lehetőséget is biztosítja (03:Break megszakítás és DEBUG.COM külső parancs monitor). Kiterjedt azonban a nyelvi interpreterek használata, amelyek több szimbolikus nyomkövetési lehetőséget adnak. Újabban vannak szövegszerkesztővel integrált programfejlesztő eszközök is (pl.: TURBO PASCAL, --C, --PROLOG). Egyre több programgenerátort tartalmazó nyelvi rendszer létezik. Velük típusfeladatokra készíthetünk programokat vagy programrészeket, interaktív üzemmódban. Ilyenek az ernyőképtervezők, amelyekkel a képi formátum explicite adható meg, majd generálják a képet az adott nyelven elővarázsoló programot (pl.: PROFESSIONAL COBOL, dBASE III PLUS). A DOS adatkezelése részben a CP/M már említett állomány-elnevezési rendszerén, részben -- a ma élő verziókban, -- a UNIX hierarchikus állományszervezésén alapul. A CP/M szabályok az állományok elnevezésére adnak szabályokat (maximum 8 karakteres név és 3 karakteres kiterjesztési kód adható meg, mint
fentebb már volt róla szó). Az állományokról a CP/M annak idején feltételezte, hogy azok mágneslemezen helyezkednek el, és szervezésük szekvenciális. Az állományok tartalmáról magától semmit nem tételezett fel, de a kiterjesztési kóddal megadhatjuk, hogy milyen típusú adatokat tárolunk az állományokban. A CP/M-et, és ebből a szempontból jogutódját, a DOS-t csak a külső parancsok érdeklik. A további állománytípusok értelmezése a fordítóprogramok és az alkalmazói programok feladata. Ezek a parancsoknál emlegetett .COM, .EXE és .BAT kiterjesztéstípusokon túl egy sereg más kódot is alkalmaznak (pl. .PAS = PASCAL kód, .TXT = ASCII szöveg). A DOS használja még a .SYS kiterjesztést rendszerparaméterek és speciális rendszerelemek megjelölésére. A hardverhez természetesen nemcsak egyetlen lemezegység csatolható. Ezeket a DOS-ban szintén CP/M stílusban különböztetjük meg. A lemezegységek elnevezésére az ABC betűit használjuk a név előtt, a névtől kettősponttal (:) elválasztva. Ez az egységazonosító. Így a DOS állományok teljesebb elnevezése az alábbi szerkezetű: [<egységazonosító>:]<állománynév>[.] Mind a CP/M-ben, mind a DOS-ban van szimbolikus neve a nem mágneslemezes perifériáknak is. Ezek többkarakteres nevek, és szintén kettőspontot szoktak tenni utánuk. Az ilyen szimbólumokat nem használhatjuk állománynévként sem (fenntartott nevek!): CON, AUX, COM1, COM2, LPT1, LPT2, PRN, NUL stb. Az állományok elnevezésén túl fontos fogalom a DOS-ban a katalógusok illetve könyvtárak fogalma. A CP/Mben, -- és eredetileg a DOS-ban is, -- minden mágneslemeznek csak egyetlen katalógusa volt. A CP/M-ben azonban egy lemezen több, maximálisan 255 különböző felhasználó adatait is meg lehetett különböztetni az úgynevezett USER azonosítóval. Az éppen aktuális user azonosítót egy paranccsal lehetett beállítani (induláskor a 0-s USER adataival lehetett dolgozni). Így az egyes felhasználók adatai egyszerűen elkülöníthetők, minden felhasználó csak a saját adatait látja. A helyzet akkor bonyolult, ha különböző USERazonosítójú állományokat kell használni egy feldolgozáshoz. Valószínűleg az ebből eredő bonyodalmak miatt nem vették át ezt a módszert a DOS-ba. A DOS-ban egy mágneslemezt kényelmesen csak egy felhasználó tudott kezelni, de neki is gondot okozott, ha különböző munkákhoz tartozó állományai keveredtek ugyanazon a lemezen. A problémát a UNIX operációs rendszer hierarchikus katalógusrendszerének mintájára oldották meg, amikor az IBM PC/XT megjelent az 5 Mbájtos fixlemezével. Ebben a helyzetben ugyanis tarthatatlanná vált, hogy csak nagyon korlátozott számú állomány lehet a mágneslemezen, továbbá sürgetően felmerült a különböző alkalmazókhoz és alkalmazásokhoz tartozó állományok szeparálhatóságának igénye. A UNIX egy mágneses periférián úgynevezett állományrendszer(eke)t (angolul: file system) tételez fel. Minden állományrendszernek van egy kiinduló katalógusa, amit gyökérkatalógusnak (angolul: root directory) neveznek. A gyökérkatalógusban szerepelhetnek UNIX állományok (sima vagy speciális állományok) és a gyökérből elágazó alkatalógusok leírásai, amelyekben szintén lehetnek további állományleírások vagy alkatalógus leírások stb. Ez egy fordított fára emlékeztető, több szintű hierarchikus alakzat: 0. szint 1. szint 3. szint
G Y Ö K É / | kt1 á11 / | / á11 á12 kt21
R \ kt2 | \ á21 kt22
kt= (al)katalógus á= adatállomány
2.3. ábra. Az MS--DOS hierarchikus katalógusrendszere A DOS-ban a mágneslemezeken ugyanilyen állományszerkezet kezelését valósították meg. A gyökérkatalógust nevezik még alapkatalógusnak, illetve főkönyvtárnak (a DOS kezelési utasítás idétlen félrefordításából eredően!), az alkatalógusokat pedig alkönyvtáraknak. A könyvtárak használata megköveteli, hogy az állomány azonosításához megadjuk az őt tartalmazó könyvtár azonosítóját is. A főkönyvtár azonosítására a DOS-ban a \ (backslash = fordított perjel) karaktert használjuk (A UNIX-ban normál perjelet kell használni. Az
eltérés oka az, hogy a CP/M nyomdokain járó DOS a normál perjelet másra használta el. A fordított perjellel némileg sikerült megőrizni a hasonlóságot.) Egy állomány pontos leírásához a gyökérből kiindulva végig kell járni az alkönyvtárakat, mint faágakat. Minden érintett alkönyvtár nevét \ karakterrel kell elválasztani az előző alkönyvtárnévtől. Az eléréshez így kijelölt névsorozatot útnévnek nevezzük (akár a UNIX-ban). Az útnév fogalmát is felhasználva a DOS állományok azonosítása a legáltalánosabban így fest: [<egységazonosító>:][<útnév>\]<állománynév>[.] Az útnevek megadása: [\][\]... Az útnevek megadhatók abszolút útnévvel vagy más néven teljes útnévvel. Ilyenkor az útnevet mindig a főkönyvtárból kiindulva határozzuk meg. Minden könyvtárban van azonban két különleges alkönyvtári leírás, amelyek speciális elnevezést kaptak. A ponttal (.) jelzett alkönyvtár önmagára mutat, illetve képzeletben helyettesíti az alkönyvtár teljes útnevét. Alapértelmezés szerint minden (al)könyvtári elem neve úgy értelmezett, mintha előtte volna a ".\" pont-alkönyvtárnév. Így az alkönyvtárbeli elemek nevét egyszerűen leírva közvetlen névvel hivatkozhatunk a megnevezett elemre, nem kell hosszú útnevekkel bajlódni. E konvenció bevezetése segít annak áthidalásában, hogy a DOS korábbi verziói nem kezelték az alkönyvtárakat. Ott tehát nem is merültek fel útnevek az állománynév előtt. (A UNIX-ban ugyanígy használhatók a közvetlen nevek, a DOS tehát szerencsésen ezt is örökölte.) Fontos még a kétpont (..) alkönyvtár, ami arra a könyvtárra mutat, amelyikhez az alkönyvtár a hierarchiában tartozik, ezért szülőkatalógusnak is szokás nevezni. A szülőkatalógus segítségével relatív utakat adhatunk meg a katalógusfában (pl.: ..\KT\NEV.FMT). Relatív utak megadhatók a pont-alkönyvtárból kiindulva is. Ezek mélyebb hierarchiaszinten lévő elemek azonosítására szolgálhatnak. Ilyenkor egy alkatalógust jelölő közvetlen név után kell az elemhez vezető utat megadni. Az ilyen útnevek elején nincs fordított perjel, hiszen az út nem a gyökérből indul. A relatív útnevek alkalmazása lehetővé teszi, hogy egy feldolgozás állományait a katalógusfa bármely ágához csatlakoztathassuk, és emellett -- relatív utakon át, -- minden szükséges állományt elérjünk. Nem kell ismerni az abszolút útneveket. (Ez is UNIX örökség.) A DOS fent elemzett alkönyvtári rendszere maximálisan alkalmas különböző munkákhoz tartozó adatok szétválasztására, akár több alkalmazó feladatairól, akár egy alkalmazó különböző feladatairól van szó. 2.4.4. ALAPVETŐ DOS PARANCSOK A DOS tökéletes alkalmazói szintű használatához maximálisan 70 parancsot és az adatállományok hierarchiáját kell megismerni, ami nem sok erőfeszítést igényel. Ráadásul alig néhány parancs ismeretével már elég jól el lehet boldogulni. Először ezt a néhányat próbáljuk kiválasztani. A DOS-t valamilyen mágneslemezes perifériáról lehet indítani. Ez lehet az "A" betűvel jelölt első floppy lemezmeghajtó vagy a "C" fix (Winchester) lemezegység. Az indításhoz bekapcsolás előtt, ha nincs fixlemez, vagy ha a gépet az "A" egységből akarjuk indítani (pl. más DOS változat kell), be kell tenni az "A" meghajtóba a DOS rendszerlemezt. (Ha nincs fixlemez, és bekapcsoláskor az "A" egységben sincs lemez, akkor az IBM PC ROM-BASIC interaktív fejlesztőrendszere indul el, de ezzel most nem foglalkozunk.) Amikor a DOS elindul, akkor a 3.30 előtti verziókban kéri a dátumot majd az időpontot. Ezeket olyan alakban kell megadni, ahogy a képernyőn megjelenik. Két eset lehetséges. Vagy van beépített óra a gépben, és akkor csak helyesbítésre van szükség, vagy nincs, és ekkor nekünk kell pótolni a friss dátumot és időpontot, különben egy előre beállított konstans időpont jelenik meg. A beállítást célszerű elvégezni, mert a DOS a beállított dátum és óraértékeket használja a keletkező állományok időpont adatában. Ha nem állítjuk be az időpontot, akkor nem
tudjuk kézben tartani állományaink időrendiségét. A beépített óra nem áll le, csak ha az eleme kimerül (gyakorlatilag sose). Előfordul azonban, hogy késik vagy siet. Az induláskor ezt tudjuk korrigálni. Miután a dátumot és az időpontot megadtuk, egy szoftver óra kezd működni, amely addig jár, amíg a gépet ki nem kapcsoljuk. A dátum és az időpont megadása után a rendszergazda által beállított, és az adott gépi konfigurációra érvényes hasznos információk szoktak megjelenni a képernyőn (ha van ilyen), majd végre megkapjuk a "vezérlést". Erről a rendszer az úgynevezett prompttal értesít bennünket. Ez alapesetben egy nagybetű (A,C), és egy > jel. A betű azt mutatja, hogy melyik a rezidens lemezegység, azaz melyik lemezmeghajtóval dolgozik az operációs rendszer (ez CP/M hagyomány). A nagyobb (>) jel azt jelzi, hogy a parancsértelmező program a parancsainkra vár. Parancsainkat a billentyűzetről adhatjuk be, minthogy a DOS-nak, mint már kielemeztük, sororientált parancsértelmezője van. Lemez-tartalomjegyzék kilistázása -- DIR Indulásképpen az a legjobb, ha körülnézünk. Amíg nincs kellő gyakorlatunk, ez folyamatosan ajánlható. A DIR (Directory listing = al/katalógus, al/könyvtárlistázó) paranccsal induláskor kilistázhatjuk annak a lemeznek a katalógusát, amelyik a rezidens meghajtón van. Normál esetben ez a gyökérkatalógus. A parancs megadása a parancs nevének leírásával történik (elől a prompt van a sorban!): A>
DIR
A parancsot mindig az ENTER gombbal kell befejezni, ami azt jelzi a parancsértelmezőnek, hogy elkezdheti a parancsunk végrehajtását. Amíg az ENTER-t le nem ütjük, nem történik semmi(!). Ugyanakkor, amíg nem ütjük le, addig javíthatjuk a rosszul gépelt betűket. A Backspace (törlőkarakter) billentyű leütésével a kurzor (szabványos nevén helyőr, fizikailag a képernyőn egy futó folt) előtt álló betűt kitörölhetjük, és beírhatjuk a helyes karaktert. Ez tipikus sororientált parancsszerkesztési lehetőség az interaktív rendszerekben. Elvei a telex terminálokon eredetileg meglévő korlátozásokon alapulnak (nem volt képernyő, nem volt kurzor, a hibás karakterig vissza kellett menni a törléssel stb.). Ha több lemezegység van, akkor a nem rezidens meghajtóba helyezett lemezek tartalomjegyzékét is megnézhetjük. Például a "B" meghajtóba helyezett lemez esetében meg kell nevezni a meghajtót a DIR parancs paraméterlistáján (a parancsnévtől egy vagy néhány szóközzel elválasztva!): A>
DIR
B:
Figyeljük meg, hogy az egységazonosító betű után kettőspontot kell írni! (Az interaktív parancsnyelvekben jellemző a különféle elválasztójelek használata a parancsok megadásánál, ami a munkavezérlő nyelvekben a fixmezős beosztás miatt kevésbé merült fel.) A fenti parancs után a katalógus körülbelül így jelenik meg: Volume in drive B has no label Directory of B:\ ASM AUTOEXEC COMMAND CONFIG GREATING
BAT COM SYS TXT
321 23791 122 6378
87-07-10 87-05-16 85-12-30 87-07-20 87-08-30
12.44 21.10 12.00 09.13 14.57
A listán kétféle név lehet: egy konkrét adatállomány, vagy egy alkatalógus neve. Fenti katalóguslistánk éppen alkatalógus-névvel indul (ASM). Most persze kíváncsiságunk növekedhet. Mi van az ASM alkatalógusban? Ezt megtudhatjuk, ha a lemezegység azonosító mellett megadjuk a látni kívánt katalógus (út)nevét is: A>
DIR
B:\ASM
Az útnevek megadásával az egész lemezt "feltérképezhetjük". A katalóguslistában az állományok neve mellett szerepel a hárombetűs minősítés (kiterjesztési kód), az állományhoz tartozó bájtok száma és az utolsó módosítás dátuma. A katalógusokat szelektált módon is ki lehet listázni. A DOS ugyanis tud kezelni névmintákat. A tipikus probléma az, hogy keresünk valamit, de a nevére nem emlékszünk pontosan. Például csak az első betűjét tudjuk. Ilyenkor a következő parancs használható: A>
DIR
B:\ASM\J*.*
Ennek hatására megjelenik az összes J betűvel kezdődő név, akármi a minősítése. A * ugyanis azt jelöli, hogy ott a névben akármilyen hosszú akármilyen szöveg lehet (persze 8 illetve 3 karakterig). Hasonlóan használható mintakarakter a kérdőjel (?). Ennek jelentése az, hogy abban a pozícióban akármi lehet, például: A>
DIR
B:\ASM\?.*
A parancs hatására megjelenik az összes egybetűs név, akármilyen a minősítése. A parancs használata kapcsán vegyük észre, hogy: * a parancsokban a rezidens egység neve nem kötelező; * az úgynevezett munkakatalógus nevét, ahol éppen dolgozunk, szintén nem kell megadni (ez a pont(.\)!). A rezidens egységet könnyen megváltoztathatjuk, egyszerűen megadjuk az új rezidens egység nevét (kettősponttal!): A> C>
C:
A parancs hatására a prompt mutatja, hogy már a "C" egység a rezidens egység. Ekkor egy másik lemez katalógusába kerülünk át, tehát ott lesz a munkakatalógus. A munkakatalógus azonban nemcsak a lemezek gyökérkatalógusa lehet. Bármelyik egységen a katalógus hierarchia bármely pontjára áthelyezhetjük, de ehhez szükség van egy újabb parancsra. Katalógusváltás -- CHDIR vagy CD A CHDIR vagy rövidítve CD paranccsal elmozdíthatjuk a munkakatalógust egy másik (al)katalógusba. Ez történhet abszolút útnév, teljes név vagy relatív útnév megadásával. A lényeg az, hogy a korábbi munkakatalógusban a név értelmes legyen. A fenti mintát folytatva, a "B"-n el akarunk jutni a gyökérből az ASM katalógusba: C> B>
B: CHDIR
ASM
Mint látható, a közvetlen (tehát a .\ relatív) nevet használhattuk, mert éppen a "B" gyökerében voltunk.
Figyelem! A CD parancs üres paraméterrel a pillanatnyi munkakatalógus teljes útnevét listázza ki a rezidens egység nevével együtt. Kezdetben ilyen üres paraméterű CD paranccsal célszerű ellenőrizni, hogy most hol is vagyunk. Ez a működésmód egyébként rámutat az interaktív parancsnyelvek olyan sajátosságára, hogy a paraméter nélküli parancshívásokat különleges célokra használják. Az egyik elterjedt működésmód az utolsó érvényes beállítás adatainak visszalistázása, a másik pedig a segítségnyújtás, vagyis a parancs paraméterezésének kiírása a terminál képernyőjére. Katalógusok létrehozása -- MKDIR vagy MD Jogos igény, hogy szeretnénk saját katalógust létrehozni. A fixlemezen ez alapvető érdek. A DOS nem hatékony, ha egy katalógusban túl sok név szerepel. Ez a probléma a fixlemez gyökérkatalógusában a legkellemetlenebb. Nem célszerű, ha a gyökérkatalógusban dolgozunk. Létesítsünk inkább a gyökérben egy saját katalógust, és menjünk át dolgozni abba! Persze előbb meg kell győződni, hogy milyen nevek léteznek már. Az MKDIR vagy rövidítve MD egy katalógusnevet vár, amelynek lehet hárombetűs kiterjesztése is, (de ennek használatát nem tanácsoljuk: egyes DOS változatokban a katalóguslistában a minősítés mellett nem jelenik meg a információ, mert nem fér el!): B>
MKDIR
A:\KARCSI
Meg kell tehát adni az egységszámot és a megfelelő útnevet. Szövegmegjelenítés képernyőn -- TYPE Most már jól tudunk közlekedni a katalógusfákon. Itt-ott találhatunk úgynevezett ASCII (aszkii) kódú, tehát számunkra olvasható szövegeket. Ezek minősítése .TXT vagy .DOC szokott lenni. Az ilyen állományokat rendszerint szövegszerkesztő programmal írták. Ezek tartalmát kilistázhatjuk a képernyőre a TYPE paranccsal. Például a fenti példa katalóguslistából kiindulva az indulóüzenetet újra elolvashatjuk: B>
TYPE
\GREATING.TXT
Ne felejtsük el, hogy utoljára az ASM katalógusban voltunk. Ha közben netán átmentünk volna a "C" egységre, akkor az egységazonosítót is meg kell adni: C>
TYPE
B:\GREATING.TXT
A képernyő törlése -- CLS Sokszor zavaró, hogy a képernyőn régebben kiírt szövegek is láthatók. Ilyenkor "tiszta lapot csinálhatunk" a CLS paranccsal: B>
CLS
Ha gépünkhöz van nyomtató csatlakoztatva, akkor a képernyőre listázott szövegeket nyomtatóra is kiírathatjuk. Amikor valamit ki akarunk íratni nyomtatón is, a CTRL + P billentyűkombinációt kell megnyomni (célszerű előbb a CTRL gombot lenyomni, majd e közben a P betűt leütni). Ha tovább nem kell nyomtatni, akkor megismételjük a CTRL + P kombinációt. Így a nyomtatás ki-be kapcsolható. Ez a CP/M-ből örökölt hardcopy (képernyőmásolat) technika.
Dátum és időpont lekérdezése, módosítása -- DATE, TIME A dátum, és időpont beállító parancsok lekérdezésre és beállításra is használhatók. Paraméter nélkül ezek is az utoljára beállított értéket írják vissza, de kérnek egy új adatot is. Ha ilyenkor válaszként ENTER-t adunk, nem változik meg a korábban beállított dátum illetve időpont. Tipikus hívási példa: B> TIME Current time is 21:03:35.23 Enter new time: B> Lapozott listázás szűrővel -- MORE Idegesítő, hogy a hosszabb katalógusok vagy ASCII szövegek a képernyőn egy pillanat alatt átfutnak, és nem tudjuk őket elolvasni. A listázást, a CP/M-től örökölt módon, ideiglenesen megállíthatjuk a CTRL + S billentyűkombináció megnyomásával. Ez azonban jó reflexeket igényel (pláne 1GHz-es processzorokkal!) még gyakorlott felhasználóktól is, nemhogy kezdőktől. A problémán segít a UNIX-ból átvett szűrő (FILTER = FILe TranszfeR = állománymozgatás szavakból képzett akronim (betűszó és szójáték!). A MORE program úgy működik, hogy egy átmeneti állományon keresztül elkapja az előtte álló program képernyőre szánt kimenetét, és 24 soronként meg-megállva ő listázza ki a képernyőre. Alkalmazásához a listázó program és a MORE közé a függőleges vonás (|) csővezeték (pipe) jelet kell írni (ettől ez még nem lesz igazi UNIX pipe!). Példa: A>
TYPE
ADOSZAM.TXT | MORE
Megjegyezzük, hogy a DIR parancs úgy is paraméterezhető, hogy a listázás laponként megálljon. Ezzel kapcsolatban megemlítjük, hogy a DOS parancsok a paraméterlistán úgynevezett kapcsolókat is értelmeznek. A kapcsoló paramétereket (normálállású!) perjel (/) után kell írni. Így a DIR lapozott listázása a következő paranccsal érhető el: A>
DIR
B:\ASM/P
Itt a /P kapcsoló (Paging = lapozás) jelenti a lapozási funkció bekapcsolását. (A DOS tehát a perjelet a CP/Mtől örökölt kapcsolók programozására használta fel.) Az IBM OS munkavezérlő nyelve és A DOS parancsnyelve csak illusztrációul szolgált a kötegelt és az interaktív számítógépes kommunikációs lehetőségek bemutatásához. A továbbiakban minden kommentár nélkül közlünk még egy összehasonlító táblázatot a CP/M, a UNIX és az MS--DOS operációs rendszerek különféle jellemzőiről, különös figyelemmel parancsnyelvükre (2.1. táblázat).
FUNKCIÓ Rezidens egység Katalógusváltás Katalóguslista(mintával) Új katalógus készítése Katalógus törlése Állománymásolás Átnevezés Álnévadás Állománytörlés Összehasonlítás Keresés Szövegszerkesztő Lemezformázás Lemezmásolás Új állományrendszer Felkapcsolás Lekapcsolás Lefoglalás Keresési út kijelölés Dátumszolgálat Időszolgálat Bejelentkezés Parancsértelmező* Parancsállomány Változó beállítás Változóhivatkozás Parancsvezérlés Alparancsok Átirányítás Csővezeték Szöveglistázás Nyomtatás Képernyőlapozás Prompt Lemezjavítás Nemzeti billentyűzet Opciók megadása Állományvédelem
CP/M A: (nincs, ill. USER) DIR *.TXT (nincs, ill. USER) (nincs) PIP NÉV2=NÉV1 REN NÉV2=NEV1 (nincs) ERA NÉV (nincs) (nincs) ED NÉV FORMAT A: (nincs) (nincs) (nincs) (nincs) (nincs) (nincs) (nincs) (nincs) (nincs) (nincs explicite) NÉV.CMD (nincs) $1,$2 (nincs) (nincs) (nincs) (nincs) TYPE NÉV (CTRL+P) (CTRL+S) (nincs) (nincs) (nincs) /kapcsoló... USER
UNIX (nincs) cd útnév ls -ail [a-l]f?x* mkdir név1 név2 ... rmdir név1 név2 ... cp név1 név2 mv név1 név2 ln név1 nev2 rm név1 név2 ... cmp név1 név2 grep minta utak ed név (más az alapelv!) dd if=n1 of=n2 mkfs paraméterek mount meghajtó név umount meghajtó lock név PATH=$(PATH):kat date [új] date [új] login név sh, csh, vsh állománynévXbittel Név=szöveg $(Név) van sh vagy ( ) parancs out par1. | par2. cat név1 név2 ... SPOOLING more név PR1=$ PR2=> fsck meghajtó (nincs szabvány!) -kapcsolólista rwx/ugo **
MS--DOS A: CD ÚTNÉV DIR *.?65 MD NÉV RD NÉV COPY NÉV1,NÉV2 REN NÉV1,NÉV2 (nincs) DEL NÉV COMP NÉV1,NÉV2 FIND "minta" út EDLIN NÉV FORMAT A: DISKCOPY A: B: FDISK JOIN A: C:\A JOIN A:/D (csak LAN s/w!) PATH=%PATH%;\C DATE [új] TIME [új] (csak LAN s/w) COMMAND.COM NÉV.BAT SET NÉV=szöveg %NÉV%,%3 van COMMAND EXIT PAR. OUT PAR1. | PAR2. TYPE NÉV SPOOLING TYPE | MORE PROMPT $P$G RECOVER C:útnév KEYB xx... /kapcsoló ... (csak LAN s/w)
------------------------------------------------------------------* A UNIX-ban választható és lecserélhető, MS--DOS-ban csak lecserélhető! ** r=read(olvasás),w=write(írás),x=execute(végrehajtás); u=user(tulajdonos),g=group(csoporttag),o=others(idegenek) ------------------------------------------------------------------2.1. táblázat. CP/M, UNIX és MS-DOS összehasonlító táblázat
2.5. Gyakorlatok 2.5.1.
Az operációs rendszerek funkcióit melyik három csoportba soroltuk?
2.5.2.
Mi a rendszeradminisztráció?
2.5.3.
Melyek a rendszeradminisztráció fő funkciói?
2.5.4.
Melyik program valósítja meg a rendszeradminisztrációt?
2.5.5.
Melyek a programfejlesztési támogatás fő funkciói?
2.5.6.
Melyek a szoftver projekt fejlődési lépései?
2.5.7.
Mi a szövegszerkesztő?
2.5.8.
Milyen nyelvi eszközök vannak?
2.5.9.
Mi a szerepük a programkönyvtáraknak?
2.5.10.
Mi a tárgyprogram és mi a szerepe?
2.5.11.
Mi a kapcsolatszerkesztő?
2.5.12.
Mit csinál a betöltő?
2.5.13.
Mi a nyomkövetés?
2.5.14.
Milyen módon veheti igénybe a programozó az operációs rendszer szolgáltatásait?
2.5.15.
Milyen tulajdonságai vannak az újraindítható programoknak?
2.5.16.
Mi az integrációs teszt?
2.5.17.
Melyek az alkalmazói támogatás fő funkciói?
2.5.18.
Milyen vezérlőnyelveket használnak?
2.5.19.
Mi a szerepe a segédprogramoknak?
2.5.20.
Mit nevezünk alkalmazási programoknak?
