OpenVMS - OpenVMS

OpenVMS
Vsi-openvms-logo.svg
DECwindows-openvms-v7.3-1.png
Az OpenVMS V7.3-1 a CDE -alapú DECwindows "New Desktop" GUI -t futtatja
Fejlesztő VMS Software Inc (VSI) (korábban Digital Equipment Corporation , Compaq , Hewlett-Packard )
Beírva Elsősorban C , BLISS , VAX MACRO , DCL . Más nyelveket is használtak.
Működő állapot Jelenlegi
Forrásmodell Zárt forráskódú , nyílt forráskódú összetevőkkel, forrás elérhető
Első kiadás 1977. október 25 . ; 43 évvel ezelőtt ( 1977-10-25 )
Legutolsó kiadás V8.4-2L3 / 2021. április 8 .; 6 hónappal ezelőtt ( 2021-04-08 )
Legújabb előzetes V9.1-A / 2021. szeptember 30 .; 16 napja ( 2021-09-30 )
Marketing cél Kiszolgálók (történelmileg miniszámítógépek , munkaállomások )
Elérhető Angol , japán . Történelmi támogatás a kínai ( hagyományos és egyszerűsített karakterek egyaránt), koreai , thai nyelvek számára .
Frissítési módszer Egyidejű frissítések,
folyamatos frissítések
Csomagkezelő PCSI és VMSINSTAL
Platformok VAX , Alpha , Itanium , x86-64
Kernel típus Monolitikus kernel betölthető modulokkal
Befolyásolt VAXELN , MICA , Windows NT
Befolyásolta RSX-11M
Alapértelmezett
felhasználói felület		 DCL CLI és DECwindows GUI
Engedély Szabadalmazott
Hivatalos honlapján www .vmssoftware .com

Az OpenVMS , amelyet gyakran csak VMS-nek is neveznek , egy többfelhasználós , többprocesszoros virtuális memória- alapú operációs rendszer, amely az időmegosztást , a kötegelt feldolgozást , a tranzakciófeldolgozást és a munkaállomás- alkalmazásokat támogatja . Ez volt az első bejelentette a Digital Equipment Corporation , mint VAX / VMS ( Virtual Address Extension / Virtual Memory System ) mellett VAX-11/780 miniszámítógép 1977 OpenVMS utólag portolták futtatni DEC Alpha rendszerek, az Itanium alapú HPE Integrity Kiszolgálók , és válasszon x86-64 hardvert és hipervizorokat . 2014 óta az OpenVMS -t a VMS Software Inc. (VSI) nevű vállalat fejleszti és támogatja.

Az OpenVMS magas rendelkezésre állást biztosít a klaszterezésen keresztül, és képes elosztani a rendszert több fizikai gépen. Ez lehetővé teszi a fürtözött alkalmazások és adatok folyamatos elérhetőségét az operációs rendszer szoftverének és hardverének karbantartása és frissítése közben, vagy ha egy egész adatközpont megsemmisül. A VMS -klaszter 17 éves üzemidejéről számoltak be. Az OpenVMS -t használó ügyfelek közé tartoznak a bankok és a pénzügyi szolgáltatások, a kórházak és az egészségügy, a távközlési szolgáltatók, a hálózati információs szolgáltatások és az ipari gyártók. Az 1990 -es és 2000 -es években világszerte körülbelül félmillió VMS -rendszer működött.

Történelem

Eredet és névváltozások

A Digital által használt stilizált "VAX/VMS"

1975 áprilisában a Digital Equipment Corporation belekezdett egy Star nevű hardverprojektbe , hogy megtervezzen egy 32 bites virtuális címbővítményt PDP-11 számítógépsorához. Egy kísérő szoftverprojekt, a Starlet kódnevű , 1975 júniusában indult, hogy kifejlesszenek egy teljesen új, RSX-11M alapú operációs rendszert a Star processzorcsalád számára. Ez a két projekt a kezdetektől szorosan integrálódott. Gordon Bell volt a VAX hardver és architektúrájának alelnöke. Roger Tök volt a projekt vezetője a Starlet programot, szoftvermérnök Dave Cutler (aki később vezető fejlesztését a Microsoft „s Windows NT ), Dick Hustvedt és Peter Lipman eljáró műszaki projektvezető, amelyek mindegyike felelősséget egy másik területre az operációs rendszer. A Star és Starlet projektek a VAX-11/780 számítógépben és a VAX/VMS operációs rendszerben tetőztek . A Starlet név fennmaradt a VMS -ben, mint a fő rendszerkönyvtárak neve, köztük STARLET.OLBés STARLET.MLB.

"Albert the Cheshire Cat" kabalája a VAX/VMS -hez , a DECUS VAX SIG

1984 szeptemberében a Digital a MicroVAX és a VAXstation számára létrehozta a MicroVMS nevű VMS dedikált disztribúcióját , amely lényegesen kevesebb memóriával és lemezterülettel rendelkezett, mint az akkori nagyobb VAX rendszerek. A MicroVMS a VAX/VMS -t több készletre osztotta fel, amelyeket az ügyfelek használhatnak a VAX/VMS egy részhalmazának telepítésére az egyedi igényeknek megfelelően. A MicroVMS készleteket TK50 szalagokon és RX50 hajlékonylemezeken adták ki , amelyek megfelelnek a VAX/VMS V4.0 -tól V4.7 -nek. A MicroVMS -t a V5.0 kiadásban visszaolvasztották a VAX/VMS -be, mire a VAX/VMS telepítés személyre szabásának lehetősége elérte azt a pontot, hogy a MicroVMS feleslegessé vált.

1989-től a VMS rövid távú forgalmazását Desktop-VMS néven értékesítették VAXstation rendszerekkel. Egyetlen CD-ROM-ból állt, amely egy köteg VMS -t , DECwindows, DECnet, VAXcluster támogatást és egy nem technikai felhasználók számára tervezett telepítési folyamatot tartalmazott. A Desktop-VMS saját verziószámú sémával rendelkezett, amely V1.0-val kezdődött, ami megfelelt a VAX/VMS V5.x kiadásainak.

1992 júliusában a Digital átnevezte a VAX/VMS -t OpenVMS -re, jelezve, hogy támogatja az olyan "nyílt rendszerek" ipari szabványokat, mint a POSIX és a Unix kompatibilitás, és hogy megszünteti a VAX -kapcsolatot, mivel az Alfa -port elindult. Az OpenVMS nevet először 1992 novemberében használták az OpenVMS AXP V1.0 kiadással. A Digital 1993 júniusában kezdte használni az OpenVMS VAX -ot a VAX/VMS helyett a V6.0 kiadással.

Port a DEC Alpha -hoz

Lásd még: DEC PRISM § Örökség és DEC Alpha § History
"Vernon the Shark" logó az OpenVMS -hez

Az 1980 -as években a Digital a VAX platform és a VMS operációs rendszer felváltását tervezte a PRISM architektúrával és a MICA operációs rendszerrel. Amikor ezeket a projekteket 1988 -ban törölték, egy csapatot állítottak fel a VAX/VMS rendszerek tervezésére, amelyek teljesítménye hasonló a RISC -alapú Unix rendszerekhez. Számos sikertelen kísérlet után egy gyorsabb VAX-kompatibilis processzor megtervezésére a csoport bemutatta a VMS és alkalmazásainak PRISM-alapú RISC architektúrába való átvitelének megvalósíthatóságát. Ez vezetett az Alfa architektúra létrehozásához . A VMS Alpha -ba való átvitelének projektje 1989 -ben kezdődött, és először 1991 elején indult el egy prototípuson, az Alpha EV3 -alapú Alpha Demonstration Unit -en . Az Alpha hardver rendelkezésre állása előtt az Alpha portot kifejlesztették és elindították egy Mannequin nevű emulátoron , végrehajtott számos Alpha utasítást egyéni mikrokódban egy VAX 8800 rendszeren.

A VMS új architektúrába történő átvitelének fő kihívása az volt, hogy a VMS -t és a VAX -ot együtt tervezték, ami azt jelenti, hogy a VMS függ a VAX architektúra bizonyos részleteitől. Továbbá a VMS-kernel, a réteges termékek és az ügyfelek által kifejlesztett alkalmazások jelentős részét a VAX MACRO összeszerelési kódjában valósították meg . A VMS és a VAX architektúra szétválasztásához szükséges változtatások közül néhány:

  • A MACRO-32 fordító létrehozása, amely a VAX MACRO-t magas szintű nyelvként kezelte , és lefordította Alpha objektumkódra .
  • A VAX to Alpha bináris fordító létrehozása , amely VAX Environment Software Translator (VEST) néven ismert, és amely képes volt a VAX futtatható fájlok fordítására, amikor nem volt lehetséges az alfa kód újrafordítása.
  • A VAX architektúra bizonyos alacsony szintű részleteinek emulálása a PALcode-ban , mint például a megszakításkezelés és az atomsor-utasítások. Ez csökkentette a VAX-függő kód mennyiségét, amelyet át kellett írni az Alpha számára.
  • A VMS -fordítók átalakítása, amelyek közül soknak saját egyedi VAX -kódgenerátora volt, egy közös GEM nevű fordítói háttérrendszerre .

Az Alfa VMS portja két külön forráskódkönyvtár létrehozását eredményezte (a VMS fejlesztési környezet vagy VDE néven ismert forráskód -kezelő eszköz alapján ) a VAX és az Alpha számára. Az alfa kódkönyvtár a VAX/VMS kódbázis V5.4-2 körüli pillanatképén alapult. 1992 -ben megjelent az OpenVMS Alpha AXP rendszerekhez készült első verziója , az OpenVMS AXP V1.0 névvel . 1994-ben az OpenVMS V6.1 megjelenésével elérték a VAX és az Alpha változatok (és a verziószám) paritását, ez volt az úgynevezett Functional Equivalence kiadás. Az a döntés, hogy az 1.x verziószámozási folyamot használja az OpenVMS AXP gyártás előtti minőségi kiadásaihoz, zavart okozott egyes ügyfelekben, és nem ismétlődött meg az OpenVMS következő portjain az új platformokra.

Amikor a VMS-t átvitték az Alpha-ra, kezdetben csak 32 bites operációs rendszer maradt. Ez azért történt, hogy visszafelé kompatibilis legyen a 32 bites VAX-hez írt szoftverrel. A 64 bites címzést először a V7.0 kiadásban adták hozzá az Alpha számára. Annak érdekében, hogy a 64 bites kód együttműködhessen a régebbi 32 bites kódokkal, az OpenVMS nem tesz különbséget a 32 bites és a 64 bites végrehajtható fájlok között, hanem lehetővé teszi mind a 32 bites, mind a 64 bites mutatók használatát ugyanazt a kódot. Ezt vegyes mutató támogatásnak nevezik. A 64 bites OpenVMS Alpha kiadások 8TiB (43 bites címtér) maximális virtuális címtér-méretet támogatnak, amelyet az Alpha 21064 és az Alpha 21164 támogat .

Az OpenVMS egyik figyelemre méltó, csak alfa -funkciója az OpenVMS Galaxy volt, amely lehetővé tette egyetlen SMP -kiszolgáló particionálását az OpenVMS több példányának futtatásához. A Galaxy támogatta a dinamikus erőforrás -allokációt a futó partíciókhoz, és a memória megosztását a partíciók között.

Port az Intel Itaniumhoz

"Swoosh" logó, amelyet a HP használ az OpenVMS -hez

2001-ben, mielőtt a Hewlett-Packard megvásárolta , a Compaq bejelentette az OpenVMS portját az Intel Itanium architektúrához. Az Itanium port a Compaq azon döntésének eredménye, hogy felhagy az Alpha architektúra jövőbeni fejlesztésével az akkori új Itanium architektúra elfogadása érdekében. A hordozás 2001 végén kezdődött, és az első rendszerindítás 2003. január 31 -én történt. Az első rendszerindítás egy minimális rendszerkonfiguráció HP i2000 munkaállomáson történő elindításából , SYSTEMfelhasználóként történő bejelentkezésből és a DIRECTORYparancs futtatásából állt. Az OpenVMS Itanium portja támogatja a HPE Integrity Servers bizonyos típusait és konfigurációit . Az Itanium kiadásokat eredetileg HP OpenVMS Industry Standard 64 névvel látták el az integritási kiszolgálók számára , bár az OpenVMS I64 vagy az OpenVMS for Integrity Servers elnevezéseket gyakrabban használják.

Az Itanium portot az OpenVMS Alpha forráskódkönyvtárban közösen fenntartott forráskód használatával hozták létre, feltételes kód és további modulok hozzáadásával, ahol Itaniumra specifikus változtatásokra volt szükség. Míg a VAX és az Alpha architektúrákat kifejezetten az OpenVMS alacsony szintű igényeinek kielégítésére tervezték, az Itanium nem. Ehhez szükség volt az OpenVMS bizonyos architekturális függőségeinek cseréjére vagy szoftverben történő emulálására. A módosítások közül néhány:

  • Az Extensible Firmware Interface (EFI) az OpenVMS rendszerintegrálására szolgál Integrity hardveren, és átveszi a System Reference Manual (SRM) firmware szerepét az Alpha rendszeren. Az OpenVMS -hez az ACPI támogatását is hozzáadták, mivel ez az Integrity platform hardvereszközeinek felfedezésére és kezelésére szolgál.
  • Az Itanium esetében a PALcode for Alpha használatával megvalósított funkciót áthelyezték az OpenVMS kernel szoftver megszakítási szolgáltatások (SWIS) nevű összetevőjébe .
  • Az Itanium port új hívási szabványt fogadott el az Intel Itanium hívási konvencióján alapulva , kiterjesztésekkel az OpenVMS Common Language Environment támogatására. Továbbá lecserélte a VAX-on és az Alpha-n használt OpenVMS-specifikus végrehajtható formátumokat a szabványos végrehajtható és összekötő formátumú (ELF) és DWARF formátumokra.
  • Az IEEE 754 lett az alapértelmezett lebegőpontos formátum, amely felváltja a VAX lebegőpontos formátumot, amely mind a VAX, mind az Alpha architektúrában alapértelmezett volt. A visszafelé való kompatibilitás érdekében lehetőség van az Itanium -on kódot fordítani a VAX lebegőpontos formátumra, de ez szoftver -emuláción alapul.
  • Az operációs rendszert úgy módosították, hogy támogassa az Itaniumon elérhető 50 bites fizikai címzést, lehetővé téve az 1PiB memória kezelését. Az Itanium port egyébként megtartotta a vegyes 32 bites/64 bites mutató architektúrát, amelyet az OpenVMS Alpha V7.0-ban vezettek be.

A VAX – Alpha porthoz hasonlóan elérhetővé vált az Alpha – Itanium bináris fordítója, amely lehetővé tette a felhasználói módú OpenVMS Alpha szoftver portálását az Itaniumba olyan helyzetekben, amikor nem volt lehetséges a forráskód újrafordítása. Ezt a fordítót Alpha Environment Software Translator (AEST) néven ismerik , és támogatta a VAX futtatható fájlok fordítását is, amelyeket már VEST -sel fordítottak.

Két gyártás előtti kiadás, az OpenVMS I64 V8.0 és a V8.1 volt elérhető 2003. június 30-án és 2003. december 18-án. Ezeket a kiadásokat a HP szervezeteinek és harmadik féltől származó szállítóknak szánták, amelyek szoftvercsomagokat hordoznak az OpenVMS I64-be . Az első éles kiadás, a V8.2 2005 februárjában jelent meg. A V8.2 az Alpha számára is megjelent, az OpenVMS későbbi V8.x kiadásai megőrizték az Alpha és Itanium architektúrák közötti paritásosságot.

Port x86-64-re

Amikor a VMS Software Inc. (VSI) bejelentette, hogy megszerezték az OpenVMS operációs rendszer fejlesztési jogait a HP-tól, bejelentették az OpenVMS x86-64 architektúrába való átvitelének szándékát is . A hordozási erőfeszítések egyidejűleg zajlottak a vállalat létrehozásával, valamint a VSI saját Itanium és Alpha OpenVMS V8.4-x kiadásainak fejlesztésével.

Az x86-64 port a HPE és a Dell bizonyos szervereire , valamint bizonyos virtuális gépek hipervizoraira irányul . A kezdeti támogatás a KVM és a VirtualBox volt . A VMware támogatását 2020-ban jelentették be, és a Hyper-V -t jövőbeli célpontként írták le. 2021-ben az x86-64 portot egy Intel Atom alapú egylapos számítógépen mutatták be .

Az x86-64 port ugyanabból a forráskódkönyvtárból épül fel, mint az Alpha és Itanium architektúrák, feltételes fordítást használva az x86-64 platform támogatásához szükséges architektúra-specifikus kód kezeléséhez. Az Alpha és Itanium portokhoz hasonlóan az x86-64 port néhány változtatást hajtott végre az OpenVMS hordozásának és támogatásának egyszerűsítése érdekében az új platformon:

  • A VSI átvette a nyílt forráskódú LLVM fordítói háttérprogramot, amely felváltotta az Alfa és Itanium portokban használt saját GEM háttérprogramot. A GEM IR és az LLVM IR közötti leképezéshez fordítót fejlesztettek ki , amely lehetővé teszi a meglévő fordítói frontendek újrafelhasználását. Ezenkívül a nyílt forráskódú Clang fordítót hivatalosan támogatott C ++ fordítóként alkalmazták az OpenVMS számára x86-64 alatt.
  • Az x86-64 rendszeren az OpenVMS szélesebb körben használja az UEFI-t és az ACPI- t a hardver észleléséhez és inicializálásához rendszerindításkor. Ennek részeként a VMS most egy memórialemezről indul, a hagyományos VMS rendszerindítási mechanizmus helyett - amely a fájlrendszer alapvető megvalósítását tartalmazó rendszerindító illesztőprogramokra támaszkodott , és amely meghatározott hardvereszközökhöz volt kötve. A rendszerindítási folyamat módosításai szükségessé tették a Dump Kernel létrehozását - ez egy másodlagos kernel, amely betöltődik a háttérbe a rendszerindításkor, és akkor hívják fel, ha az OpenVMS -nek összeomlási leíratást kell írnia a lemezre.
  • Az OpenVMS négy hardver által biztosított jogosultsági szintet feltételez , hogy elkülönítse a felhasználói alkalmazásokat és az operációs rendszer különböző részeit. Míg az x86-64 névlegesen négy jogosultsági szintet biztosít, ezek csak kettővel egyenértékűek a VAX, Alpha és Itanium jogosultsági szintjeivel. Az x86-64 porton a kernel szoftver megszakítási szolgáltatások (SWIS) modulja bővül a hiányzó jogosultsági szintek emulálására.
  • Az Itanium porthoz hasonlóan az x86-64 hívó szabványa a platform szabványos hívási konvenciójának kiterjesztése, különösen a System V AMD64 ABI . Az x86-64 architektúra bizonyos jellemzői kihívást jelentettek a megfelelő hívási szabvány meghatározásához. Például az x86-64 általános célú regisztereinek kis száma miatt a MACRO-32 fordítónak az emulált VAX regiszterek tartalmát a memóriában található "álregiszter" struktúrában kell tárolnia, ahelyett, hogy a processzor hardverregisztereit használná. Alfán és Itániumon történik.

Az első rendszerindítást 2019. május 14 -én jelentették be. Ez magában foglalta az OpenVMS rendszerindítását a VirtualBoxon, és a DIRECTORYparancs sikeres futtatását . Később, 2019 -ben bejelentették az első „igazi rendszerindítást” - ez abból állt, hogy az operációs rendszer teljesen szabványos módon indult, a felhasználó bejelentkezett a rendszerbe és futtatta a DIRECTORYparancsot. 2020 májusában a V9.0 Early Adopter's Kit kiadása kis számú ügyfél számára elérhető volt. Ez az VirtuálisBox virtuális gépen futó OpenVMS operációs rendszerből állt, bizonyos korlátozásokkal-ami a legfontosabb, kevés rétegű termék volt elérhető, és a kód csak az x86-64 számára fordítható, keresztirányú fordítók használatával, amelyek Itanium-alapú OpenVMS rendszereken futnak. A V9.0 kiadását követően a VSI havonta vagy kéthavonta frissítéseket adott ki, amelyek további funkciókat és hipervizor -támogatást adtak hozzá. Ezeket V9.0-A és V9.0-H között jelölték. 2021 júniusában a VSI kiadta a V9.1 terepi tesztet, amely elérhető a VSI ügyfelei és partnerei számára. A V9.1 ISO-képként kerül szállításra, amely különféle hipervizorokra és HPE ProLiant DL380 szerverekre telepíthető a V9.1-A kiadással.

Építészet

Az OpenVMS operációs rendszer architektúrája, amely bemutatja a rendszer rétegeit, és azok a hozzáférési módok, amelyekben általában futnak

Az OpenVMS operációs rendszer rétegzett architektúrával rendelkezik, amely egy kiváltságos ügyvezetőből , egy parancsnyelv-tolmácsból áll, amely a jogosultságok közepes szintjén fut, valamint a segédprogramokból és a futásidejű könyvtárakból (RTL), amelyek jogosulatlan módban futnak, de potenciálisan magasabb jogosultsági szint, ha erre felhatalmazást kap. A jogosulatlan kód rendszerint rendszergazdai szolgáltatásokon keresztül hívja meg az Executive funkcióit ( más operációs rendszerek rendszerhívásaival egyenértékű ).

Az OpenVMS rétegei és mechanizmusai a VAX architektúra bizonyos jellemzői köré épülnek, többek között:

Ezeket a VAX architektúra-mechanizmusokat az Alpha, Itanium és x86-64 rendszereken valósítják meg, vagy az adott architektúrák megfelelő hardvermechanizmusaihoz való hozzárendeléssel, vagy emulációval ( PALcode- on keresztül Alpha-n, vagy szoftverben Itanium és x86-64-en).

Ügyvezető és kernel

Az OpenVMS Executive a rendszerterületen található kiváltságos kódokat és adatstruktúrákat tartalmazza. Az Executive tovább van osztva a kernel között , amely a kernelhozzáférési módban futó kódból áll, és a kernelen kívüli kevésbé privilegizált kódból, amely a végrehajtó hozzáférési módban fut.

Az Executive komponensek, amelyek végrehajtási hozzáférési módban futnak, magukban foglalják a Rekordkezelési szolgáltatásokat és bizonyos rendszerszolgáltatásokat, például a képaktiválást. A kernel és a végrehajtó hozzáférési módok közötti fő különbség az, hogy az operációs rendszer alapvető adatstruktúráinak többsége végrehajtó módból olvasható, de megköveteli, hogy a rendszermag módját írják be. A végrehajtó módban futó kód tetszés szerint átkapcsolhat kernel módra, ami azt jelenti, hogy a kernel és a végrehajtó mód közötti gát védelmet nyújt a véletlen korrupció ellen, szemben a biztonsági mechanizmussal.

A rendszermag tartalmazza az operációs rendszer alapvető adatstruktúráit (pl. Oldaltáblázatok, I/O adatbázis és ütemezési adatok), valamint az ezeken a struktúrákon működő rutinokat. A rendszermagot általában három fő alrendszerrel írják le: I/O, folyamat- és időmenedzsment, memóriakezelés. Ezenkívül más funkciók, például a logikai névkezelés, a szinkronizálás és a rendszerszolgáltatás -kiosztás is megvalósulnak a rendszermagban.

Végrehajtó struktúra

A VAX/VMS korai verzióiban az ügyvezető kódjának nagy része egyetlen futtatható képhez volt kapcsolva SYS.EXE. A VAX/VMS 5.0 bemutatta a Modular Executive programot , amely az Executive kódot számos végrehajtó képre (más néven execlets ) osztotta fel, amelyeket a rendszerindítás során töltenek be. SYS.EXEmegmaradt, de a rendszer -szolgáltatás feladási vektorokra, a több végrehajtó képen közös adatok statikus memóriahelyeire és néhány alapvető támogatási kódra korlátozódott. Az OpenVMS for Alpha, az Itanium és az x86-64 SYS.EXEesetén felosztásra kerül, SYS$BASE_IMAGE.EXEés SYS$PUBLIC_VECTORS.EXEamelyek tartalmazzák a megosztott memória helyét és a támogatási kódot, valamint a rendszerszolgáltatás feladási logikáját.

Bővítő mechanizmusok

Az OpenVMS lehetővé teszi, hogy a felhasználói mód kódja megfelelő jogosultságokkal váltson végrehajtó vagy kernel módra a, $CMEXECilletve $CMKRNLrendszerszolgáltatások használatával . Ez lehetővé teszi, hogy a rendszerterületen kívüli kód közvetlenül hozzáférjen az ügyvezető rutinjaihoz és rendszerszolgáltatásaihoz. Amellett, hogy harmadik felek kiterjesztéseit engedélyezi az operációs rendszerhez, a privilegizált képeket az alapvető operációs rendszer segédprogramok használják az operációs rendszer adatstruktúráinak dokumentálatlan interfészeken keresztüli manipulálására.

Az OpenVMS lehetővé teszi a megosztható képek (azaz megosztott könyvtárak ) jogosultságának megadását is, lehetővé téve a felhasználó által írt rendszerszolgáltatások létrehozását , amelyek privilegizált rutinok, amelyek nem privilegizált programhoz kapcsolhatók. A felhasználó által írt rendszerszolgáltatások ugyanazzal a mechanizmussal hívhatók meg, mint a szokásos rendszerszolgáltatások, ami megakadályozza, hogy a jogosulatlan program megszerezze a privilegizált megosztható kép kódjának jogosultságait. Annak ellenére, amit a név sugallhat, a felhasználó által írt rendszerszolgáltatásokat olyan ritkán használt operációs rendszer-funkciók megvalósítására is használják, mint például a kötetbeillesztés.

Az OpenVMS eszközillesztő felületet biztosít, amely lehetővé teszi az új I/O eszközök támogatását az operációs rendszerhez.

Fájlrendszer

Főbb cikkek: Files-11 és Record Management Services

Az OpenVMS funkciókban gazdag lehetőségeket kínál a fájlkezeléshez. A fájlrendszer tipikus felhasználói és alkalmazásfelülete a Record Management Services (RMS), bár az alkalmazások közvetlenül kapcsolódhatnak a mögöttes fájlrendszerhez a QIO rendszerszolgáltatásokon keresztül . Az RMS több rekordorientált fájlhozzáférési módszert és rekordformátumot támogat (beleértve a rögzített hosszúságot, a változó hosszúságot és az adatfolyam formátumot, ahol a fájl bájtfolyamként van kezelve, hasonlóan a Unixhoz). Az RMS támogatja a távoli fájlhozzáférést a DECnet -en keresztül, és a naplózás opcionális támogatását is .

A VMS által támogatott fájlrendszereket Files-11 On-Disk Structures (ODS) néven emlegetik , amelyek lemezkvótákat , hozzáférés-vezérlési listákat és fájlverziókat biztosítanak . A legjelentősebb szerkezeti szintek az ODS-2 , amely az eredeti VMS fájlrendszer, és az ODS-5 , amely kiterjeszti az ODS-2-t, támogatva a Unicode fájlneveket, a kis- és nagybetűket , a merev hivatkozásokat és a szimbolikus hivatkozásokat . A VMS képes elérni az ISO 9660 CD-ROM-okon és ANSI szalagcímkével ellátott mágnesszalagon lévő fájlokat is .

Mellett az OpenVMS Alpha V7.0 kiadás 1995-ben, digitális kiadott egy log felépített fájlrendszer nevű Spiralog amelynek célja az volt, mint egy potenciális utódját Files-11. A Spiralog opcionális termékként került szállításra, és megszűnt az OpenVMS Alpha 7.2 kiadásakor. A Spiralog abbahagyását számos probléma okozta, beleértve a teljes kötetek kezelésével kapcsolatos problémákat. A Spiralog fejlesztői 1996 -ban kezdtek dolgozni egy új fájlrendszeren, amelyet felfüggesztettek, majd később a VSI 2016 -ban újrakezdett VMS Advanced File System néven (VAFS, nem tévesztendő össze a Digital AdvFS for Tru64 verziójával ). A VAFS már nem jelenik meg a legutóbbi ütemtervekben, ehelyett a VSI tárgyalta a nyílt forráskódú GFS2 fájlrendszer OpenVMS -be történő átvitelét . A Files-11 struktúrák cseréjének egyik fő motivációja az, hogy azok 2TiB kötetre korlátozódnak.

Parancsnyelv tolmács

Az OpenVMS Command Language Interpreter (CLI) parancssori felületet valósít meg az OpenVMS számára; felelős az egyes parancsok végrehajtásáért, valamint a parancskezelési eljárásokért (egyenértékű shell parancsfájlokkal vagy kötegelt fájlokkal ). Az OpenVMS szabványos CLI -je a DIGITAL Command Language , bár más opciók is rendelkezésre állnak.

A Unix shell -ekkel ellentétben , amelyek általában saját elszigetelt folyamatukban futnak, és úgy viselkednek, mint bármely más felhasználói módú program, az OpenVMS CLI -k egy folyamat opcionális összetevői, amelyek az adott folyamat által futtatható végrehajtható lemezképek mellett léteznek. Míg a Unix héj általában futtatható fájlokat futtat a fork-exec használatával külön folyamat létrehozásával , az OpenVMS CLI általában betölti a végrehajtható képet ugyanabba a folyamatba, átadja a vezérlést a képnek, és biztosítja, hogy a vezérlés a kép után újra visszakerüljön a CLI-be kilépett, és hogy a folyamat visszaáll eredeti állapotába. A CLI a LOGINOUTkép privát címeterébe kerül leképezésre a kép végrehajtása révén , amelyet manuálisan vagy bizonyos folyamatszolgáltatások automatikusan végrehajthatnak.

Tekintettel arra, hogy a CLI ugyanabba a címtérbe van betöltve, mint a felhasználói kód, és hogy a CLI felelős a képaktiválás meghívásáért és a kép lejáratásáért, a CLI a felügyeleti hozzáférési módban a folyamat címterébe kerül. Ez azért van, hogy megakadályozzuk a CLI kódjának és adatstruktúráinak véletlen vagy rosszindulatú manipulálását felhasználói módú kóddal.

Jellemzők

A VAXstation 4000 96 -as modellje OpenVMS V6.1, DECwindows Motif és az NCSA Mosaic böngészőt futtat

Felhasználói felületek

A VMS-t eredetileg interaktív használatra és kezelésre tervezték a Digital szöveges videotermináljai , például a VT100 , vagy nyomtatott terminálok, például a DECwriter sorozat segítségével. A VAXstation vonal 1984 -es bevezetése óta a VMS opcionálisan támogatja a grafikus felhasználói felületeket munkaállomásokkal vagy X terminálokkal való használatra .

Parancssori interfészek

Fő cikk: DIGITÁLIS parancsnyelv
OpenVMS Alpha V8.4-2L1, amely a DCL CLI-t mutatja egy terminál munkamenetben

A DIGITAL Command Language az első kiadás óta az OpenVMS elsődleges CLI -ja. A VMS-hez elérhető egyéb hivatalos CLI-k közé tartozik az RSX-11 MCR (csak VAX) és a különböző Unix héjak . A Digital eszközöket biztosított a szövegalapú felhasználói felület alkalmazások létrehozásához - a Form Management System (FMS) és a Terminal Data Management System (TDMS), amelyeket később a DECforms követett . A képernyőkezelési szolgáltatások (SMG $) nevű, Unix átkokkal összehasonlítható, alacsonyabb szintű felület is létezik.

Grafikus felhasználói felületek

A VWS 4.5 a VAX/VMS V5.5-2 tetején fut
DECwindows XUI ablakkezelő a VAX/VMS V5.5-2 tetején

Az évek során a VMS számos különböző grafikus felhasználói felületen és eszközfelületen ment keresztül:

  • A VMS eredeti grafikus felhasználói felülete a VMS Workstation Software (VWS) néven ismert, saját ablakkezelő rendszer volt, amelyet 1984 -ben adtak ki először a VAXstation I -hez . A felhasználói felület (User Interface Services, UIS) nevű API -t tette közzé . A VAX hardverek korlátozott választékán futott.
  • 1989-ben december helyébe VWS új X11 -alapú ablakkezelő rendszer elemzi DECwindows . Először a VAX/VMS V5.1 -ben szerepelt. A DECwindows korai verzióiban az X felhasználói interfész (XUI) nevű szabadalmaztatott eszköztár tetejére épített interfész volt . Egy UISX nevű réteges terméket szállítottak, hogy a VWS/UIS alkalmazások fussanak a DECwindows felett.
  • 1991 -ben a DEC felváltotta az XUI -t a Motif eszköztárral , létrehozva a DECwindows Motif -ot . Ennek eredményeként a Motif Window Manager lett az alapértelmezett DECwindows interfész az OpenVMS V6.0 -ban, bár az XUI ablakkezelő opcióként maradt.
  • 1996 -ban az OpenVMS V7.1 részeként a DEC kiadta az új asztali felületet a DECwindows Motif számára, a Common Desktop Environment alapján . Alfa és Itanium rendszereken továbbra is lehetőség van a régebbi MWM-alapú felhasználói felület ("DECwindows Desktop") kiválasztására bejelentkezéskor. Az új asztalt soha nem sikerült átvinni az OpenVMS VAX kiadásaiba.

A DEC Alpha munkaállomásokon futó VMS -verziók az 1990 -es években támogatják az OpenGL és az Accelerated Graphics Port (AGP) grafikus adaptereket. A VMS támogatja a régebbi grafikus szabványokat is, mint például a GKS és a PHIGS . A DECwindows modern verziói az X.Org Server -en alapulnak .

Fürtözés

Fő cikk: VMScluster

Az OpenVMS támogatja a fürtözést (először VAXcluster , később VMScluster néven ), ahol több rendszer futtatja az operációs rendszer saját példányát, de megosztja a lemeztárolást, a feldolgozást, az elosztott zárkezelőt , a közös felügyeleti és biztonsági tartományt, a munkasorokat és a nyomtatási sorokat. egy egységes rendszer image absztrakció. A rendszereket vagy saját, speciális hardver (Cluster Interconnect) vagy ipari szabványú Ethernet LAN köti össze . Az OpenVMS akár 96 csomópontot támogat egyetlen fürtben, és lehetővé teszi a vegyes architektúrájú klasztereket, ahol a VAX és Alpha rendszerek, vagy az Alpha és Itanium rendszerek együtt élhetnek egyetlen fürtben. A VMS -fürtök lehetővé teszik olyan alkalmazások létrehozását, amelyek képesek ellenállni a fürt egy részének tervezett vagy nem tervezett kimaradásainak.

Hálózatépítés

Fő cikk: DECnet

A Digital DECnet protokollkészlete szorosan integrálva van a VMS -be, lehetővé téve a távoli bejelentkezéseket, valamint átlátható hozzáférést a fájlokhoz, nyomtatókhoz és egyéb erőforrásokhoz a VMS -rendszereken keresztül a hálózaton keresztül. A VMS modern verziói mind a hagyományos Phase IV DECnet protokollt, mind az OSI-kompatibilis Phase V-t (más néven DECnet-Plus ) támogatják . A TCP/IP támogatását az opcionális TCP/IP szolgáltatások biztosítják az OpenVMS rétegzett termékekhez (eredetileg VMS/ULTRIX kapcsolat , majd ULTRIX kommunikációs bővítmények vagy UCX). A TCP/IP Services a BSD hálózati verem OpenVMS portjára épül , és támogatja az olyan általános protokollokat, mint az SSH , DHCP , FTP és SMTP . Tekintettel arra, hogy a hivatalos TCP/IP verem csak 1988 -ban került bevezetésre, és a korai verziók korlátozott szolgáltatáskészlete miatt több harmadik féltől származó TCP/IP verem jött létre a VMS számára. Ezen termékek némelyike ​​aktív fejlesztés alatt áll, mint például a TCPware és a MultiNet .

A Digital értékesített egy PATHWORKS nevű szoftvercsomagot (eredeti nevén Personal Computer Systems Architecture vagy PCSA), amely lehetővé tette az MS-DOS , Microsoft Windows vagy OS/2 operációs rendszert futtató személyi számítógépek , vagy az Apple Macintosh számítógépek terminálként való használatát a VMS rendszerek számára. használja a VMS rendszereket fájlként vagy nyomtatókiszolgálóként. A PATHWORKS a LAN Manager -en alapult, és a DECnet vagy a TCP/IP protokollt támogatta szállítási protokollként. A PATHWORKS -t később átnevezték Advanced Server for OpenVMS -re , és végül az Itanium port idején a Samba VMS -portjára cserélték .

A Digital a Local Area Transport (LAT) protokollt biztosította, amely lehetővé tette a távoli terminálok és nyomtatók csatlakoztatását a VMS -rendszerhez egy terminálkiszolgálón , például a DECserver család egyikén keresztül .

Programozás

A Digital (és utódvállalatai) számos programozási nyelvet biztosított a VMS számára. A VMS -ben hivatalosan támogatott nyelvek, akár jelenlegi, akár korábbi, a következők:

Az OpenVMS figyelemre méltó tulajdonságai közé tartozik a Common Language Environment , a szigorúan meghatározott szabvány, amely meghatározza a függvények és rutinok hívási konvencióit, beleértve a veremeket , regisztereket stb., A programozási nyelvtől függetlenül. Emiatt lehetséges az egyik nyelven (például Fortranban) írt rutin meghívása egy másikból (például COBOL), anélkül, hogy ismernie kellene a célnyelv megvalósítási részleteit. Az OpenVMS maga is különféle nyelveken valósul meg, és a közös nyelvi környezet és a hívó szabvány támogatja ezeket a nyelveket. A Digital létrehozta a Structure Definition Language (SDL) elnevezésű eszközt , amely lehetővé tette adattípus -definíciók generálását különböző nyelvekre egy közös definícióból.

Fejlesztőeszközök

A VAX/VMS dokumentáció "szürke fala", a Living Computers: Museum + Labs webhelyen

A Digital szoftverfejlesztő eszközök gyűjteményét biztosította egy DECset (eredeti nevén VAXset ) nevű réteges termékben . Ez a következőkből állt : nyelvérzékeny szerkesztő (LSE), verzióellenőrző rendszer ( kódkezelő rendszer vagy CMS), építőeszköz (a modulkezelő rendszer vagy MMS), statikus elemző ( forráskód-elemző vagy SCA), profilozó (a teljesítmény- és lefedettség -elemző vagy PCA), valamint egy tesztmenedzser (a digitális tesztkezelő vagy a DTM). Ezenkívül számos szövegszerkesztő is szerepel az operációs rendszerben, beleértve az EDT -t , az EVE -t és a TECO -t .

Az OpenVMS hibakereső támogatja az összes DEC fordítót és számos harmadik fél nyelvét. Lehetővé teszi töréspontok, figyelési pontok és interaktív futásidejű programok hibakeresését parancssor vagy grafikus felhasználói felület segítségével . Egy pár alacsonyabb szintű hibakereső, DELTA és XDELTA , használható a privilegizált kód hibakeresésére a normál alkalmazáskódon kívül.

2019-ben a VSI hivatalosan is támogatta a Visual Studio Code- on alapuló integrált fejlesztési környezetet a VMS-hez . Ez lehetővé teszi a VMS alkalmazások távoli fejlesztését és hibakeresését Microsoft Windows , macOS vagy Linux munkaállomásról.

Adatbázis-kezelés

A Digital számos opcionális adatbázis -terméket hozott létre a VMS számára, amelyek közül néhányat VAX Information Architecture családként forgalmaztak. Ezek a termékek a következők voltak:

  • Rdb - Relációs adatbázis -rendszer, amely eredetileg a saját Relational Data Operator (RDO) lekérdezési felületet használta, de később SQL támogatást kapott.
  • DBMS - adatbáziskezelő rendszer, amely a CODASYL hálózati modellt és az adatmanipulációs nyelvet (DML) használja.
  • Digital Standard MUMPS (DSM)-integrált programozási nyelv és kulcsérték-adatbázis .
  • Common Data Dictionary (CDD) - egy központi adatbázis -séma -lerakat, amely lehetővé tette a sémák megosztását a különböző alkalmazások között, és az adatok meghatározását a különböző programozási nyelvekhez.
  • DATATRIEVE - lekérdezési és jelentési eszköz, amely hozzáférhet az RMS fájlok, valamint az Rdb és DBMS adatbázisok adataihoz.
  • Alkalmazásvezérlő felügyeleti rendszer (ACMS)-Tranzakciófeldolgozó monitor , amely lehetővé teszi alkalmazások létrehozását magas szintű feladatleíró nyelv (TDL) segítségével. A tranzakció egyes lépései megvalósíthatók DCL parancsok vagy Common Language Environment eljárások használatával. A felhasználói felületek megvalósíthatók a TDMS, a DECforms vagy a Digital ALL-IN-1 irodai automatizálási termékével.
  • RALLY , DECadmire - Negyedik generációs programozási nyelvek (4GLs) generálására adatbázist is alkalmazásokhoz. A DECadmire integrálta az ACMS-t, és később támogatást nyújtott a Visual Basic kliens-szerver alkalmazások Windows PC-khez történő előállításához.

1994 -ben a Digital eladta az Rdb -t, a DBMS -t és a CDD -t az Oracle -nek , ahol továbbra is aktív fejlesztés alatt állnak. 1995 -ben a Digital eladta a DSM -et az InterSystems -nek , akik átnevezték Open M -re , és végül felváltották a Caché termékükre.

Az OpenVMS harmadik féltől származó adatbázis-kezelő rendszerei például a MariaDB , a Mimer SQL és a System 1032 .

Biztonság

Az OpenVMS különféle biztonsági szolgáltatásokat és mechanizmusokat kínál, beleértve a biztonsági azonosítókat, az erőforrás -azonosítókat, az alrendszer -azonosítókat, az ACL -eket , a behatolásérzékelést, valamint a részletes biztonsági ellenőrzést és riasztásokat. A specifikus verziókat a Trusted Computer System Evaluation Criteria C2 osztályban értékelték , és a SEVMS biztonság továbbfejlesztett kiadásával a B1 osztályban. Az OpenVMS rendelkezik ITSEC E3 minősítéssel is (lásd NCSC és Common Criteria ). A jelszavak kivonatolása a Purdy Polynomial használatával történik .

Sebezhetőségek

  • Korai változatai VMS között számos privilegizált felhasználói fiókok (beleértve SYSTEM, FIELD, SYSTESTés DECNET) az alapértelmezett jelszavakat, amelyek gyakran nem változtak a rendszergazdák. Számos számítógépes férgek a VMS -hez, köztük a WANK féreg és a Mikulás féreg kihasználták ezeket az alapértelmezett jelszavakat, hogy hozzáférjenek a DECnet hálózatok csomópontjaihoz. Ezt a kérdést is leírták Clifford Stoll az a kakukk tojás , mint olyan eszközt, amely Markus Hess szerzett jogosulatlan hozzáférést VAX / VMS rendszereket. A V5.0 verzióban az alapértelmezett jelszavakat eltávolították, és kötelezővé vált a jelszavak megadása ezekhez a fiókokhoz a rendszer beállításakor.
  • A 33 éves sebezhetőségét VMS VAX és Alpha-ben fedezték fel 2017-ben, és a hozzárendelt CVE ID CVE - 2017-17482 . Az érintett platformokon ez a biztonsági rés lehetővé tette, hogy a DCL parancssorhoz hozzáférő támadó kiváltsági támadást hajtson végre . A biztonsági rés egy puffertúlcsordulási hiba kiaknázásán alapul a DCL parancsfeldolgozási kódban, a felhasználó azon képességében, hogy megszakítsa a futó képet ( végrehajtható program ) a DCL paranccsal , CTRL/Yés visszatérjen arra, valamint arra, hogy a DCL megtartja a megszakított kép jogosultságait. . A puffer túlcsordulási hibája lehetővé tette a shellcode végrehajtását egy megszakított kép jogosultságaival. Ezt a támadó fiókjánál magasabb jogosultságokkal telepített képpel együtt lehet használni a rendszer biztonságának megkerülésére.

Platformok közötti kompatibilitás

A VAX/VMS eredetileg tartalmazott egy RSX-11M kompatibilitási réteget, az RSX Application Migration Executive (RSX AME) nevet, amely lehetővé tette, hogy a felhasználói módú RSX-11M szoftvert módosítatlanul futtassák a VMS tetején. Ez a VAX-11 processzorokban megvalósított PDP-11 kompatibilitási módra támaszkodott . Az RSX AME fontos szerepet játszott a VAX/VMS korai verzióiban, amelyek újrahasználtak bizonyos RSX-11M felhasználói térbeli segédprogramokat a natív VAX verziók kifejlesztése előtt. Ez megszűnt a VAX/VMS V3.0 -ban, amikor az összes kompatibilitási mód segédprogramját natív implementációkra cserélték le. A VAX/VMS V4.0-ban az RSX AME-t eltávolították az alaprendszerből, és egy opcionális VAX-11 RSX nevű réteges termékre cserélték , amely szoftver-emulációra támaszkodva futtatta a PDP-11 kódot az újabb VAX processzorokon. Az RTEM- kompatibilitási réteg VAX portja RT-11 alkalmazásokhoz szintén rendelkezésre állt a Digital-tól.

Különféle hivatalos Unix és POSIX kompatibilitási rétegeket hoztak létre a VMS számára. Az első a DEC/Shell volt - ez egy rétegzett termék, amely a 7. verziójú Unix Bourne héj portjából és számos más Unix segédprogramból állt a VAX/VMS rendszerbe. 1992 -ben a Digital kiadta a POSIX for OpenVMS réteges terméket, amely tartalmazott egy héjat a Korn Shell alapján . A POSIX for OpenVMS -t később a nyílt forráskódú GNV ( GNU nem VMS) projekt váltotta fel, amely 2002 -ben került először az OpenVMS adathordozóra. Más GNU -eszközök között a GNV tartalmazza a Bash shell VMS -be való portját . Példák a harmadik féltől származó Unix kompatibilitási rétegekre a VMS -hez az Eunice .

Digitális licencű SoftPC (és később SoftWindows), és réteges termékként értékesítette mind a VAX, mind az Alpha architektúrához, lehetővé téve a Windows és a DOS alkalmazások VMS -en való futtatását.

1995-ben a Digital bejelentette az Affinity for OpenVMS (más néven NT Affinity ) nevű programot, amely lehetővé tette, hogy az OpenVMS a Windows NT kliens-szerver alkalmazások perzisztencia rétegeként szolgáljon . Ennek a kezdeményezésnek a részeként a Distributed Component Object Model (DCOM) megvalósítását hozzáadták az OpenVMS Alpha-hoz, amely először a V7.2-1 kiadásban jelent meg.

Nyílt forráskódú alkalmazások

Az OpenVMS -be portolt néhány nyílt forráskódú alkalmazás a következőket tartalmazza:

Számos közösségi projekt létezik a nyílt forráskódú szoftverek VMS-be való portolására, beleértve a VMS-portokat és a GNV-t (a GNU Not VMS).

Hobbi programok

1997-ben az OpenVMS és számos réteges termék ingyenesen elérhetővé vált hobbista, nem kereskedelmi használatra az OpenVMS Hobbyist Program részeként . Azóta több OpenVMS szoftvert gyártó cég tette elérhetővé termékeit, például a Process Software. Az x86-64 port előtt az OpenVMS futtatására alkalmas hardverek kora és költsége az emulátorokat , mint például a SIMH-t , gyakori választássá tette a hobbiszervezők számára.

2020 márciusában a HPE bejelentette az OpenVMS Hobbyist Program befejezését. Ezt követte a VSI 2020 áprilisában bejelentett közösségi licencprogramja (CLP), amelyet a HPE Hobbyist Program helyettesítésére szántak. A CLP 2020 júliusában indult, és engedélyeket biztosít a VSI OpenVMS Alpha és Integrity rendszereken történő kiadásokhoz. Az OpenVMS x86-64 licencek elérhetővé válnak, amikor stabil verzió jelenik meg ehhez az architektúrához. Az OpenVMS for VAX nem tartozik a CLP hatálya alá, mivel az OpenVMS VAX nem rendelkezik VSI kiadásokkal, és a régi verziók továbbra is a HPE tulajdonában vannak.

Befolyás

A nyolcvanas években a PRISM architektúra MICA operációs rendszerét a VMS későbbi utódjának szánták. A MICA -t úgy tervezték, hogy fenntartsa a visszafelé való kompatibilitást a VMS alkalmazásokkal, miközben támogatja az Ultrix alkalmazásokat ugyanazon kernel tetején. A MICA -t végül a PRISM platform többi részével együtt törölték, így Dave Cutler elhagyta a Digital -t a Microsoft számára. A Microsoftnál Cutler vezette a Windows NT operációs rendszer megalkotását , amelyet nagymértékben inspirált a MICA architektúrája. Ennek eredményeként, a VMS tekinthető őse Windows NT együtt RSX-11 , VAXELN és MICA és sok hasonlóság áll fenn a VMS és NT. Ezt az utódvonalat világossá teszi Cutler előszava Helen Custer "Inside Windows NT" című művében.

A FreeVMS nevű, mára megszűnt projekt nyílt forráskódú operációs rendszert próbált kifejleszteni a VMS-egyezményeknek megfelelően. A FreeVMS az L4 mikrokernelre épült, és támogatta az x86-64 architektúrát. A VMS mikrokernel-alapú architektúrával történő megvalósítását vizsgáló korábbi munkákat a DEC alkalmazottai korábban prototípus-készítési feladatként vállalták a Carnegie Mellon Egyetem segítségével, a VAXstation 3100 hardverhez átvitt Mach 3.0 mikrokernel felhasználásával , multiserver architekturális modell alkalmazásával.

Egy nem hivatalos származék VAX / VMS nevű MOS VP ( orosz : Многофункциональная операционная система с виртуальной памятью, МОС ВП , világít  "multifunkciós operációs rendszer virtuális memória) hoztak létre a Szovjetunió 1980-as években az SM 1700 sorában VAX klón hardver. A fő különbség a MOS VP és a hivatalos digitális kiadások fordítása volt a parancs, az üzenetek és a dokumentáció orosz és támogatja a cirill betűs segítségével KOI-8 kódolást. A MicroVMS hasonlóan módosított származékait MicroMOS VP ( oroszul : МикроМОС ВП ) vagy MOS-32M ( oroszul : МОС-32М ) néven is létrehozták.

Főbb kiadási idővonal

Változat Eladó Kiadási dátum Életvégi dátum Megjegyzések
Régi, már nem karbantartott verzió: X0.5 DECEMBER 1977 vége ? Az első verziót szállították a vásárlóknak
Régi, már nem karbantartott verzió: V1.0 1978. augusztus ? Első produkciós kiadás
Régi, már nem karbantartott verzió: V2.0 1980. április ? VAX-11/750 . Új segédprogramok, beleértve az EDT -t .
Régi, már nem karbantartott verzió: V3.0 1982. április ? VAX-11/730 , VAX-11/725 , VAX-11/782 , ASMP
Régi, már nem karbantartott verzió: V4.0 1984. szeptember ? VAX 8600 , MicroVMS, VAX -klaszterek
Régi, már nem karbantartott verzió: V5.0 1988. április ? VAX 6000 , SMP , LMF, Modular Executive
Régi, már nem karbantartott verzió: V1.0 AXP 1992. november ? Első kiadás az Alpha számára
Régi, már nem karbantartott verzió: V6.0 1993. június ? VAX 7000/10000 , TCSEC C2 megfelelőség
Régi, már nem karbantartott verzió: V6.1 1994. április ? A VAX és az Alpha verziószámok egyesítése
Régi, már nem karbantartott verzió: V7.0 1995. december 1998. március 64 bites címzés Alpha, Fast Path I/O rendszeren
Régi, már nem karbantartott verzió: V7.3 Compaq 2001. június 2012. december A VAX utolsó kiadása
Régi, már nem karbantartott verzió: V8.0 HP 2003. június 2003. december Értékelési kiadás az Integrity Servers számára
Régi, már nem karbantartott verzió: V8.2 2005. február 2014. április Gyártási kiadás az Integrity és az Alpha számára
Régi, már nem karbantartott verzió: V8.4 2010. június 2020 december Támogatja a HPVM -t , a TCP/IP -n keresztüli fürtöket
Régebbi verzió, még mindig karbantartva: V8.4-1H1 VSI 2015. május 2022 december Poulson processzorok támogatása
Régebbi verzió, még mindig karbantartva: V8.4-2L1 2016. szeptember 2024. december Az OpenSSL frissítve 1.0.2 -re
2017. január TBA Az Alpha első kiadása a VSI -től
Régebbi verzió, még mindig karbantartva: V8.4-2L2 2017. július TBA Az Alpha utolsó kiadása
Jelenlegi stabil verzió: V8.4-2L3 2021 április 2028. december Végső kiadás az Integrity Servers számára
Régi, már nem karbantartott verzió: V9.0 2020 május 2021. június x86-64 Korai elfogadó készlet
Egy jövőbeli kiadás legújabb előzetes verziója: V9.1 2021. június H2 2021 x86-64 Terepi teszt
Jövőbeni megjelenés: V9.2 2022 április 2028. december x86-64 Korlátozott gyártási kiadás
Jövőbeni megjelenés: V9.2-1 2022. november 2029. december x86-64 Éles kiadás
Jövőbeni megjelenés: V9.2-2 2023 TBA Továbbfejlesztett klaszterbiztonság
Legenda:
Régi verzió
Régebbi verzió, még mindig karbantartva
Legújabb verzió
A legújabb előzetes verzió
Jövőbeni megjelenés

Lásd még

Hivatkozások

További irodalom

Külső linkek