OS 2200 - OS 2200

OS 2200

Fejlesztő	Unisys
OS család	OS 2200
Működő állapot	Jelenlegi
Forrásmodell	Zárt forrás . A legtöbb forrás licenc alatt érhető el az ügyfelek számára.
Első kiadás	1967 ; 53 évvel ezelőtt Exec 8 néven ( 1967 )
Legutolsó kiadás	18.0 / 2018. július 18 . ; 2 évvel ezelőtt ( 2018-07-18 )
Marketing cél	Vállalati / nagyszámítógépek
Frissítési módszer	Exec és néhány egyéb összetevő: Vonalszám alapú csomagolt változtatások. A legtöbb komponens: Időközi korrekciók (IC)
Csomagkezelő	PRIMUS (belső), COMUS és SOLAR (kliens és belső)
Platformok	UNIVAC 1100/2200 sorozat és Unisys ClearPath Dorado rendszerek
Kernel típus	Monolit kernel (egyedülállóan hardveres támogatással)
Alapértelmezett felhasználói felület	Parancssori felület
Engedély	Saját tulajdonú . Lejárati licenc vagy a használatért fizetett (mért) licencek fizetése
Hivatalos honlapján	OS 2200 webhely

OS 2200 az operációs rendszer a Unisys ClearPath Dorado család mainframe rendszerek. Az OS 2200 operációs rendszermagja az UNECAC 1108 Exec 8 egyenes leszármazottja . A jelenlegi és korábbi Unisys rendszerekről szóló dokumentáció és egyéb információk megtalálhatók az Unisys nyilvános támogatási weboldalán.

A gép architektúrájának és az OS 2200 operációs rendszerhez való viszonyának leírását lásd az Unisys 2200 sorozatú rendszerarchitektúrában.

Történelem

Korábban 1100 rendszer állt vissza az 1101 -hez 1951-ben, de az 1108 volt az első 1100-as számítógép, amelyet a multiprogramozás és a többprocesszoros folyamat hatékony támogatására terveztek. Ezzel az új hardverrel együtt jött az Exec 8 operációs rendszer (Executive System for 1108).

Az UNIVAC 1108 számítógépet 1964-ben jelentették be és 1965 végén szállították. Az első 1108 számítógép az Exec I és az Exec II számítógépeket használta , amelyeket az UNIVAC 1107-hez fejlesztettek ki . Az UNIVAC azonban azt tervezte, hogy az 1108 szimmetrikus többprocesszoros verzióit kínálja , legfeljebb 4 processzorral, és a korábbi operációs rendszereket (valóban alapvető monitorprogramokat ) nem erre tervezték, annak ellenére, hogy támogatták a korlátozott multiprogramozást.

Amikor az UNIVAC 1110- et 1972-ben bevezették, az operációs rendszer neve OS 1100-ra változott, hogy tükrözze a rendszerek szélesebb körének támogatását. Az OS 1100 név 1988-ig megmaradt, a Sperry 2200 sorozat bevezetésével , az 1100 sorozat folytatásaként, amikor a nevét OS 2200-ra változtatták. Azóta a 2200 sorozat Unisys ClearPath IX sorozat , majd az Unisys ClearPath Dorado sorozat, de az operációs rendszer megtartotta az OS 2200 nevet.

A cég és a terméknevek is változtak az idők során. A Saint Paul Engineering Research Associates (ERA) céget a Remington Rand Corporation vásárolta meg . Remington Rand megvásárolta a filadelfiai Eckert – Mauchly Computer Corporation-t is , amely akkor az UNIVAC számítógépet építette . A kettőt William Norris irányításával egyesítették Remington Rand UNIVAC részlegével. William Norris az ERA egyik alapítója volt, és később otthagyta Remington Randot, hogy megalapítsa a Control Data Corporation-t . A Remington Rand Corporation UNIVAC részlege a Sperry Rand Corporation UNIVAC részlegévé vált, miután a Remington Rand beolvadt a Sperry Corporation-be . Az 1970-es években a Sperry Rand egy vállalati identitás-programot indított, amelynek neve Sperry Corporation-re változott, és az összes részleg neve a Sperry-vel kezdődött, így a számítógépes rendszerek részlege Sperry UNIVAC lett. Később a divízióneveket elvetették, és minden egyszerűen Sperry lett.

Az operációs rendszer kerneljét a legtöbb Unisys és az ügyfélszemélyzet továbbra is "Exec" néven emlegeti. Amikor azonban az Unisys elkezdte kiadni a rendszer alapkiadásaként együtt tesztelt termékek csomagjait , később "ClearPath OS 2200 Release n " néven, az OS 2200 kifejezés megváltozott a rendszerkiadás teljes termékcsomagjára és másokra, például a BIS-re , aszinkron módon kiadva a Dorado hardverplatformokhoz.

1986-ban a Burroughs és a Sperry vállalatok egyesülve Unisyssé váltak (ami néhány 2200-as sorozatú ügyfél szerint sokáig az "UNIVAC továbbra is az Ön beszállítója"). Mindkét vállalat nagy mainframe termékcsaládja tovább folytatta a fejlesztést, beleértve a Burroughs MCP operációs rendszerét és a Sperry OS 2200 operációs rendszerét .

2016-ban az Unisys ingyenesen elérhetővé tette az OS2200 virtuális Microsoft Windows verzióját oktatási és szabadidős célokra.

Exec 8

Az EXEC 8 (amelyet néha EXEC VIII-nak is hívnak) az UNIVAC operációs rendszere volt, amelyet 1964-ben fejlesztettek ki az UNIVAC 1108-ra. Ez egyesítette a korábbi operációs rendszerek, az EXEC I és az EXEC II legjobb tulajdonságait , amelyeket az UNIVAC 1107- en használtak . Az EXEC 8 volt az első kereskedelemben sikeres többprocesszoros operációs rendszer. Támogatta a kötegelt , az időmegosztást és a valós idejű egyidejű vegyes munkaterheléseket . Egyetlen fájlrendszere lapos névszerkezettel rendelkezett sok dobon és orsón. Támogatta a jól fogadott tranzakció-feldolgozó rendszert is .

A korábbi rendszerek valamennyien valós módú rendszerek voltak, hardveres támogatás nélkül, a programok és az operációs rendszer védelmére és szétválasztására. Míg a korábbi rendszerekben támogatták a multiprogramozást , ez csak egy felhasználói feladat futtatására korlátozódott, több jól ismert viselkedést biztosító támogató funkcióval, például a kártyaolvasóval, a nyomtatóval és a kártya lyukasztó orsókkal .

Az Exec 8 operációs rendszert a kezdetektől fogva úgy tervezték, hogy több programozással és többprocesszoros operációs rendszer legyen, mivel az 1108-at legfeljebb négy CPU-ra tervezték. A memória és a tárhely voltak az elsődleges rendszerkorlátozások. Míg az 1100-as sorozat elképzelése szerint egy általánosabb piacot célzott meg, az extrém valós idejű feldolgozás volt az elsődleges követelmény.

Az Exec 8 specifikációit 1964 decemberéig készítették el, mint előzetes Programmers Reference Manual (felhasználói útmutató), és a munka 1965 májusában kezdődött.

Az Exec 8 valós idejű operációs rendszerként indult, korai használatával, főleg az általános tudományos és mérnöki munkában, de az üzenetváltásban, a folyamatirányításban, a szimulációban és a rakéták kilövésében is használták. Úgy tervezték, hogy olyan rendszereken fusson, amelyek gyakran csak 128 KB szavakat tartalmaznak (576 K bájt - kevesebb, mint az IBM PC XT maximális memória mérete ), és a valós idejű és a kötegelt feldolgozásra összpontosított. Míg a legkorábbi kiadási szintek 128KW-ban működtek, a későbbi kiadások növekvő funkcionalitása ezt tarthatatlanná tette, mivel nem hagyott elegendő helyet hasznos méretű programok számára. Az 1108 maximális memóriakapacitása 256 kW (1148 KB) volt, így a memória hatékony kihasználása volt a legfontosabb korlát, mivel az alapmemória volt a rendszer legdrágább része.

A tömeges tárolás 6 láb hosszú forgó dobokból állt, amelyek 256 kW-ot (az FH-432-ben) 2 MW-ig tartottak (az FH-1782-ben). A legnagyobb kapacitású tömegtároló a FASTRAND dob volt, amelynek 22 MW (99 MB) volt a kapacitása . A fájlok töredezettségével egy "fájl mentés" nevű folyamat foglalkozott, amelyet általában naponta egyszer, éjszaka hajtottak végre. Ez magában foglalta az összes fájl szalagra gördítését, a dob fájlrendszer újrakezdését, majd a fájlok visszaolvasását.

Komoly memóriakorlátok és valós idejű használat mellett a kódnak csak egy példányának a magba töltése volt szükséges. Mivel az 1108-at többfeladatos kezelésre tervezték, a rendszer teljesen "újból belépett" ( szálbiztos ). Minden újbóli belépő modul egyetlen memória "alapcímen" keresztül jutott el a programadatokhoz, amely a futtatott adatok minden példányánál eltérő volt. A végrehajtási kontextusok váltása egyetlen utasításban történhet, csupán egy másik regisztráció különböző alapcímének beállításával. A rendszer finomszemcsés zárolást alkalmazott a megosztott adatszerkezetek védelme érdekében. Azok az ügyvezetők, fordítók, segédprogramok és még olyan kifinomult felhasználói alkalmazások, amelyeknek több példánya egyidejűleg futtatható, úgy lettek megírva, hogy meg lehessen osztani a kódjukat. Ehhez csak egy példány betöltése volt szükséges a memóriába, ezzel mind a hely, mind a kód betöltéséhez szükséges idő megtakarításra került.

A kód és az adatok különféle terhelési entitásokra történő szétválasztásának másik oka az volt, hogy a memóriát két független bankként (különálló fizikai szekrényekként) valósították meg, az úgynevezett IBANK-t és DBANK-t (utasítások és adatok). Mindegyiknek meg volt a saját hozzáférési útvonala, így a CPU mindkét bankot egyszerre olvashatta. Ha az egyik memória bankba futtatunk futtatható kódot, a másikba adatokat, akkor sok program futtatási ideje majdnem felére csökkenhet.

A Reentrant kódnak szálbiztosnak kellett lennie (csak végrehajtani); az önmódosító kód nem engedélyezett. Más programok esetében a futtatható kód futás közbeni módosítása még mindig elfogadható programozási technika volt az 1100-as sorozatú számítógépek idején, de a felhasználókat arra bíztatták, hogy ne tegyék meg a teljesítményütem miatt. A biztonsági előnyöket ugyan reklámozták, de nem értékelték nagyra, mert az 1100-as sorozat legtöbb alkalmazásának feltörése senkinek sem jelentene hasznot, és mivel akkor kevés hacker volt rosszindulatú.

Az Exec 8 elsősorban egy kötegelt feldolgozó rendszer volt, amely az alkalmazásoknak (úgynevezett "feladatoknak") nagyon finom vezérlést adott a CPU ütemezési prioritása számára a szálai számára (úgynevezett "tevékenységek"). A processzor kapcsolása megelőző volt, a magasabb prioritású szálak megszerezték az irányítást a processzor felett, amely jelenleg a programok legalacsonyabb prioritású szálait futtatja. A valós idejű rendszerek kivételével még a legalacsonyabb prioritású feladatok is kaptak némi processzor-időt. Ez egy multiprogramozó és többprocesszoros operációs rendszer volt, teljesen szimmetrikus processzorkezeléssel. A hardverbe épített tesztelt és beállított utasítás nagyon hatékony és finom szemcsés rögzítést tett lehetővé mind az operációs rendszeren, mind a többszálas alkalmazásokon belül.

Az Exec 8 alkalmazásban a munka munkákba, ún. "Futásokba" szerveződik, amelyek ütemezése prioritásuk és zárolható erőforrások, például Uniservo szalagos meghajtók vagy Fastrand dobfájlok szükségessége alapján történik. A vezérlőnyelv szintaxisa a "@" szimbólumot (amelyet az Univac "főtérnek" nevezte) használja a vezérlő utasítás felismerési szimbólumaként. Ezt azonnal követte a parancs vagy a program neve, majd vessző és bármelyik kapcsoló. Szóköz karakter után az utasítás többi része különbözik az egyes parancsoktól. A FORTRAN program fordítására szolgáló parancs "@FOR [, options] sourcefile, objectfile" -nek tűnik. Az alkalmazás bemeneti adatai leolvashatók egy fájlból (általában kártyaképek), vagy azonnal követhetik a @ parancsot a futtatási folyamban. Az "@END" őrszemig terjedő összes sort bemeneti adatnak tekintettük, ezért a beillesztés elfelejtése oda vezetett, hogy a fordító a következő parancsokat programadatokként értelmezte. Emiatt előnyösebb volt az adatok fájlokban történő feldolgozása, nem pedig a futtatási adatfolyamba történő beírása.

1968-ban megkezdődött az időmegosztási képesség hozzáadása az Exec 8 programhoz. Ezt az ügyvezető igazgató 23. szintjével szállították 1969-ben. Az időmegosztás (úgynevezett igénymód ) ugyanazokkal a képességekkel rendelkezett, mint a kötegelt és a valós idejű folyamatok. Az ASCII terminálról mindent meg lehet tenni, amit kötegenként lehet elvégezni. Igény szerinti módban a munkafolyamat I / O-t egy terminálkezelőhöz csatolták, nem pedig a kártya kép (bemenet) és a spool (kimenet) fájlokhoz. Ugyanazt a futásvezérlő nyelvet használták mindkettőhöz. Néhány évvel később konkrétabb időmegosztási parancsok kerültek hozzá, és néhány vezérlő nyilatkozatot aszinkron módon adhattak ki azonnali feldolgozás céljából, még akkor is, amikor sem a végrehajtó, sem a futó program nem számított adatokra. Ezek a parancsok, amelyeket csak egy terminálról lehetett megadni, "@@" -val kezdődtek. Mivel ugyanolyan terminálról más folyamatban lévő munka leállítása nélkül is végrehajthatók, átlátszó parancsoknak hívták őket. Eleinte csak állítások voltak a jelenlegi program megölésére vagy a terminál kimenetének átirányítására egy fájlba, de végül szinte az összes vezérlő utasításnak engedélyezték, hogy "azonnali" legyen.

A kötegelt és az igényfutások is egy @FIN utasítással zárulnak, és ha egy igényfelhasználó a munkamenetét addig fejezi be, amíg a futtatása aktív, az Exec automatikusan leállítja a futtatást anélkül, hogy @FIN-t igényelne.

Kommunikációs szoftver

A tranzakció-feldolgozási képességet az 1960-as évek végén fejlesztették ki a United Airlines társasággal közös projektként, majd egy másik, az Air Kanadával közös projektben finomították. Ezt a képességet 1972-ben teljesen integrálták az operációs rendszerbe, és ez az 1100-as sorozat jövőbeni növekedésének alapja lett. A korai felhasználók közvetlenül, valós idejű programjaikból vezérelték a kommunikációs vonalakat. A tranzakciófeldolgozás fejlesztésének része volt egy kommunikációs üzenetrendszer, amely kezelte a kommunikációs vonalakat, és üzeneteket mutatott be az Exec 8 számára, hogy tranzakcióként ütemezzék őket. Ez áthelyezte az összes alacsony szintű kommunikációs fizikai vonalkezelést és protokollt az alkalmazásokból a CMS 1100 alkalmazásba.

Maga a CMS 1100 valós idejű, többszálú programként futott, azzal a kiváltsággal, hogy megszerezze a kommunikációs vonalak vezérlését és tranzakciós üzeneteket küldjön be ütemezés céljából. Ez arra vezetett, hogy az Exec 8 szerint mindenféle alkalmazást gondosan ellenőrizni kell annak biztosítása érdekében, hogy ne okozzanak integritási problémákat. A biztonság minden bizonnyal aggodalomra ad okot, de az első időkben a rendszer megbízhatósága és integritása sokkal nagyobb kérdés volt. A rendszer továbbra is elsősorban kötegelt és tranzakciós feldolgozás volt, és nem sok esély volt arra, hogy bárki jogosulatlan kódot telepítsen a rendszerre. A CMS 1100 később hozzáadta azt a képességet, hogy interfész legyen az igényes terminálok és a tranzakciós terminálok számára, hogy mindkét terminál számára használhatók legyenek terminálok, és a korai terminál meghajtók eltávolíthatók legyenek az Exec-ből. A CMS 1100-ot később a CPComm (ClearPath Enterprise Servers Communications Platform) és a SILAS (System Interface for Legacy Application Systems) kombinációja váltotta fel. Az Intel-alapú Dorado kiszolgáló modelleknél az alacsonyabb szintű kommunikációt firmware-re helyezték át, a felső szinteket a SILAS és a CPCommOS (ClearPath Enterprise Servers Communications Platform for Open Systems) kezelte.

Az Exec

Az Exec tartalmazza a rendszer összes kódját, amely a legmagasabb jogosultsági szinteken futtatható. Nincsenek mechanizmusok más kódok előléptetésére ezekre a jogosultsági szintekre.

Az Exec felelős a rendszer hardverének kezeléséért, a munka ütemezéséért és irányításáért, valamint az operátorokkal és rendszergazdákkal való kommunikációért.

A 16.0 kiadásban az Exec a 49R2 (49.70.5) szinttel rendelkezik. A belső rendszerszintek háromrészes számot használnak, például 21.92.42 (ami az első széles körben használt termelési rendszer volt, bár korábbi telepítéseket számos helyszínen alkalmaztak a gyártásban). Az első számrész a fő szint, és jelzi az Exec új verzióját, az összes korábbi frissítéssel együtt egy új alapverzióba integrálva. Ez egy ritka folyamat, és évenként lép fel. A második számrész a legfrissebb frissítések verzióit jelzi, és gyakran hetente többször is előfordul. Amikor döntés születik a funkció tartalmának befagyasztásáról és a kiadásra való felkészülésről, a harmadik rész játékba lép, és javítások és kisebb funkciófrissítések alkalmával jelzi a kiadás előtti szint verzióit. A kiadás szintjének előkészítésével párhuzamosan a "fővonal" frissítései folytatódnak, miközben a mérnökök integrálják a változásokat a jövőbeli kiadások előkészítése során. Sok éven keresztül a hivatalos kiadási szint a teljes háromrészes szám volt. A későbbi kiadásokat egyszerűen 44R1, 44R2, 49R2 és így tovább nevezték el, bár a háromrészes számot továbbra is belsőleg használják.

Munkavégzés

Az Exec a szívében egy valós idejű, több szálból álló kötegelt feldolgozó rendszer. Minden arra a modellre épült. Maga az Exec nagyrészt valós idejű programként van felépítve. A Windows szolgáltatásként szolgáltatásként , vagy a Linux és a UNIX Daemons szolgáltatásként végrehajtott funkciókat az Execen belüli tevékenységként vagy kötegelt programként hajtják végre, amelyek mindig a háttérben futnak.

Az időmegosztás ( igény szerinti üzemmód ) és a tranzakciók feldolgozása speciális kötegelt esetekként valósul meg. Ennek egyik eredménye, hogy kevés korlátozás vonatkozik arra, hogy egy időmegosztó felhasználó vagy tranzakciós program mit tehet. Számos figyelmeztetés van a tranzakciós programok írói számára, hogy nem lesznek elégedettek a teljesítménnyel, ha például szalagos rögzítést kérnek, de ez megengedett.

A legnagyobb munkaegység a "Run". Ez a gyári "gyártási futtatás" terminológiából származik, és általában megegyezik a más rendszereken végzett munkával vagy munkamenettel. A futást a "futási folyama" határozza meg. A futtatott adatfolyam a végrehajtandó lépéseket képviselő vezérlő utasítások sorozata. Tartalmazhatják a fájlkezelést, a program végrehajtását és a vezérlés ágait. A kötegelt futtatást általában fájlként tárolják, és egy másik futtatáson belüli "Start" parancs vagy az operátor ütemezi. Az időmegosztási futtatást egy időmegosztó terminálról történő bejelentkezés és a @RUN parancs megadása indítja el. Gyakran a @RUN utasítás és a második vezérlő utasítás (gyakran @ADD vagy egy program végrehajtása) automatikusan generálódik a felhasználói profil alapján. A biztonsági engedélyeket a hitelesített felhasználói azonosító és a Futtatás vezérlő utasításban megadott egyéb információk alapján érvényesítik.

A tranzakciók különleges esetek. Valójában nincsenek vezérlő utasítások, de a futtatás belső adatstruktúrái létrejönnek. Ez lehetővé teszi az Exec számára, hogy ugyanazokat a biztonsági, könyvelési, hibakeresési stb. Mechanizmusokat társítsa a tranzakciós programokhoz. Általában a biztonsági profil a memóriába kerül, amikor a tranzakció felhasználója hitelesítésre kerül, és a tranzakció ütemezésekor átmásolásra kerül a felhasználó munkamenet adatairól a tranzakció futási állapotába. Mivel minden tranzakciópéldány lényegében Run, a könyvelés, a naplózás és a hibakezelés mind a Run mechanizmusba van foglalva.

Köteg

A kötegelt feladatokat (futtatásokat) az jellemzi, hogy egy fájlban egy runstream (job control language utasítások) vannak tárolva. A kötegelt feladat mindig egy @RUN utasítást tartalmaz a fájl első rekordjaként. Ez az utasítás megadja a futásnak a nevet (runid), meghatározza a prioritásokat és meghatározza a feladat várhatóan használt SUPS (Standard Processing Unit) számát. A feladatot valamilyen más jobból indítják @START vezérlő utasítással, vagy az operátor ST kulcs segítségével. A rendszer konfigurálható úgy, hogy indításakor automatikusan kiadjon @START utasításokat tetszőleges számú feladatra. Ezek a feladatok az inicializálási, helyreállítási és háttérfunkciók végrehajtását szolgálják.

A @RUN utasítás összes mezőjét felülírhatják a @START utasítás megfelelő mezői. Kivéve, ha a @START programot egy kiváltságos felhasználó hajtja végre, a felhasználói azonosítót és az egyéb biztonsági állapotokat mindig a @START műveletet futtatják.

Két prioritási mező van a @RUN utasításban. Az egyik a lemaradás prioritásának megadására szolgál. 26 elmaradt prioritási szint létezik (A - Z). Az Exec maximálisan beállította a nyitott kötegelt futások számát. Ha eléri ezt a szintet, akkor a munkákat kiemelt sorrendben választja ki az elmaradt várólistákból. A prioritáson belüli kiválasztás általában a FIFO. Az Exec azonban az első programfuttatásig előszkenneli a jobvezérlő utasításokat, fájlneveket és tekercsszámokat keresve. Ha a munka azonnal leállna, mert bizonyos erőforrások nem állnak rendelkezésre, akkor megkerülhető, ha más munkákat ugyanazon prioritási szinten indít.

A második prioritási szint egy végrehajtó processzor erőforráscsoportot határoz meg. Általában a magasabb végrehajtási csoport prioritásai általában hosszabb processzoridőt kapnak.

Míg az OS 2200 jobvezérlő nyelv nem támogatja a teljes programozhatóságot, az @ADD vezérlő utasítás segítségével lehetővé teszi a vezérlőnyelv szekvenciáinak dinamikus hozzáadását. Lehet, hogy a hozzáadandó fájlt ugyanaz a job hozta létre közvetlenül a hozzáadása előtt. Az @ADD és a legtöbb más vezérlő utasítás egy futó programon belül is beadható API-n keresztül. A programozhatóság közvetett módon elérhető a Symbolic Stream Generator (SSG) használatával. Az SSG egy programozási nyelv a szöveges fájlok manipulálására és létrehozására a bemeneti paraméterekből és a rendszerinformációkból. Sokat használják a konfigurációkezelés ( gyártás ) feldolgozásához és más olyan funkciókhoz, ahol a szöveges képeket programozottan kell létrehozni. Az így kapott kimenet ugyanabban a menetben "@ADD" szerkeszthető, így biztosítva a közvetetten programozható futást.

Az üzemeltetői parancsok rendelkezésre állnak a futások lemaradásának és végrehajtásának prioritásainak megváltoztatására. Mivel az API minden kezelőparancsot rendelkezésre áll a megfelelően privilegizált felhasználók számára, ezt egy távoli rendszergazda automatizálhatja vagy vezérelheti.

A határidő a kötegelt esetek speciális esete. A határidő futás ugyanúgy néz ki, mint bármely más kötegelt futás, azzal a különbséggel, hogy a @RUN vagy @START vezérlő nyilatkozatban határidő van megadva. A határidő időpontját az ellenőrzési nyilatkozaton szereplő maximális SUPS-szel (időbecsléssel) együtt kell használni. A határidő-feladat normál kötegelt prioritások mellett fut, hacsak nem tűnik úgy, hogy elmulasztaná a határidejét. Akkor minél nagyobb az eltérés a határidőig eltelt idő és a fennmaradó SUPS között, annál nagyobb a prioritás. Míg a határidő nem zárhatja le teljesen a tranzakciókat, és nincs hatása a valós idejűre, akkor a rendszer többi feldolgozását a cél elérése érdekében hatékonyan leállíthatja.

Igény

Az OS 2200 időmegosztási munkameneteket igény szerinti ("igény szerint") futásoknak nevezzük. Ugyanazt a vezérlőnyelvet használják, mint a kötegelt futtatásokat, néhány kiegészítéssel, az úgynevezett "azonnali" vezérlő utasításokkal. Az azonnali vezérlő utasítások a "@@" jelzőt használják, amely jelzi, hogy azokat azonnal végre kell hajtani akkor is, ha egy program fut. Míg fájlok létrehozására vagy hozzárendelésére használhatók, a legfontosabbak lehetővé teszik az igényt felhasználó felhasználók számára, hogy hibával leállítsák egy futó programot, vagy akár jelet is küldjenek neki.

Tranzakciók

A tranzakciókat futtatásként hajtják végre, de tárolt vagy benyújtott ellenőrzési utasítások nélkül. Ehelyett, amikor egy tranzakció-munkamenetként definiált munkamenetből érkezik egy üzenet, azt beolvassa, hogy meghatározza azt a tranzakciós várólistát, amelyre kerülni kell. Ezt általában az üzenet első karakterei határozzák meg, de a felhasználó által írt szkennerek hozzáadhatók.

A kommunikációs menedzser, amely akár 250 000 aktív munkamenet kezelésére is képes, átveszi a bejövő tranzakciós üzeneteket és továbbítja azokat az üzenetsoros szoftverhez. Korlátlan számú sorban álló üzenetet képes kezelni az üzenetsoros architektúra segítségével. Felhívás érkezik az operációs rendszer Transaction Interface Package (TIP) API-jaira, hogy a tranzakciót a megfelelő sorban állási sorba állítsák. Minden sorban állási pont meghatározza a munka és a kapcsolódó végrehajtandó tranzakciós program prioritási és egyidejűségi szintjét.

A tranzakciós program ütemezési fája lehetővé teszi az ügyfél számára, hogy relatív használatot állapítson meg a tranzakciós programok csoportjaihoz. Az egyidejűségi korlátok elkerülik, hogy egyfajta munka uralja a rendszert, kizárva a többi munkát, és elkerülik az erőforrások túlzott elkötelezettségét. Legfeljebb 4094 csomópont hozható létre a fában.

• A fa minden csomópontjára megadott maximális egyidejűség
• A magasabb csomópontok egyidejűsége korlátozza a függő csomópontok teljes egyidejűségét
• A legmagasabb csomópont egyidejűsége korlátozza a rendszer egyidejűségét

Minden tranzakciós programhoz megadható az elsőbbség (0–63) és a párhuzamossági szint (1–2047).

Az ütemezéshez a legmagasabb prioritású tranzakciót választják, kivéve, ha a csomópontjára és a magasabb csomópontokra érvényes párhuzamossági irányelvek korlátozzák őket.

Valós idő

A valós idő nem egy másik típusú futás. Inkább ez egy prioritási szint, amelyet bármely tevékenység kérhet. A valós idejét általában a hosszú futó kötegelt programok használják, például az OS 2200 kommunikációs menedzser CPComm, de nem korlátozódik ilyenekre.

Az alkalmazás számára 36 valós idejű prioritási szint áll rendelkezésre az API számára. A felhasználónak és a fióknak kiváltsággal kell rendelkeznie a valós idejű prioritások használatához. A webhely feladata annak ellenőrzése, hogy alkalmazásaik hogyan használják a prioritási szinteket. A valós idejű prioritások teljesen uralják az összes alacsonyabb prioritást, így nagyon rosszul viselkedő valós idejű program kapcsolhatja össze egy vagy több processzort.

A valós idejű prioritás egy egyedi tevékenységre (szálra) vonatkozik, így a programnak egyszerre lehetnek valós és nem valós idejű szálai is.

CPU küldése

Miután elindult egy futtatás, a processzorhoz való hozzáférés szabályozza a haladás sebességét. Az Exec szíve az összes processzort irányító diszpécser .

Az Exec akár 4095 prioritás diszpécserét is támogatja, bár a legtöbb webhely ezeknek csak kis részhalmazát definiálja. A két legmagasabb prioritás nem kapcsolható. Bizonyos típusú feldolgozások elismerése, amelyeknek engedélyezni kell, hogy folytassák azokat a processzorokat, amelyeken elindultak, amíg önként nem adják fel az irányítást. A megszakítás zárolása akkor következik be, amikor megszakadás érkezik, vagy néhány speciális esetben, amikor más Exec kód megakadályozza az összes megszakítást (annak érdekében, hogy megváltoztasson néhány olyan adatot, amelyhez a megszakítás kezelője is hozzáférhet).

Az összekapcsolást a megszakítás utáni feldolgozási rutinok használják, amelyeknek vagy ugyanazon a fizikai processzoron kell futniuk, vagy egyszerűen nem szabad őket megszakítani. A diszpécser, az I / O befejezések és az I / O kezdeményezés néhány példa. Mindkét prioritás által használt összes zár spin-zár, mivel csak egy másik processzoron állíthatja be őket valaki más, és a tervezés megköveteli, hogy csak nagyon rövid utasítássorokra állítsák be őket.

A High Exec prioritást az operátor parancskezelője és néhány más funkció használja, amelyeknek akkor is futtatniuk kell, ha egy valós idejű program rendelkezik irányítással. Várhatóan csak nagyon rövid időt vesznek igénybe. Ha több időre van szükségük, sorba kell állítaniuk a Low Exec tevékenység által feldolgozandó munkát.

A valós idejű tevékenységek korlátlan mennyiségű processzorral rendelkeznek, és váltás nélkül futnak, kivéve, ha egy magasabb prioritású valós idejű vagy High Exec tevékenység megszakítja őket. A valós idejű tevékenységeket minden elérhető processzor vezérli, amely valamivel alacsonyabb prioritású fut. A megszakításokat a processzorok között küldik, ha szükséges az azonnali rendelkezésre állás érdekében. A valós idejét az ügyfelek rakéták repülésére, szimulátorok futtatására és egyéb, azonnali választ igénylő funkciókra használják.

A tranzakciós prioritásokat kétféleképpen lehet kezelni, a helyszín meghatározása szerint. Valamilyen alacsonyabb prioritású valós idejűek lehetnek, mivel csak a prioritás számít, és a kvantum mérete lényegében végtelen. Ez nagyon rövid idejű tranzakciók esetében megfelelő, például a légitársaságok foglalása esetén; ha az egyik egy programozási hiba miatt hurkol, az Exec leállítja, amikor eléri a nagyon kicsi konfigurált maximális időt. A másik űrlap lehetővé teszi az Exec számára, hogy a rendszer erőforrás-használatának optimalizálása érdekében változtassa meg a prioritást egy tartományon belül. A megközelítés nagyobb prioritást és rövidebb időszeleteket ad azoknak a programoknak, amelyek korlátozott I / O és fokozatosan alacsonyabb prioritásúak, de hosszabb időszeleteket adnak a számítástechnikához. Az Exec dinamikusan módosítja ezeket a prioritásokat a viselkedés alapján, mivel a programok gyakran mindkét irányban viselkednek különböző időpontokban. Ez a megközelítés alkalmas a hosszabb futó tranzakciókra, például az adatbázis-lekérdezésekre vagy a légitársaságok viteldíjaira.

A köteg és a kereslet mindig dinamikusan beállított prioritásokat alkalmaz. Az I / O korlátozott programok, vagy az időmegosztó felhasználóval folytatott beszélgetések során magasabb prioritásokat kapnak, de rövid időrészeket kapnak. A több számításorientált program alacsonyabb prioritásokat és hosszabb időszeleteket kap.

Az Exec két további mechanizmussal rendelkezik a diszpécser optimalizálásához. Az egyik az affinitáson alapuló diszpécser. Ha lehetséges, az Exec ugyanazon a processzoron fog futtatni egy tevékenységet, mint amilyen legutóbb volt, hogy a maradék gyorsítótár-tartalom legnagyobb előnyét kihasználja. Ha ez nem lehetséges, akkor megpróbálja a tevékenységeket a "legközelebbi" processzoron tartani a gyorsítótár és a memória elérési ideje szempontjából. A második egy "méltányosság" politikai mechanizmus. A webhely meghatározhatja az egyes tranzakciókhoz, igényekhez és kötegekhez kiosztandó erőforrások relatív százalékos arányát. A tranzakciókon és a kötegeken belül vannak olyan prioritási csoportok, amelyek tovább jelezhetik, hogy a csoportjuk idejének hány százalékát kell a prioritáshoz rendelni. Ez biztosítja, hogy a tranzakciók ne uralhassák annyira a rendszert, hogy ne végezzen kötegelt munkát. A különféle prioritási csoportok között biztosítja, hogy bizonyos haladás biztosítható legyen az egyes csoportok számára (kivéve, ha a csoport százalékos értéke nulla). Ezek a "fairness" algoritmusok csak akkor lépnek működésbe, ha a processzorok nagyon elfoglaltak, de az OS 2200 rendszerek gyakran úgy működnek, hogy az összes processzor közel 100% -ban kihasználva van.

Mérés

Az OS 2200 számos modellt támogat a rendszer teljesítményének kezeléséhez. Az ügyfelek megvásárolhatnak egy bizonyos rögzített teljesítményszintet, és az Exec figyelni fogja a processzor használatát annak biztosítására, hogy a teljesítmény ne haladja meg ezt a szintet. Az ügyfelek ideiglenesen vagy véglegesen további teljesítményt is vásárolhatnak, a rendszer teljes kapacitásáig, ha megnő a munkaterhelésük vagy vészhelyzet esetén ez szükséges.

A közelmúltban a rendszer hozzáadott egy mért használati képességet. Ebben az üzemmódban a rendszer teljes ereje mindig elérhető az ügyfél számára (bár ezt adminisztratív úton korlátozhatják). A felhasználás egy hónap alatt halmozódik fel, majd a bejelentett felhasználás bekerül az Unisys számlázására. A konkrét szerződési feltételektől függően az ügyfél számlát kaphat a havi szerződéses alapérték feletti többlethasználatról, vagy csak egy nyilatkozatot, amely azt mutatja, hogy a teljes szerződéses felhasználás csökkent. Az első űrlap olyan, mint egy mobiltelefon-számla, amely felesleges lehet perceken keresztüli töltésre. Ez utóbbi olyan, mintha előre fizetett telefonkártyát vásárolna.

Fájlrendszer

Az OS 2200 nem rendelkezik hierarchikus fájlrendszerrel, mint a legtöbb más operációs rendszer. Inkább strukturált elnevezési konvencióval és a programfájloknak nevezett tárolófájlok fogalmával rendelkezik.

Az OS 2200 fájljai egyszerűen konténerek, amelyek megcímezhetők vagy a fájlban lévő szóeltolással, vagy pedig a fájlban lévő szektor (28 szavas egység) eltolással. A 28 szó egy korai tömegtároló eszköz (a FASTRAND dob) történelmi egysége, amely fizikai sávonként 64 ilyen egységet képes befogadni. Ennek ellenére szerencsés történelmi baleset. Négy ilyen 28 szavas egység vagy 112 szó 504 bájtot foglal el. A mai 512 bájtos fizikai rekordokat használó tömeges tárolóeszközökkel az OS 2200 kliensek szinte mind a 112 szó többszörösét elfogadták fizikai rekordméretüknek és adatbázis-oldalméretüknek. Az I / O processzorok automatikusan igazodnak az 504 <-> 512 bájtos hozzárendeléshez, 8 bájt nullát adva hozzá az írásokhoz, és lehúzva azokat minden egyes fizikai rekord olvasásakor. Az OS 2200 úgy kezeli az alkalmazásokat, amelyek nem a 112 szó többszörösét használják, azzal, hogy oszthatatlanul elolvassa a tartalmazó fizikai rekordokat, és az adatok láncolásával kiírja a változatlan és megváltozott részeket. A speciális reteszelési funkciók garantálják az oszthatatlanságot akkor is, ha eszközhibák vannak, és egy fürt több rendszerén keresztül.

A fájlformátumokat és egyéb belső adatstruktúrákat a Data Structures Programming Reference Manual ismerteti .

Fájlnevek

Az Exec-8 óta a fájlnevek a következő formát öltötték: Minősítő * Fájlnév (f-ciklus) (pl. "SZEMÉLY * EMPLOYEES (+1)". A minősítő és a fájlnév egyszerűen tizenkét karakteres karakterlánc, amelyet az ügyfél által kívánt névstruktúra létrehozására használnak. Az F-ciklus 0 és 999 közötti szám, amely lehetővé teszi a fájl több generációját. Ezekre relatív számok hivatkozhatnak: (+1) következő vagy új ciklus, (-1) előző ciklus, (+0) aktuális ciklus. A ciklus kikapcsolása alapértelmezés szerint az aktuális ciklus. A fájlok új generációit létrehozó kötegelt gyártási futtatások ezt a megközelítést használják. A számok 999 után körbeveszik. Egyszerre csak 32 egymást követő relatív ciklusszám létezhet. (+1) létrehozása törli (-31).

Bármely fájl használható programfájlként. A programfájl olyan elemeket tartalmaz, amelyek általában fájlként működnek. Az elemek elnevezése a Qualifier * fájlnév (f-ciklus). Elem / verzió (e-ciklus) (pl. "SZEMÉLY * PROGRAMOK.TAXCALC / 2008"). Az elem és a verzió tizenkét karakteres név, amelyet bármilyen módon használnak a felhasználók. Az E-ciklus annyiban hasonlít az f-ciklushoz, hogy generációs számot képvisel, de nem korlátozódik 32 egyidejű ciklusra, és a határérték 256 K ciklus. Az e-ciklus azonban csak a szöveges elemekre vonatkozik, és a szövegelem minden egyes sorát megjelölik azok a ciklusszámok, amelyekre beillesztették és törölték. Az elemeknek típusuk és altípusuk is van. A leggyakrabban használt típusok a "szöveg" és az "objektum". Ha az alapértelmezett típus nem megfelelő, az opciók kiválasztják a megfelelő típust. A szöveges elemeknek vannak olyan altípusaik is, amelyek általában a programozási nyelvet képviselik (pl. "ASM", "C", "COB", "FOR"). Az objektumfájl alapértelmezett elemneve megegyezik azzal a szövegfájllal, amelyből létrehozták.

Az objektumelem futtatható, ha ez egy fő program, vagy más objektum-elemekhez kapcsolódik, beleértve a fő programot is. A linkelés lehet statikus vagy dinamikus. A fő program végrehajtható előzetes összekapcsolás nélkül, feltéve, hogy az összes szükséges alprogram ugyanabban a programfájlban található, rendszerkönyvtár vagy más módon ismert. A programfájlba szabályokat lehet beilleszteni, amelyek irányítják a dinamikus linkelő keresését a nem kitöltött hivatkozások után. A linkelő felhasználható több objektum modul statikus összekapcsolására is egy új objektum modul létrehozásához, amely tartalmazza az eredeti objektum modulokban található összes utasítást, adatot és egyéb információt.

Az Omnibus elemek felhasználhatók adatokként, vagy strukturált információk tárolására szolgálhatnak az alkalmazások és a rendszer segédprogramjai számára. Az omnibus elemnek nincs feltételezett szerkezete.

A korábbi (alapmódú) programozási modellekkel való kompatibilitás érdekében vannak áthelyezhető és abszolút elemtípusok. Az áthelyezhető elemek az alapmódú fordítók kimenetei. Az alapmódú statikus linker (@MAP - a gyűjtő) egyesítheti őket egy "abszolút" elemként, amely végrehajtható.

Fájlkezelés

Az OS 2200 egy teljesen virtuális fájlrendszert valósít meg. A fájlok bárhol lefoglalhatók bármely tömegtároló eszközön. A tömeges tárolást nagy térkészletként kezelik, hasonlóan a virtuális memória kezeléséhez. Míg lehetőség szerint összefüggő terület van kiosztva, a tömeges tárolást 8 KB méretű oldalaként kezelik, és egy fájl elhelyezhető ugyanazon vagy különböző eszközök annyi területén, amennyire csak szükséges. A fájlok dinamikus kiterjesztése megkísérli az előző kiosztás melletti terület kiosztását, de helyet talál, ahol csak elérhető. Valójában a fájloknak nem is kell lenniük a tömegtárban, hogy felhasználhassák őket. Az Exec és a fájlmentési rendszer teljesen integrálva vannak. A fájl biztonsági másolatának elkészítésekor a szalagtekercs (ek) száma (i) a fájlkönyvtárba kerülnek. Ha kevés a hely a tömeges tárhelyen, néhány fájlt egyszerűen "kirakatlannak" jelölnek, ha aktuális biztonsági másolatuk van, és a helyük felhasználható. Ha így nem talál elegendő helyet, elindul a biztonsági mentés.

Bármely hivatkozás egy kirakatlan fájlra sorba kerül, amíg a fájlt visszamásolják a tömegtárba. Az egész rendszer automatikus és általában átlátható a felhasználók számára.

Hozzáférési módszerek

Általában az Exec nem biztosít hozzáférési módszereket . A fájlok egyszerűen konténerek. A hozzáférési módszereket a nyelv futási idő rendszere és az adatbázis-kezelő biztosítja. Az egyetlen kivétel egy rögzített blokkú hozzáférési módszer, amelyet nagy volumenű tranzakciók feldolgozásához biztosítanak. Sokkal kevesebb rezsi van, mint az adatbázis-kezelő, de részt vesz az összes zárolási, fürtözési és helyreállítási mechanizmusban.

Kivehető csomagok

Amikor az ügyfelek kifejezettebb ellenőrzést akarnak a fájlok helye felett, használhatják a "cserélhető csomag" koncepciót. Egy időben ezek a valóban képviselt fizikailag kivehető lemezcsomagok, és az operációs rendszer szükség esetén automatikusan generál csomagcsatlakozási kérelmeket az operátorok számára.

Ma még mindig használják fájlok, általában adatbázis fájlok vagy tranzakciós fájlok elhelyezésére egy vagy több lemezkötetre. A fájlok továbbra is több lemezkötetre terjedhetnek ki, és a fájl létrehozásakor most megadják a kötetnevek listáját. Az ilyen kötetcsoportokba tartozó fájlokról még mindig készítenek biztonsági másolatot, de nem tartoznak automatikus virtuális térkezelés alá.

CIFS

Az OS 2200 a Közös Internet Fájlrendszer ( CIFS ) teljes körű megvalósítását is biztosítja . A CIFS implementálja a Microsoft szerverei által használt SMB protokollt és a UNIX / Linux Samba szoftvert. A ClearPath OS 2200 CIFS fájlkiszolgáló és fájlkliens más CIFS-kompatibilis rendszerek számára is. Ide tartoznak a Windows rendszert futtató asztali számítógépek is. A CIFS támogatja az SMB üzenetek aláírását.

Az OS 2200 biztonságának fenntartása érdekében a ClearPath OS 2200 CIFS két szintű védelmet nyújt. Először is, az OS 2200 fájlok csak akkor láthatók a hálózat számára, ha azokat "CIFS" paranccsal "megosztottként" deklarálták. Sajátos jogosultság van annak ellenőrzésére, hogy ki nyilatkozhat meg megosztást. A vezérlés második szintje, hogy minden hozzáférést továbbra is az OS 2200 biztonság véd. A CIFS-en keresztül az OS 2200-hoz hozzáférő ügyfeleket vagy automatikusan azonosítani kell az NTLM-en vagy a Kerberoson keresztül, vagy meg kell kapniuk az OS 2200 felhasználói azonosítójukat és jelszavukat.

A CIFS lehetővé teszi az OS 2200 fájlok hierarchikus nézetben történő megjelenítését. A minősítő általában a fa legmagasabb szintjeként jelenik meg, amelyet a fájlnév, az elem neve és a verzió követ. Ezenkívül a fájlok tárolhatók az OS 2200 szervereken a teljes Windows fájlnév formátum használatával. A Windows-alkalmazások az OS 2200-at másik fájlszerverként fogják látni. Az OS 2200 alkalmazások rendelkeznek API-kkal, amelyek a hálózaton található más CIFS-kompatibilis szervereken, például a Windows fájlszervereken léteznek. A szöveges fájlok automatikusan konvertálódnak az OS 2200 belső formátumaiba és onnan. A bináris fájlokat az alkalmazásnak meg kell értenie.

Az OS 2200 alatt futó CIFSUT segédprogram titkosított tömörített fájlokat cserélhet más szoftverekkel, például a WinZip-el.

Alrendszerek

Az alrendszerek és a védett alrendszerek koncepciója központi szerepet játszik az OS 2200 tervezésében. Az alrendszer leginkább hasonlít a Windows .dll fájljaihoz. Ez a kód és az adatok megoszthatók a rendszerben futó összes program között. Az OS 2200 operációs rendszerben minden alrendszer saját bankkészlettel rendelkezik, amelyek a címtér külön részében találhatók, és amelyeket egyetlen felhasználói program sem tud közvetlenül elérni. Ehelyett a hardver és az operációs rendszer olyan "kaput" biztosítanak, amely lehet a Call utasítás célpontja. További információkért lásd: Unisys 2200 sorozatú rendszer architektúra .

Az adatbázis-kezelők, a futtatási idő könyvtárak, az üzenetkezelő rendszer és sok más rendszerfunkció alrendszerként valósul meg. Bizonyos, általában tiszta kódból álló alrendszerek, például a futási könyvtárak a kapu igénye nélkül lehetnek a Call utasítás közvetlen célpontjai. Ezek az alrendszerek a felhasználói program védelmi környezetében futnak. Más alrendszerek, például az adatbázis-kezelők, kódból és adatokból vagy privilegizált kódból állnak, és csak kapun keresztül hívhatók meg. Ezek az alrendszerek hozzáférés-ellenőrzési listákkal is társulhatnak, hogy ellenőrizzék, ki hívhatja őket. Ennél is fontosabb, hogy a kapu vezérli a látható belépési pontokat, a védelmi környezetet, amelyben az alrendszer futni fog, és gyakran egy felhasználóspecifikus paramétert, amely további biztonságos információt nyújt a hívó félről.

Biztonság

B1 biztonság

Az OS 2200 biztonsági rendszert úgy tervezték, hogy megvédje az adatokat az illetéktelen hozzáféréstől, módosítástól vagy expozíciótól. Magában foglalja a DoD Orange Book B1 szintű specifikáció megvalósítását. Az OS 2200 először 1989 szeptemberében kapott sikeres B1 értékelést. Ezt az értékelést 1994-ig fenntartották. Ezt követően az OS 2200 fejlesztői továbbra is követték a B1 értékelés által megkövetelt fejlesztési és dokumentációs gyakorlatokat.

A B1 rendszer központi eleme a felhasználók és az objektumok fogalma. A felhasználók rendelkeznek személyazonossággal, biztonsági szintekkel, rekeszekkel és jogosultságokkal. Az objektumok megkövetelik a kombinációk bizonyos kombinációit a különféle hozzáférési típusokhoz. Az OS 2200 objektumai fájlokból, védett alrendszerekből, eszközökből és szalagtekercsekből állnak.

A felhasználói munkamenet biztonsági profilja tartalmazza a felhasználói identitást, az engedélyezési szintet (0-63), a rekeszkészletet és az engedélyezett jogosultságokat. Az OS 2200 mind a kötelező hozzáférés-vezérlést (MAC), mind a diszkrecionális hozzáférés-vezérlést (DAC) a Bell-La Padula modell alapján hajtja végre a titoktartás (nincs felolvasás, nincs leírás) és a Biba integritási modell (nem olvasható le, nem ír fel) alapján. . Ahhoz, hogy egy futás egy fájlt olvashasson vagy hajtson végre, a futás végrehajtási szintjének nagyobbnak kell lennie vagy egyenlőnek kell lennie a fájl törlési szintjével, és a fájl szabadon hagyási szintjének 0-nak kell lennie, vagy a futás szabadidősségi tartományán belül kell lennie; ezenkívül a futtatás végrehajtó rekeszkészletének tartalmaznia kell a fájl rekeszkészletét. Mivel az OS 2200 egyesíti a Bell-La Padula és a Biba modell követelményeit, a futás végrehajtási szintjének és rekeszkészletének pontosan meg kell egyeznie egy fájléval, hogy lehetővé tegye a fájlba írást vagy annak törlését.

A DAC egy hozzáférés-vezérlési listát társít egy objektumhoz; a lista azonosítja a hozzáféréssel rendelkező felhasználókat és felhasználói csoportokat, valamint meghatározza a felhasználó vagy csoport számára engedélyezett hozzáférés típusát (olvasás, írás, végrehajtás vagy törlés).

Mivel a B1 vezérlők teljes készlete túl korlátozó a legtöbb környezet számára, a rendszergazdák úgy konfigurálhatják a kiszolgálókat, hogy megválasztják az alkalmazandó vezérlőket. Biztonsági szintek az alapvető biztonságtól a 3. biztonsági szintig szolgálnak kiindulópontként.

Biztonsági őr

Minden OS 2200 rendszerben egy felhasználó van kijelölve biztonsági tisztként. Az alapvető biztonsággal konfigurált rendszereken csak a biztonsági tiszt jogosult bizonyos feladatok végrehajtására. Magasabb szintű biztonsággal konfigurált rendszereken más megbízható felhasználók megengedhetik ezeknek a feladatoknak a végrehajtását.

Az OS 2200 finom szemcsés biztonsági mechanizmust biztosít, a legkevesebb privilégium elvén alapul . Ez az elv megköveteli, hogy csak a szükséges feladat ellátásához szükséges minimális jogosultságot biztosítsák. Így az OS 2200-nak nincs fogalma a "Szuperfelhasználó" szerepről, amelyet bármely felhasználó felvehet. Inkább nagyszámú speciális jogosultságot használ, amelyeket minden felhasználónak külön megadhat. Minden kiváltság egy adott hatósághoz kapcsolódik.

Fájlbiztonság

Az 1. vagy magasabb biztonsági szintekkel konfigurált rendszereken az objektumot létrehozó felhasználó az objektum tulajdonosa. Alapértelmezés szerint az objektum a létrehozó felhasználó számára privát, de lehet nyilvános vagy hozzáférés-vezérlési lista is vezérelheti. A tulajdonos vagy a biztonsági tiszt létrehozhat hozzáférés-ellenőrzési listát az adott objektumhoz.

Az alapvető biztonsággal konfigurált rendszeren a fájloknak nincs tulajdonosuk. Ehelyett egy fiókhoz vagy projekthez létrehozzák őket privátként, vagy nyilvánosak. A hozzájuk való hozzáférés írási és olvasási kulcsokkal szabályozható.

Hitelesítés

Amikor a felhasználók bejelentkeznek a rendszerbe, azonosítják magukat, és opcionálisan kiválaszthatják a szabad mozgásszintet és a rekesz készletet, amelyet a munkamenethez használni fognak.

Az OS 2200 rugalmas hitelesítési rendszert kínál. Több hitelesítési mechanizmus támogatott egyidejűleg. Kliens vagy harmadik fél által írt hitelesítő szoftver is használható. A szokásos hitelesítési képességek a következőket tartalmazzák:

• Felhasználói azonosító és jelszó az OS 2200 által titkosított fájlban
• Hitelesítést egy külső rendszer, például a Microsoft Windows hajt végre, a felhasználói azonosítóval és jelszóval
• NTLM
• Kerberos
• LDAP

Az utolsó kettő lehetővé teszi a biometrikus adatok, az intelligens kártyák és bármely más, az említett technológiák által támogatott hitelesítési mechanizmus használatát.

Titkosítás

Az OS 2200 biztosítja a nyugalmi adatok titkosítását a Cipher API-n keresztül, egy szoftver alrendszeren keresztül, amely titkosítja és visszafejti a hívó fél adatait. A Cipher API támogatja a hardveres gyorsító kártya használatát is az adatok tömeges titkosításához.

CMOS alapú Dorado kiszolgálók esetében a CPComm SSL / TLS titkosítást biztosít az átvitt adatokhoz . Az Intel-alapú Dorado szerverek esetében az SSL-t és a TLS-t az openSSL biztosítja , amely a Dorado firmware-ben található. Minden Dorado szerver támogatja az TLS 1.0–1.2 szinteket, valamint az SSLv3-t, de az SSL alapértelmezés szerint le van tiltva a protokoll sebezhetősége miatt.

A CPComm és a Cipher API is használja a CryptoLib, egy FIPS tanúsított szoftveres titkosító modul titkosítási szolgáltatásait . Az AES és a Triple DES algoritmusok a CryptoLib-ben megvalósított algoritmusok közé tartoznak.

Az OS 2200 támogatja a szalagos meghajtók titkosítását is, amelyek titkosítást biztosítanak az archív adatok számára.

Csoportosítás

Az OS 2200 rendszerek csoportosíthatók , hogy nagyobb teljesítményt és elérhetőséget érjenek el, mint egyetlen rendszer. Legfeljebb 4 rendszer kombinálható klaszterekké, amelyek megosztják az adatbázisokat és fájlokat megosztott lemezeken keresztül. Egy hardvereszköz, az XPC-L, koordinációt biztosít a rendszerek között azáltal, hogy nagysebességű zárkezelőt biztosít az adatbázisok és fájlok eléréséhez.

A fürtözött környezet lehetővé teszi, hogy minden rendszer saját helyi fájlokkal, adatbázisokkal és alkalmazáscsoportokkal rendelkezzen, megosztott fájlokkal és egy vagy több megosztott alkalmazáscsoporttal együtt. A helyi fájlokhoz és adatbázisokhoz csak egyetlen rendszer fér hozzá. A megosztott fájloknak és adatbázisoknak olyan lemezeken kell lenniük, amelyek egyszerre érhetők el a fürt összes rendszeréből.

Az XPC-L kommunikációs utat biztosít a műveletek összehangolására szolgáló rendszerek között. Rendkívül gyors motorral is rendelkezik. Az XPC-L-hez egy speciális I / O processzoron keresztül lehet csatlakozni, amely rendkívül alacsony késleltetéssel működik. Az XPC-L zárkezelője biztosítja a fájlok és az adatbázisok zárolásához szükséges összes funkciót. Ez magában foglalja a holtpont észlelését és a sikertelen alkalmazások zárainak felszabadításának lehetőségét.

Az XPC-L két fizikai szerverrel valósul meg a teljesen redundáns konfiguráció létrehozása érdekében. A karbantartás, beleértve az XPC-L firmware új verzióinak betöltését is, elvégezhető az egyik szerveren, míg a másik továbbra is fut. A hibák, beleértve az egyik szerver fizikai sérülését, nem állítják le a fürtöt, mivel minden információt mindkét kiszolgálóban tárolnak.

Műveletek és adminisztráció

Tevékenységek

Az OS 2200 műveletek aktív operátorok és egy vagy több konzol köré épülnek. Minden konzol egy terminálablak, amelynek egy részét egy fix kijelző számára tartják fenn, amelyet gyakran frissítenek a rendszer tevékenységéről szóló összefoglaló információkkal.

A konzol többi részét az események görgető kijelzőjeként használják. Amikor olyan üzenetet adnak ki, amely kezelői választ igényel, akkor 0 és 9 közötti számot kap, és addig marad a kijelzőn, amíg meg nem válaszolják. A szalagra rögzített üzenetek görgetnek más üzenetekkel, de két percenként megismétlődnek, amíg a szalag fel nem kerül.

A Sentinel műveletek minden OS 2200 művelethez használhatók. Az OS 2200 konzolok egyszerűen ablakok az Operations Sentinel kijelzőjén. Lehet annyi megjelenítő PC, amennyit kíván. A távvezérlés tipikus. A Sentinel műveletek tetszőleges számú ClearPath, Windows, Linux és UNIX rendszert támogatnak.

A termékkel együtt kiadásra kerül egy automatikus műveletüzenet-adatbázis. Ez az adatbázis lehetővé teszi a Sentinel műveletek számára az üzenetek felismerését. A szkriptek írhatók úgy, hogy automatikusan válaszolnak azokra az üzenetekre, amelyek választ igényelnek, elrejtik a nem kívánt üzeneteket, lefordítják más nyelvekre, eseményeket hoznak létre, stb. A kliensek teljesen sötét szobában működnek. Legfeljebb Operations Sentinel kijelzőkkel rendelkeznek távoli helyeken, amelyek figyelik a rendszert és riasztásokat hoznak létre bizonyos események bekövetkezésekor.

Adminisztráció

Az OS 2200 rendszerek adminisztrációja sokféle eszközzel történik, amelyek mindegyike a rendszer egy adott területére specializálódott. Például van egy eszköz a tranzakciós környezet adminisztrációjához, amely lehetővé teszi új tranzakciós programok telepítését, meghatározza az összes szükséges információt róluk, megváltoztatja a sorban állási struktúrát, a prioritásokat és az egyidejűségi szinteket stb.

Más eszközök a biztonsági tisztre vonatkoznak, és lehetővé teszik a felhasználók létrehozását, az engedélyezett jogosultságok megváltoztatását, a rendszer biztonsági beállításainak módosítását stb ^{. ,}

Az eszközök többségének grafikus felülete van, bár néhány nem. Mindegyik egy kötegelt tárolt fájl interfészt biztosít, ahol az összes műveletet megadja a vezérlő adatfolyam. Ez lehetővé teszi bármely adminisztratív felület és az összes adminisztrációs felület szkriptelését akár helyi webhelyekről, esetleg a napszak vagy más események alapján, akár távoli helyekről. Minden adminisztratív területhez egyedi jogosultságokra van szükség.

Alkalmazáscsoportok

Az alkalmazáscsoportok egy logikai konstrukció, amely az Egyetemes Adatrendszer (UDS) példányából, az üzenetsor alrendszer példányából és néhány tranzakcióból áll. Minden alkalmazáscsoportnak megvan a maga ellenőrzési nyomvonala. Az OS 2200 egy rendszerben maximum 16 alkalmazáscsoportot támogat.

Az alkalmazáscsoport fogalma megfelel annak, amit gyakran "alkalmazásnak" neveznek. Vagyis egy sor program és adat, amely a csatlakoztatott feldolgozás valamilyen nagyobb egységét képviseli. Például egy alkalmazáscsoport repülési rendszert képviselhet. Egy másik alkalmazáscsoport képviselheti a vállalati pénzügyi rendszert. Vagy az alkalmazáscsoportok ugyanazon alkalmazás és adatmodell példányait jelenthetik, mint a bankfiókokban. A fontos az, hogy minden alkalmazáscsoportnak megvan a maga környezete, munkamenetei, helyreállítása stb.

Az alkalmazáscsoportokat önállóan lehet elindítani, leállítani és helyreállítani.

Az alkalmazáscsoportok nem rendelkeznek saját számviteli és ütemezési szabályokkal. A több alkalmazáscsoportban lebonyolított tranzakcióknak ugyanazok a prioritásai lehetnek, és prioritásaik egymásra épülnek. Ez lehetővé teszi a webhely számára, hogy a teljes rendszerben ellenőrizze a tranzakciók relatív prioritásait.

Lásd még

• Unisys 2200 sorozatú rendszerarchitektúra a hardverarchitektúráról.
• Unisys OS 2200 programozási nyelvek az OS 2200 fordítóiról és linkelőiről.
• Unisys OS 2200 adatbázisok az OS 2200 adatbázisokról és az adatbázis-kezelőről.
• Unisys OS 2200 kommunikáció az OS 2200 kommunikációval kapcsolatos információkért.
• Unisys OS 2200 elosztott feldolgozás az OS 2200 elosztott feldolgozással kapcsolatos információkért.

A forrásanyag egyéb helyszínei

Az Unisys History Newsletter cikkeket tartalmaz az Unisys történetéről és a számítógépekről. Az Unisys összes történeti hírlevelén kívül más webhelyekre mutató linkek találhatók.

Az Unisys történelmi archívumainak többsége a Minnesotai Egyetem Charles Babbage Intézetében és a delaware-i Hagley Múzeumban és Könyvtárban található. A Charles Babbage Intézet az ERA, néhány korai Remington Rand levéltárat a Saint Paul, MN és a Burroughs archívumok birtokolja. A Hagley Múzeum és Könyvtár őrzi a Sperry-levéltárak nagy részét.

Hivatkozások

Lábjegyzetek