| SVM | |
|---|---|
| Fejlesztő | IBM , NIIEVM |
| OS család | VM |
| Kernel típusa | Virtuális gép |
| Engedély | Szabadalmazott |
| Állapot | történelmi |
A virtuális géprendszer ( SVM ) az EU számítógépének operációs rendszere , az IBM VM rendszer analógja .
A VM (VM és korai verziója, a CP/CMS) az első olyan rendszer, amelyben a virtuálisgép -technológiát implementálták . A CBM virtualizációja konzisztens és teljes volt, különösen a virtuális gépek futtathatták a CBM rendszer egy másik példányát stb. Ezenkívül a CBM futtatása egy CBM virtuális gépen volt az ajánlott módszer a rendszer új verziójának létrehozásához a telepítéshez. Ez konkrétan azt jelentette, hogy bármely valódi számítógépes eszköz egyik vagy másik módszerrel virtuális eszközként ábrázolható egy virtuális gépen. Ez idáig a virtuális gépek egyetlen más megvalósítása sem rendelkezik ezzel a tulajdonsággal.
A szocialista tábor virtuális gépeinek rendszerét először az 1-es verzióban adaptálta a Robotron vállalat (GDR), majd a 2-es verziótól a NIIEVM (Minszk) fejlesztette ki. A NIIEVM tevékenységének köszönhetően az SVM-et a Szovjetunióban az ES számítógépes rendszerszoftver egyik fő összetevőjének tekintették, és ezt követően az ES OS 7-es verziójának alapjává vált , amelyet standard opcióként kínáltak az ES-en való használatra. számítógépes rendszerek Ryad-3 és újabb. A Szovjetunióban a legelterjedtebbek az SVM 3 és 4 verziói voltak. Az 5-ös verziót már a Szovjetunió összeomlása és az ES számítógépes berendezések használatának tömeges felhagyása idején adták ki, ezért nem használták széles körben, és "SVM" néven A 6"-os verzió minszki szakemberei kiadtak egy programcsomagot a VM-hez, amely maximális kompatibilitást biztosít a VM-alkalmazásokkal.
Másrészt, racionális magyarázat nélküli okokból az IBM soha nem ösztönözte VM operációs rendszerének használatát, és a virtuális gépet az IBM marketingje mindig másodlagos szerepkörbe helyezte más nagyszámítógépes operációs rendszerekkel - MVS, OS - képest. és még DOS is, technológiailag sokkal kevésbé fejlett és felhasználóbarát. Valószínűleg a virtuális gép, mint kezdeti kísérleti projekt alacsony költségvetése nem tette lehetővé, hogy az IBM pénzügyi vezetése egyenlőnek ismerje el azokkal a rendszerekkel, amelyekre sokkal több pénzt költöttek.
Építészetileg az SVM több független komponensből állt. A központi komponens a virtuális gép monitor (VMM, IBM neve CP, Control Program) volt, amely egy valódi számítógép hardverét vezérelte, és adott konfigurációjú virtuális gépek halmazát implementálta. A fennmaradó komponensek az MVM irányítása alatt futó virtuális gépek operációs rendszerei vagy rendszerfüggetlen programjai voltak: a párbeszéd-feldolgozó alrendszer (PDO), a hálózati fájlátviteli alrendszer (NFT), az előfizetői állomás logikai kapcsoló alrendszere (PLC), a dump elemzési alrendszer (PAD), a távirányító alrendszer fájlátvitel (PDP), hardvervezérlő alrendszer (PKT), generáló és karbantartási eszközök (SSS).
PDO (Conversational Processing Subsystem, IBM név - CMS , Conversational Monitor System, korábban Cambridge Monitor System; fordított fordítás angolra - PTS, Programming and Testing System) volt a CBM virtuális gépének fő operációs rendszere, amelyben a felhasználók dolgoztak. A PDO párbeszédes felületet biztosított a felhasználó számára, valójában a felhasználó által a terminálon végzett munka PDO-val egy virtuális gépen egy személyi számítógépen végzett munkához hasonlított. Ez nagyon komoly előrelépés volt az ES számítógépek korábbi operációs rendszereihez képest, amelyek párbeszéd-képessége vagy teljesen hiányzott, vagy nagyon korlátozott volt.
A PSP, PLC, PAD, PDP, PKT, SGO alrendszereket rendszerkarbantartási feladatokra szánták, alkalmazásprogramozók és felhasználók nem használták.
Ezen túlmenően a CBM virtuális gépen bármilyen valós hardveren való futtatásra tervezett ES számítógépes operációs rendszer (úgynevezett vendég OS) futtatható volt - ES OS, ES DOS, ES MOS, MVS stb. Az ES OS 7-es verziója, egy speciális BOS operációs rendszert fejlesztettek ki, amely funkcionálisan egyenértékű az EU 6-os verziójával (SVS), de kifejezetten az SVM virtuális gépen való futtatásra tervezték. A BOS a többi ES számítógépes rendszereszköz túlnyomó többségével ellentétben a szovjet programozók független fejlesztése volt, független az IBM-től. Mivel az EU operációs rendszer kötegelt rendszer volt, az OEM felhasználók az előkészített feladatcsomagokat átvihették rá, és virtuális lyukasztó és virtuális ADCP segítségével kaphattak eredményeket .
A Virtual Machine Monitor elméletileg akár 10 000 virtuális gépet is képes volt támogatni egyetlen valós rendszeren. A gyakorlatban az egyidejűleg aktív virtuális gépek számát a számítógép teljesítménye korlátozta, és több tízet is elérhetett.
Az EC Ryad-3 és magasabb számítógépeken megvalósították az SVM mikroprogram támogatásának eszközeit.
Az SVM architektúrája lehetővé tette a számítógépes időfelhasználás elszámolásának természetes megszervezését, ami nagyon fontos volt a költséges többfelhasználós rendszerek esetében. A virtuális gép felhasználója számára elérhető MVM parancs Q UERY T TIME lehetővé tette az aktuális dátum és idő, valamint az aktuális munkamenetben használt valós és virtuális processzorok teljes processzoridejének megállapítását. a virtuális gép. Népszerű volt egy egyszerű REXX nyelvű szkript , amely a rendszerből való kilépéskor egy ilyen parancsot adott ki, a kapott eredményt megszorozta a rendszer gépidejének költségével, és tájékoztatta a felhasználót arról, hogy a munkája mennyibe került az üzemeltető szervezet számára. a számítógép. Egy olyan programozó számára, aki nem foglalta le intenzív számításokkal a processzort, hanem a programok szokásos fejlesztését és hibakeresését végezte, az EU-1066-on a gépi idő tipikus költsége körülbelül 10 rubel volt munkanaponként (azaz megközelítőleg egyenlő volt bérek). Az erőforrás-igényes programok működés közben nagyságrendekkel több processzoridőt igényelhetnek. Természetesen a Szovjetunióban a programozók nem a saját zsebükből fizettek a gépidőért, de ez az ábra azt mutatja, hogy a programozók kódoptimalizálási munkája abban az időben nagyon gyorsan megtérült.
Az EU OS és BOS MVM irányítása alatti használatának lehetősége mellett magát az OEM-et is úgy alakították ki, hogy a lehető legegyszerűbbé tegye a programok átvitelét az EU OS-ből. Lehetőség volt EU OS formátumú lemezek csatlakoztatására a PDO virtuális géphez, és közvetlenül elindítani az EU OS rendszerindító moduljait egy speciális OSRUN paranccsal (bizonyos korlátozásokkal a használt rendszerhívásokra). Ezenkívül az EU operációs rendszerhez készült legtöbb alkalmazás egyszerűen újrafordítható PDO-val, hogy valódi OEM végrehajtható fájlokat kapjon. A PDO rendszerhívások maximálisan kompatibilisek voltak az EU OS-szel, az EU számítógépek alkalmazási programjainak többsége a közös részhalmazukra íródott, és mind EU OS (és MCS) környezetben, mind PDO környezetben futtatható volt.
A virtuális memóriarendszer hatékony kihasználása érdekében a rendszerprogramozó kérésére a címtér egy részét az úgynevezett megosztott szegmensek számára tervezték lefoglalni. Például egy szövegszerkesztő, fordító vagy programozási nyelvet támogató könyvtár betölthető egy megosztott szegmensbe, és így az ezeket használó összes felhasználó hatékonyan hozzáférne ugyanahhoz a másolathoz a virtuális memóriában, ahelyett, hogy minden egyes virtuális géphez külön másolatot készítene.
A DOS ES-től, az OS ES-től és az MVS-től eltérően, amelyek igen nehézkes és kényelmetlen fájlkezelő rendszert biztosítottak a mindennapi használatra (pontosabban az ő terminológiájukban, adatkészleteikben), az PDO az úgynevezett mini-lemezek koncepcióját valósította meg felhasználási lehetőséggel. saját fájlrendszere. A minilemez egy virtuális lemezeszköz volt, amelyet VMM emulált. A minilemezt PDO fájlrendszerben lehetett formázni, ebben az esetben egyetlen fájlkönyvtárat tartalmazott. A fájlazonosító a fájlnévből (legfeljebb 8 karakter), a kiterjesztésből (legfeljebb 8 karakter) és a fájlmódból (1 meghajtóbetűjel és 1 hozzáférési mód számjegye) állt. A név összetevői szóközzel voltak elválasztva, a fájl mód teljesen elhagyható, vagy csak a meghajtó betűjele adható meg. Például egy PROFILE EXEC A1 nevű fájl egy EXEC típusú PDO rendszerindító fájl (a szkriptnyelvek egyikében) a fő felhasználói minilemezen A , a szokásos hozzáférési móddal 1 .
Az OEM fájlok felépítése megfelelt az EU OS adatkészleteinek szerkezetének (a legbonyolultabb típusú adatkészletek kivételével), vagyis minden fájl meghatározott formátumú és hosszúságú rekordokra volt felosztva. Az OEM fő szöveges fájlformátuma az F(80) formátum volt, vagyis egy 80 oszlopos lyukkártyák virtuális paklijának képe .
A minilemezeket több virtuális gép között meg lehetett osztani, így a minilemezeket megosztották a rendszerprogramokkal, és a felhasználók hozzáférhettek egymás adataihoz. Jelszavas védelmet biztosít az olvasáshoz és íráshoz használható minilemezekhez.
Az EU DOS, EU OS és MBC rendszerrel való kompatibilitás érdekében az OEM főként az ezektől a rendszerektől kölcsönzött külső fájltársítási mechanizmust használta. Bár egy PDO-s program közvetlenül a neve alapján képes megnyitni egy fájlt a lemezen, valójában csak néhány rendszerprogram, például fájlsegédprogramok, szövegszerkesztők stb. voltak elrendezve így. Az alkalmazási programok szokásos mechanizmusa a társítás volt egy lemezen (vagy eszközön) lévő fájl a programban található fájlnévvel a program végrehajtása előtt kiadott FI LEDEF paranccsal (a DD utasítás analógja a JCL nyelvben DOS, OS és MBC esetén). Például a FI LEDEF SYSPRINT DISK TEST LISTING parancs azt jelentette, hogy a következő programok rendszerkimenetét ( SYSPRINT ) a PDO minilemezen egy TEST LISTING nevű fájlba kell írni (és az A1 implikált móddal ).
A CBM-ben végzett interaktív munka kényelme érdekében a legtöbb VMM-, PDO- és rendszerprogram-parancsban, valamint néhány parancsoperandusban megengedett volt a csonkítások és rövidítések használata. Például az OLVASÓ szó beírható az OLVASÓ , OLVASÁS , READ , REA , RE , R rövidítések egyikeként vagy az RDR rövidítésként . A gyakrabban használt parancsok és operandusok rövidebb, legfeljebb egy betű csonkolással rendelkeztek, a ritkábban használtak hosszabbak. A szintaktikai leírásban a csonkolás kötelező részét nagybetűvel vagy aláhúzással írtuk, például: R EADER | RDR .
A CBM 3-as verziójától kezdve a PDO egy nagyon fejlett X EDIT szövegszerkesztőt használt , amelyet különösen a REXX nyelv vezérelt. Az XEDIT-hez készült REXX szkriptek segítségével számos összetett rendszert valósítottak meg, mint például a programok kollektív verziókezelésére szolgáló rendszereket. Ezt követően a XEDIT klónokat (KEDIT, SEDIT, THE) különféle személyi számítógépek operációs rendszereiben implementálták, de nem igazán honosodtak meg, mivel a XEDIT ideológia nagyrészt a mainframe terminálok jellemzőire koncentrált. A THE (The Hessling Editor) jelenleg GPL alatt van terjesztve Unix , z/OS , MS-DOS , OS/2 , Windows , QNX , Amiga , BeOS , Mac OS X platformokon . Érdekes módon a THE z/OS verzióját maga az IBM terjeszti.
Az OEM részeként programokat szállítottak az e-mail kezeléshez. Általában egy valódi számítógép felhasználói között működött az e-mail (az EC számítógépek régebbi modelljénél ez több száz felhasználót jelenthet a terminálokon több kilométeres körzetben), de az akkoriban még érdekességnek számító telekommunikáció segítségével különböző a gépek hálózatba kapcsolhatók. A felhasználók közötti rövid üzenetek azonnali továbbítására szolgáló rendszert is megvalósítottak.
A PDO fő programozási eszközei a REXX szkriptnyelvek és a korábbi EXEC és EXEC2 , assemblerek , fordítók a PL/1 -től , Fortrantól , Cobol -tól voltak . Emellett számos más programozási rendszert is implementáltak az OEM-hez, mint például: Pascal , C , Lisp , Prolog , REDUCE szimbolikus számítási rendszer , PLS (programozási nyelv) rendszerszoftver fejlesztési technológiai nyelv stb.
A REXX nyelvi tolmács először a CBM 3-as verziójában került be az OEM-be. A REXX nyelv ezt követően széles körben elterjedt az OS/2 operációs rendszerben , és számos más operációs rendszerre is implementálták. A CVM-ben a REXX népszerűsége korlátozottabb volt a felhasználók körében, mint az OS/2-ben, mivel a PDO korábbi verzióinak szkriptnyelve, az EXEC2 meglehetősen bőséges lehetőséget biztosított, és ritkábban merült fel az összetettebb REXX nyelv használatának igénye. az OS/2-ben a REXX egyetlen alternatívája a rendkívül korlátozott .bat /.cmd fájlnyelv volt.