OpenVMS - OpenVMS

OpenVMS

OpenVMS V7.3-1 mit der CDE- basierten DECwindows "New Desktop" GUI
Entwickler	VMS Software Inc (VSI) (vormals Digital Equipment Corporation , Compaq , Hewlett-Packard )
Geschrieben in	In erster Linie C , BLISS , VAX MACRO , DCL . Es werden auch andere Sprachen verwendet.
Arbeitszustand	Strom
Quellmodell	Closed-Source mit Open-Source- Komponenten, Quelle verfügbar
Erstveröffentlichung	25. Oktober 1977 ; Vor 43 Jahren ( 1977-10-25 )
Neueste Erscheinung	V8.4-2L3 / 8. April 2021 ; vor 6 Monaten ( 2021-04-08 )
Letzte Vorschau	V9.1-A / 30.09.2021 ; Vor 16 Tagen ( 2021-09-30 )
Marketingziel	Server (historisch Minicomputer , Workstations )
Verfügbar in	Englisch , Japanisch . Historische Unterstützung für Chinesisch (sowohl traditionelle als auch vereinfachte Zeichen), Koreanisch , Thai .
Update-Methode	Gleichzeitige Upgrades, fortlaufende Upgrades
Paket-Manager	PCSI und VMSINSTAL
Plattformen	VAX , Alpha , Itanium , x86-64
Kernel- Typ	Monolithischer Kernel mit ladbaren Modulen
Beeinflusst	VAXELN , MICA , Windows NT
Beeinflusst von	RSX-11M
Standard - Benutzeroberfläche	DCL- CLI und DECwindows- GUI
Lizenz	Proprietär
Offizielle Website	www .vmssoftware .com

OpenVMS , die oft als nur VMS , ist ein Multi-User , Multiprozessing virtuelle Speicher -basierten Betriebssystem entwickelt , um Unterstützung Time-Sharing , Stapelverarbeitung , Transaktionsverarbeitung und Workstation - Anwendungen. Es wurde erstmals 1977 von der Digital Equipment Corporation als VAX/VMS ( Virtual Address eXtension/Virtual Memory System ) neben dem VAX-11/780- Minicomputer angekündigt . OpenVMS wurde anschließend für die Ausführung auf DEC Alpha- Systemen, der Itanium- basierten HPE Integrity . portiert Server und wählen Sie x86-64- Hardware und Hypervisoren aus . Seit 2014 wird OpenVMS von einem Unternehmen namens VMS Software Inc. (VSI) entwickelt und unterstützt.

OpenVMS bietet hohe Verfügbarkeit durch Clustering und die Möglichkeit, das System auf mehrere physische Maschinen zu verteilen. Dadurch können geclusterte Anwendungen und Daten kontinuierlich verfügbar bleiben, während Software- und Hardwarewartungen und Upgrades des Betriebssystems durchgeführt werden oder wenn ein ganzes Rechenzentrum zerstört wird. VMS-Cluster-Betriebszeiten von 17 Jahren wurden gemeldet. Zu den Kunden, die OpenVMS verwenden, gehören Banken und Finanzdienstleister, Krankenhäuser und das Gesundheitswesen, Telekommunikationsbetreiber, Netzwerkinformationsdienste und industrielle Hersteller. In den 1990er und 2000er Jahren waren weltweit etwa eine halbe Million VMS-Systeme in Betrieb.

Geschichte

Herkunft und Namensänderungen

Stilisiertes "VAX/VMS" verwendet von Digital

Im April 1975 startete die Digital Equipment Corporation ein Hardwareprojekt mit dem Codenamen Star , um eine virtuelle 32-Bit- Adresserweiterung für ihre PDP-11- Computerlinie zu entwickeln. Ein begleitendes Softwareprojekt mit dem Codenamen Starlet wurde im Juni 1975 gestartet, um ein völlig neues Betriebssystem basierend auf RSX-11M für die Star-Prozessorfamilie zu entwickeln. Diese beiden Projekte waren von Anfang an eng miteinander verbunden. Gordon Bell war der VP Lead für die VAX-Hardware und deren Architektur. Roger Gourd war die Projektleitung für das Starlet Programm, mit Software - Ingenieuren Dave Cutler (wer würde später führen Entwicklung von Microsoft ‚s Windows NT ), Dick Hustvedt und Peter Lipman als den technischen Projektleiter handeln, von denen jede Verantwortung für einen anderen Bereich des Betriebssystems. Die Projekte Star und Starlet gipfelten im VAX-11/780- Computer und dem VAX/VMS-Betriebssystem. Der Name Starlet überlebte in VMS als Name mehrerer der wichtigsten Systembibliotheken, einschließlich STARLET.OLBund STARLET.MLB.

Maskottchen "Albert the Cheshire Cat" für VAX/VMS, verwendet von der DECUS VAX SIG

Im September 1984 erstellte Digital eine dedizierte VMS-Distribution namens MicroVMS für MicroVAX und VAXstation , die deutlich weniger Arbeitsspeicher und Festplattenspeicher hatte als größere VAX-Systeme der damaligen Zeit. MicroVMS teilt VAX/VMS in mehrere Kits auf, mit denen ein Kunde eine auf seine spezifischen Anforderungen zugeschnittene Untergruppe von VAX/VMS installieren kann. MicroVMS-Kits wurden auf TK50- Bändern und RX50-Disketten veröffentlicht, die VAX/VMS V4.0 bis V4.7 entsprechen. MicroVMS wurde in der Version V5.0 wieder mit VAX/VMS zusammengeführt. Zu diesem Zeitpunkt war die Möglichkeit, eine VAX/VMS-Installation anzupassen, so weit fortgeschritten, dass MicroVMS überflüssig wurde.

Ab 1989 wurde eine kurzlebige VMS-Distribution namens Desktop-VMS mit VAXstation- Systemen verkauft. Es bestand aus einer einzelnen CD-ROM mit einem Bündel von VMS, DECwindows, DECnet, VAXcluster-Unterstützung und einem Setup-Prozess für nicht-technische Benutzer. Desktop-VMS hatte ab V1.0 ein eigenes Versionsschema, das den V5.x-Releases von VAX/VMS entsprach.

Im Juli 1992 benannte Digital VAX/VMS in OpenVMS um, als Zeichen für seine Unterstützung von Industriestandards für "offene Systeme" wie POSIX- und Unix- Kompatibilität und um die VAX-Verbindung zu trennen, da die Portierung auf Alpha im Gange war. Der Name OpenVMS wurde erstmals mit der Version OpenVMS AXP V1.0 im November 1992 verwendet. Digital begann mit der Version V6.0 im Juni 1993, OpenVMS VAX anstelle von VAX/VMS zu verwenden.

Port nach DEC Alpha

"Vernon the Shark"-Logo für OpenVMS

In den 1980er Jahren plante Digital, die VAX-Plattform und das VMS-Betriebssystem durch die PRISM- Architektur und das MICA- Betriebssystem zu ersetzen. Als diese Projekte 1988 eingestellt wurden, wurde ein Team gebildet, um neue VAX/VMS-Systeme mit vergleichbarer Leistung wie RISC- basierte Unix-Systeme zu entwickeln. Nach mehreren gescheiterten Versuchen, einen schnelleren VAX-kompatiblen Prozessor zu entwickeln, demonstrierte die Gruppe die Machbarkeit der Portierung von VMS und seinen Anwendungen auf eine RISC-Architektur basierend auf PRISM. Dies führte zur Schaffung der Alpha- Architektur. Das Projekt zum Hafen VMS Alpha begann im Jahr 1989, und zuerst auf einem Prototyp gebootet Alpha EV3 -basierte Alpha Demonstration Einheit Anfang 1991. Vor der Verfügbarkeit von Alpha - Hardware wurde das Alpha - Port entwickelt und auf einem gebootet Emulator namens Mannequin , das implementierte viele der Alpha-Befehle in benutzerdefiniertem Mikrocode auf einem VAX 8800- System.

Die größte Herausforderung bei der Portierung von VMS auf eine neue Architektur bestand darin, dass VMS und VAX gemeinsam entworfen wurden, was bedeutet, dass VMS von bestimmten Details der VAX-Architektur abhängig war. Darüber hinaus wurde ein erheblicher Teil des VMS-Kernels, der mehrschichtigen Produkte und vom Kunden entwickelten Anwendungen in VAX MACRO- Assembly-Code implementiert . Einige der Änderungen, die erforderlich waren, um VMS von der VAX-Architektur zu entkoppeln, umfassten:

• Die Entwicklung des MACRO-32- Compilers, der VAX MACRO als Hochsprache behandelte und in Alpha- Objektcode kompilierte .
• Die Erstellung eines VAX-zu-Alpha- Binärübersetzers , bekannt als VAX Environment Software Translator (VEST), der in der Lage war, ausführbare VAX-Dateien zu übersetzen, wenn es nicht möglich war, den Code für Alpha neu zu kompilieren.
• Die Emulation bestimmter Low-Level-Details der VAX-Architektur in PALcode , wie z. B. Interrupt-Handling und atomare Warteschlangenbefehle. Dies verringerte die Menge an VAX-abhängigem Code, der für Alpha neu geschrieben werden musste.
• Die Konvertierung der VMS-Compiler, von denen viele über eigene maßgeschneiderte VAX-Codegeneratoren verfügten, um ein gemeinsames Compiler-Backend namens GEM zu verwenden .

Die VMS-Portierung auf Alpha führte zur Erstellung zweier separater Quellcodebibliotheken (basierend auf einem Quellcodeverwaltungstool, das als VMS Development Environment oder VDE bekannt ist) für VAX und für Alpha. Die Alpha-Codebibliothek basierte auf einem Snapshot der VAX/VMS-Codebasis um V5.4-2. 1992 wurde die erste Version von OpenVMS für Alpha AXP- Systeme mit der Bezeichnung OpenVMS AXP V1.0 veröffentlicht . 1994 wurde mit der Veröffentlichung von OpenVMS V6.1 eine Funktions- (und Versionsnummer-)Parität zwischen den VAX- und Alpha-Varianten erreicht, dies war die sogenannte Funktionale Äquivalenz-Version. Die Entscheidung, den 1.x-Versionsnummerierungsstrom für die Qualitätsvorabversionen von OpenVMS AXP zu verwenden, verursachte bei einigen Kunden Verwirrung und wurde in den nachfolgenden Portierungen von OpenVMS auf neue Plattformen nicht wiederholt.

Als VMS auf Alpha portiert wurde, wurde es zunächst als reines 32-Bit-Betriebssystem belassen. Dies geschah, um die Abwärtskompatibilität mit Software zu gewährleisten, die für den 32-Bit-VAX geschrieben wurde. Die 64-Bit-Adressierung wurde erstmals in der Version V7.0 für Alpha hinzugefügt. Damit 64-Bit-Code mit älterem 32-Bit-Code zusammenarbeiten kann, unterscheidet OpenVMS nicht zwischen ausführbaren 32-Bit- und 64-Bit-Dateien, sondern ermöglicht stattdessen die Verwendung von 32-Bit- und 64-Bit-Zeigern innerhalb der gleiche Code. Dies wird als Unterstützung für gemischte Zeiger bezeichnet. Die 64-Bit-OpenVMS Alpha-Versionen unterstützen eine maximale Größe des virtuellen Adressraums von 8 TiB (ein 43-Bit-Adressraum), was die maximale Größe ist, die von Alpha 21064 und Alpha 21164 unterstützt wird .

Eine der bemerkenswerteren Alpha-only-Funktionen von OpenVMS war OpenVMS Galaxy – die die Partitionierung eines einzelnen SMP-Servers ermöglichte, um mehrere Instanzen von OpenVMS auszuführen. Galaxy unterstützte die dynamische Ressourcenzuweisung zu laufenden Partitionen und die Möglichkeit, Speicher zwischen Partitionen zu teilen.

Port auf Intel Itanium

"Swoosh"-Logo, das von HP für OpenVMS verwendet wird

2001, vor der Übernahme durch Hewlett-Packard , kündigte Compaq die Portierung von OpenVMS auf die Intel Itanium- Architektur an. Die Itanium-Portierung war das Ergebnis der Entscheidung von Compaq, die zukünftige Entwicklung der Alpha-Architektur zugunsten der damals neuen Itanium-Architektur einzustellen. Die Portierung begann Ende 2001 und der erste Bootvorgang erfolgte am 31. Januar 2003. Der erste Bootvorgang bestand aus dem Booten einer minimalen Systemkonfiguration auf einer HP i2000- Workstation, dem Anmelden als SYSTEMBenutzer und dem Ausführen des DIRECTORYBefehls. Der Itanium-Port von OpenVMS unterstützt bestimmte Modelle und Konfigurationen von HPE Integrity Servern . Die Itanium-Versionen hießen ursprünglich HP OpenVMS Industry Standard 64 for Integrity Servers , obwohl die Namen OpenVMS I64 oder OpenVMS für Integrity Servers häufiger verwendet werden.

Die Itanium-Portierung wurde unter Verwendung von Quellcode durchgeführt, der in der OpenVMS Alpha-Quellcodebibliothek gemeinsam verwaltet wird, mit dem Hinzufügen von bedingtem Code und zusätzlichen Modulen, wo spezifische Änderungen für Itanium erforderlich waren. Während die VAX- und Alpha-Architekturen speziell entwickelt wurden, um die Low-Level-Anforderungen von OpenVMS zu unterstützen, war dies bei Itanium nicht der Fall. Dafür mussten bestimmte architektonische Abhängigkeiten von OpenVMS ersetzt oder in Software emuliert werden. Einige der Änderungen umfassten:

• Das Extensible Firmware Interface (EFI) wird zum Booten von OpenVMS auf Integrity-Hardware verwendet und übernimmt die Rolle der System Reference Manual (SRM)-Firmware auf Alpha. OpenVMS wurde auch Unterstützung für ACPI hinzugefügt, da dies zum Erkennen und Verwalten von Hardwaregeräten auf der Integrity-Plattform verwendet wird.
• Für Itanium wurde die Funktionalität, die mit PALcode für Alpha implementiert wurde, in eine Komponente des OpenVMS-Kernels namens Software Interrupt Services (SWIS) verlagert.
• Der Itanium-Port hat einen neuen Anrufstandard basierend auf Intels Itanium- Anrufkonvention mit Erweiterungen zur Unterstützung der OpenVMS Common Language Environment übernommen. Darüber hinaus wurden die OpenVMS-spezifischen ausführbaren Formate, die auf VAX und Alpha verwendet werden, durch die Standardformate Executable and Linking Format (ELF) und DWARF ersetzt .
• IEEE 754 wurde als Standard-Gleitkommaformat übernommen und ersetzt das VAX-Gleitkommaformat, das sowohl auf der VAX- als auch auf der Alpha-Architektur der Standard war. Aus Gründen der Abwärtskompatibilität ist es möglich, Code auf Itanium zu kompilieren, um das VAX-Gleitkommaformat zu verwenden, aber es basiert auf Softwareemulation.
• Das Betriebssystem wurde modifiziert, um die auf Itanium verfügbare physische 50-Bit-Adressierung zu unterstützen, sodass 1 PiB Speicher adressiert werden kann. Der Itanium-Port behielt ansonsten die gemischte 32-Bit/64-Bit-Zeigerarchitektur bei, die in OpenVMS Alpha V7.0 eingeführt wurde.

Wie bei der Portierung von VAX nach Alpha wurde ein Binärübersetzer für Alpha nach Itanium zur Verfügung gestellt, der es ermöglicht, OpenVMS Alpha-Software im Benutzermodus nach Itanium zu portieren, wenn es nicht möglich war, den Quellcode neu zu kompilieren. Dieser Übersetzer ist als Alpha Environment Software Translator (AEST) bekannt und unterstützt auch die Übersetzung von ausführbaren VAX-Dateien, die bereits mit VEST übersetzt wurden.

Zwei Vorproduktionsversionen, OpenVMS I64 V8.0 und V8.1, waren am 30. Juni 2003 und am 18. Dezember 2003 verfügbar. Diese Versionen waren für HP-Organisationen und Drittanbieter gedacht, die an der Portierung von Softwarepaketen auf OpenVMS I64 beteiligt sind . Die erste Produktionsversion, V8.2, wurde im Februar 2005 veröffentlicht. V8.2 wurde auch für Alpha veröffentlicht, nachfolgende V8.x-Versionen von OpenVMS haben die Funktionsparität zwischen den Alpha- und Itanium-Architekturen beibehalten.

Port auf x86-64

Als VMS Software Inc. (VSI) bekannt gab, dass sie sich die Rechte zur Entwicklung des OpenVMS-Betriebssystems von HP gesichert hatten, gaben sie auch ihre Absicht bekannt, OpenVMS auf die x86-64- Architektur zu portieren . Die Portierungsbemühungen liefen gleichzeitig mit der Gründung des Unternehmens sowie der Entwicklung von VSIs eigenen Itanium- und Alpha-Releases von OpenVMS V8.4-x.

Der x86-64-Port ist für bestimmte Server von HPE und Dell sowie für bestimmte Hypervisoren virtueller Maschinen vorgesehen . Die anfängliche Unterstützung war auf KVM und VirtualBox ausgerichtet . Die Unterstützung für VMware wurde 2020 angekündigt und Hyper-V als zukünftiges Ziel beschrieben. Im Jahr 2021 wurde der x86-64-Port auf einem Intel Atom- basierten Single-Board-Computer demonstriert .

Der x86-64-Port wird aus derselben Quellcodebibliothek wie die Alpha- und Itanium-Architekturen erstellt, wobei bedingte Kompilierung verwendet wird, um den architekturspezifischen Code zu verwalten, der zur Unterstützung der x86-64-Plattform erforderlich ist. Wie bei den Alpha- und Itanium-Ports wurden beim x86-64-Port einige Änderungen vorgenommen, um die Portierung und Unterstützung von OpenVMS auf der neuen Plattform zu vereinfachen:

• VSI hat das Open-Source- LLVM- Compiler-Backend übernommen und das proprietäre GEM-Backend ersetzt, das in den Alpha- und Itanium-Ports verwendet wird. Es wurde ein Übersetzer entwickelt, um die GEM IR auf LLVM IR abzubilden , wodurch die bestehenden Compiler-Frontends wiederverwendet werden können. Darüber hinaus wurde der Open-Source- Compiler Clang als offiziell unterstützter C++-Compiler für OpenVMS unter x86-64 übernommen.
• Auf x86-64 verwendet OpenVMS UEFI und ACPI in größerem Umfang , um Hardware beim Booten zu erkennen und zu initialisieren. Als Teil davon wird VMS jetzt von einer Speicherplatte gebootet, anstatt vom traditionellen VMS-Boot-Mechanismus – der auf Boot-Treibern beruhte , die eine grundlegende Implementierung des Dateisystems enthielten und an bestimmte Hardwaregeräte gebunden waren. Die Änderungen am Boot-Prozess erforderten die Erstellung eines Dump-Kernels – dies ist ein sekundärer Kernel, der beim Booten im Hintergrund geladen wird und aufgerufen wird, falls OpenVMS einen Crash-Dump auf die Festplatte schreiben muss.
• OpenVMS geht davon aus, dass vier von der Hardware bereitgestellte Berechtigungsstufen vorhanden sind , um eine Isolierung zwischen Benutzeranwendungen und verschiedenen Teilen des Betriebssystems zu gewährleisten. Obwohl x86-64 nominell vier Berechtigungsstufen bietet, entsprechen sie nur zwei der Berechtigungsstufen auf dem VAX, Alpha und Itanium. Im x86-64-Port wird das Software Interrupt Services (SWIS)-Modul des Kernels erweitert, um die fehlenden Berechtigungsstufen zu emulieren.
• Wie bei der Itanium-Portierung ist der Aufrufstandard für x86-64 eine Erweiterung der Standard-Aufrufkonvention der Plattform, insbesondere der System V AMD64 ABI . Bestimmte Merkmale der x86-64-Architektur stellten Herausforderungen an die Definition eines geeigneten Anrufstandards. Aufgrund der geringen Anzahl von Universalregistern für x86-64 muss der MACRO-32-Compiler beispielsweise den Inhalt der emulierten VAX-Register in einer speicherinternen "Pseudoregister"-Struktur speichern, anstatt die Hardwareregister des Prozessors wie erfolgt auf Alpha und Itanium.

Der erste Bootvorgang wurde am 14. Mai 2019 angekündigt. Dabei wurde OpenVMS auf VirtualBox gebootet und der DIRECTORYBefehl erfolgreich ausgeführt . Später im Jahr 2019 wurde der erste "richtige Boot" angekündigt - dieser bestand aus dem Booten des Betriebssystems auf ganz normale Weise, einem Benutzer, der sich am System anmeldete und den DIRECTORYBefehl ausführte. Im Mai 2020 wurde die Version des V9.0 Early Adopter's Kit einer kleinen Anzahl von Kunden zur Verfügung gestellt. Dies bestand darin, dass das OpenVMS-Betriebssystem in einer VirtualBox-VM mit gewissen Einschränkungen ausgeführt wurde – vor allem waren nur wenige mehrschichtige Produkte verfügbar, und Code kann nur mit Cross-Compilern, die auf Itanium-basierten OpenVMS-Systemen laufen, für x86-64 kompiliert werden. Nach der Veröffentlichung von V9.0 veröffentlichte VSI monatlich oder zweimonatlich eine Reihe von Updates, die zusätzliche Funktionen und Hypervisor-Unterstützung hinzufügten. Diese wurden als V9.0-A bis V9.0-H bezeichnet. Im Juni 2021 hat VSI den V9.1-Feldtest veröffentlicht, der den Kunden und Partnern von VSI zur Verfügung steht. V9.1 wird als ISO-Image geliefert , das auf einer Vielzahl von Hypervisoren und auf HPE ProLiant DL380- Servern ab Version V9.1-A installiert werden kann .

Die Architektur

Die Architektur des OpenVMS-Betriebssystems, die die Schichten des Systems und die Zugriffsmodi, in denen sie normalerweise ausgeführt werden, demonstriert

Das OpenVMS-Betriebssystem hat eine mehrschichtige Architektur, bestehend aus einem privilegierten Executive , einem Command Language Interpreter , der auf einer mittleren Berechtigungsebene ausgeführt wird, und Dienstprogrammen und Laufzeitbibliotheken (RTLs), die in einem unprivilegierten Modus ausgeführt werden, aber möglicherweise unter laufen können eine höhere Berechtigungsstufe, wenn Sie dazu berechtigt sind. Unprivilegierter Code ruft typischerweise die Funktionalität der Exekutive über Systemdienste auf (entspricht Systemaufrufen in anderen Betriebssystemen).

Die Schichten und Mechanismen von OpenVMS basieren auf bestimmten Funktionen der VAX-Architektur, darunter:

• Die Verfügbarkeit von vier Prozessorzugriffsmodi (mit den Namen Kernel , Executive , Supervisor und User , in der Reihenfolge abnehmender Berechtigungen). Jeder Modus hat seinen eigenen Stack, und jede Speicherseite kann Speicherschutz haben, der pro Modus festgelegt wird.
• Ein virtueller Adressraum, der zwischen prozessprivaten Raumabschnitten und Systemraumabschnitten aufgeteilt ist, die allen Prozessen gemeinsam sind.
• 32 Interrupt-Prioritätsstufen, die zur Synchronisation verwendet werden .
• Hardwareunterstützung für die Bereitstellung asynchroner System-Traps an Prozesse.

Diese VAX-Architekturmechanismen werden auf Alpha, Itanium und x86-64 implementiert, indem sie entweder auf entsprechende Hardwaremechanismen auf diesen Architekturen abgebildet werden oder durch Emulation (über PALcode auf Alpha oder in Software auf Itanium und x86-64).

Executive und Kernel

Der OpenVMS Executive umfasst den privilegierten Code und die Datenstrukturen, die sich im Systemraum befinden. Der Executive ist weiter unterteilt in den Kernel , der aus dem Code besteht, der im Kernel-Zugriffsmodus läuft, und dem weniger privilegierten Code außerhalb des Kernels, der im Executive-Zugriffsmodus läuft.

Zu den Komponenten des Executive, die im Executive-Zugriffsmodus ausgeführt werden, gehören die Record Management Services und bestimmte Systemdienste wie die Bildaktivierung. Der Hauptunterschied zwischen dem Kernel- und dem Executive-Zugriffsmodus besteht darin, dass die meisten Kerndatenstrukturen des Betriebssystems aus dem Executive-Modus gelesen werden können, aber in den Kernel-Modus geschrieben werden muss. Code, der im Executive-Modus ausgeführt wird, kann nach Belieben in den Kernel-Modus wechseln, was bedeutet, dass die Barriere zwischen dem Kernel- und dem Executive-Modus als Schutz vor versehentlicher Beschädigung und nicht als Sicherheitsmechanismus gedacht ist.

Der Kernel umfasst die Kerndatenstrukturen des Betriebssystems (zB Seitentabellen, die I/O-Datenbank und Scheduling-Daten) und die Routinen, die auf diesen Strukturen arbeiten. Der Kernel wird typischerweise mit drei Hauptsubsystemen beschrieben: I/O, Prozess- und Zeitmanagement, Speichermanagement. Darüber hinaus sind im Kernel weitere Funktionalitäten wie Logical Name Management, Synchronisation und System Service Dispatch implementiert.

Führungsstruktur

In frühen Versionen von VAX/VMS war der Großteil des Codes von Executive in einem einzigen ausführbaren Image namens SYS.EXE. VAX/VMS 5.0 führte den Modular Executive ein , der den Executive-Code in eine Reihe von Executive-Images (auch als Execlets bekannt ) aufteilt, die während des System-Bootstrap geladen werden. SYS.EXEblieb, wurde aber auf Systemdienst-Dispatch-Vektoren, statische Speicherorte für Daten, die mehreren Executive-Images gemeinsam sind, und einige grundlegende Unterstützungscodes reduziert. Auf OpenVMS für Alpha, Itanium und x86-64 SYS.EXEwird in SYS$BASE_IMAGE.EXEund aufgeteilt SYS$PUBLIC_VECTORS.EXE, die die gemeinsam genutzten Speicherorte und den Support-Code bzw. die Dispatch-Logik des Systemdienstes enthalten.

Erweiterungsmechanismen

OpenVMS ermöglicht es dem Benutzermodus-Code mit entsprechenden Rechten, mit den Systemdiensten $CMEXECund in den Exekutiv- oder Kernelmodus zu wechseln $CMKRNL. Dadurch kann Code außerhalb des Systembereichs direkten Zugriff auf die Routinen und Systemdienste der Exekutive haben. Privileged Images ermöglichen nicht nur Erweiterungen des Betriebssystems durch Drittanbieter, sondern werden auch von Kerndienstprogrammen des Betriebssystems verwendet, um die Datenstrukturen des Betriebssystems über undokumentierte Schnittstellen zu manipulieren.

OpenVMS erlaubt auch Shareable Images (dh Shared Libraries ) zu gewähren, was die Erstellung von benutzerdefinierten Systemdiensten ermöglicht , die privilegierte Routinen sind, die in ein nicht-privilegiertes Programm eingebunden werden können. Vom Benutzer geschriebene Systemdienste werden unter Verwendung des gleichen Mechanismus wie Standardsystemdienste aufgerufen, wodurch verhindert wird, dass das unprivilegierte Programm die Privilegien des Codes im Privileged Shareable Image erhält. Entgegen dem, was der Name vermuten lässt, werden benutzergeschriebene Systemdienste auch verwendet, um selten verwendete Betriebssystemfunktionen wie das Mounten von Datenträgern zu implementieren.

OpenVMS bietet eine Gerätetreiberschnittstelle , die das Hinzufügen neuer E/A-Geräte zum Betriebssystem ermöglicht.

Dateisystem

OpenVMS bietet funktionsreiche Funktionen für die Dateiverwaltung. Die typische Benutzer- und Anwendungsschnittstelle in das Dateisystem sind die Record Management Services (RMS), obwohl Anwendungen über die QIO- Systemdienste direkt mit dem zugrunde liegenden Dateisystem kommunizieren können. RMS unterstützt mehrere datensatzorientierte Dateizugriffsmethoden und Datensatzformate (einschließlich fester Länge, variabler Länge und einem Stream-Format, bei dem die Datei wie ein Bytestrom behandelt wird, ähnlich wie bei Unix). RMS unterstützt auch den Remote-Dateizugriff über DECnet und optional Unterstützung für Journaling .

Die von VMS unterstützten Dateisysteme werden als Files-11 On-Disk Structures (ODS) bezeichnet, die Festplattenkontingente , Zugriffskontrolllisten und Dateiversionsverwaltung bereitstellen . Die wichtigsten Strukturebenen sind ODS-2 , das ursprüngliche VMS-Dateisystem, und ODS-5 , das ODS-2 um Unterstützung für Unicode- Dateinamen, Groß-/Kleinschreibung , Hardlinks und symbolische Links erweitert . VMS kann auch auf Dateien auf ISO 9660- CD-ROMs und Magnetbändern mit ANSI -Bandetiketten zugreifen .

Parallel zur Veröffentlichung von OpenVMS Alpha V7.0 im Jahr 1995 veröffentlichte Digital ein Log-strukturiertes Dateisystem namens Spiralog, das als potenzieller Nachfolger von Files-11 gedacht war. Spiralog wurde als optionales Produkt ausgeliefert und wurde mit der Veröffentlichung von OpenVMS Alpha 7.2 eingestellt. Die Einstellung von Spiralog war auf eine Reihe von Problemen zurückzuführen, darunter Probleme bei der Handhabung vollständiger Mengen. Die Entwickler von Spiralog begannen 1996 mit der Arbeit an einem neuen Dateisystem, das von VSI im Jahr 2016 auf Eis gelegt und später als VMS Advanced File System (VAFS, nicht zu verwechseln mit Digitals AdvFS für Tru64 ) wieder aufgenommen wurde. VAFS erscheint nicht mehr auf aktuellen Roadmaps, und stattdessen hat VSI die Portierung des Open-Source- GFS2- Dateisystems auf OpenVMS diskutiert . Einer der Hauptgründe für das Ersetzen der Files-11-Strukturen ist, dass sie auf 2 TiB-Volumes beschränkt sind.

Kommandosprachen-Interpreter

Ein OpenVMS Command Language Interpreter (CLI) implementiert eine Befehlszeilenschnittstelle für OpenVMS; verantwortlich für die Ausführung einzelner Befehle sowie Befehlsprozeduren (entspricht Shell-Skripten oder Batch-Dateien ). Die Standard-CLI für OpenVMS ist die DIGITAL Command Language , obwohl auch andere Optionen verfügbar sind.

Im Gegensatz zu Unix-Shells , die normalerweise in einem eigenen isolierten Prozess ausgeführt werden und sich wie jedes andere Benutzermodusprogramm verhalten, sind OpenVMS-CLIs eine optionale Komponente eines Prozesses, die neben jedem ausführbaren Image vorhanden ist, das dieser Prozess möglicherweise ausführen kann. Während eine Unix-Shell normalerweise ausführbare Dateien ausführt , indem sie mit fork-exec einen separaten Prozess erstellt, lädt eine OpenVMS-CLI normalerweise das ausführbare Image in denselben Prozess, überträgt die Kontrolle auf das Image und stellt sicher, dass die Kontrolle nach dem Image wieder an die CLI übertragen wird beendet wurde und der Prozess in seinen ursprünglichen Zustand zurückversetzt wird. Eine CLI wird durch die Ausführung des LOGINOUTImages in den privaten Adressraum eines Prozesses abgebildet , die entweder manuell oder automatisch von bestimmten Systemdiensten zur Prozesserstellung ausgeführt werden kann.

Aufgrund der Tatsache, dass die CLI in denselben Adressraum wie der Benutzercode geladen wird und dass die CLI für das Aufrufen der Image-Aktivierung und des Image-Rundowns verantwortlich ist, wird die CLI im Supervisor-Zugriffsmodus in den Prozessadressraum abgebildet. Dies dient dazu, eine versehentliche oder böswillige Manipulation des Codes und der Datenstrukturen der CLI durch Benutzermoduscode zu verhindern.

Merkmale

VAXstation 4000 Modell 96 mit OpenVMS V6.1, DECwindows Motif und dem NCSA Mosaic Browser

Benutzeroberflächen

VMS wurde ursprünglich entwickelt , werden verwendet und verwaltet interaktiv Digital textbasierte mit Videoterminals wie die VT100 oder Hardcopy - Endgeräte wie die DEC - Drucker - Serie. Seit der Einführung der VAXstation- Linie im Jahr 1984 unterstützt VMS optional grafische Benutzeroberflächen für den Einsatz mit Workstations oder X-Terminals .

Befehlszeilenschnittstellen

OpenVMS Alpha V8.4-2L1, zeigt die DCL-CLI in einer Terminalsitzung

Die DIGITAL Command Language dient seit der ersten Version als primäre CLI von OpenVMS. Andere für VMS verfügbare offizielle CLIs sind der RSX-11 MCR (nur VAX) und verschiedene Unix-Shells . Digital bereitgestellte Tools zum Erstellen textbasierter Benutzeroberflächenanwendungen – das Form Management System (FMS) und das Terminal Data Management System (TDMS), später von DECforms abgelöst . Eine niedrigere Schnittstelle namens Screen Management Services (SMG$), vergleichbar mit Unix curses , existiert ebenfalls.

Grafische Benutzeroberflächen

VWS 4.5 läuft auf VAX/VMS V5.5-2

DECwindows XUI Window Manager läuft auf VAX/VMS V5.5-2

Im Laufe der Jahre hat VMS eine Reihe verschiedener GUI-Toolkits und Schnittstellen durchlaufen:

• Die ursprüngliche grafische Benutzeroberfläche für VMS war ein proprietäres Fenstersystem, bekannt als VMS Workstation Software (VWS), das erstmals 1984 für die VAXstation I veröffentlicht wurde. Es stellte eine API namens User Interface Services (UIS) bereit . Es lief auf einer begrenzten Auswahl an VAX-Hardware.
• 1989 ersetzte DEC VWS durch ein neues X11- basiertes Fenstersystem namens DECwindows . Es war erstmals in VAX/VMS V5.1 enthalten. Frühe Versionen von DECwindows verfügten über eine Schnittstelle, die auf einem proprietären Toolkit namens X User Interface (XUI) aufbaute. Ein mehrschichtiges Produkt namens UISX wurde bereitgestellt, damit VWS/UIS-Anwendungen auf DECwindows ausgeführt werden können.
• 1991 ersetzte DEC XUI durch das Motif-Toolkit und schuf DECwindows Motif . Als Ergebnis wurde der Motif Window Manager die Standard-DECwindows-Schnittstelle in OpenVMS V6.0, obwohl der XUI Window Manager als Option blieb.
• 1996 veröffentlichte DEC als Teil von OpenVMS V7.1 die New Desktop- Schnittstelle für DECwindows Motif, die auf Common Desktop Environment basiert . Auf Alpha- und Itanium-Systemen ist es immer noch möglich, beim Login die ältere MWM-basierte Benutzeroberfläche (als "DECwindows Desktop" bezeichnet) auszuwählen. Der New Desktop wurde nie auf die VAX-Versionen von OpenVMS portiert.

Versionen von VMS, die in den 1990er Jahren auf DEC Alpha-Workstations ausgeführt wurden, unterstützten OpenGL- und Accelerated Graphics Port (AGP)-Grafikkarten. VMS bietet auch Unterstützung für ältere Grafikstandards wie GKS und PHIGS . Moderne Versionen von DECwindows basieren auf X.Org Server .

Clustering

OpenVMS unterstützt Clustering (zuerst als VAXcluster und später als VMScluster bezeichnet ), bei dem mehrere Systeme ihre eigene Instanz des Betriebssystems ausführen, sich jedoch den Plattenspeicher, die Verarbeitung, einen verteilten Sperrenmanager , eine gemeinsame Verwaltungs- und Sicherheitsdomäne, Auftragswarteschlangen und Druckwarteschlangen teilen eine einzelne Systembildabstraktion . Die Verbindung der Systeme erfolgt entweder über proprietäre Spezialhardware (Cluster Interconnect) oder ein branchenübliches Ethernet- LAN . OpenVMS unterstützt bis zu 96 Knoten in einem einzelnen Cluster und ermöglicht Cluster mit gemischter Architektur, bei denen VAX- und Alpha-Systeme oder Alpha- und Itanium-Systeme in einem einzigen Cluster koexistieren können. VMS-Cluster ermöglichen die Erstellung von Anwendungen, die geplanten oder ungeplanten Ausfällen eines Teils des Clusters standhalten.

Vernetzung

Die DECnet- Protokollsuite von Digital ist eng in VMS integriert und ermöglicht Remote-Logins sowie transparenten Zugriff auf Dateien, Drucker und andere Ressourcen auf VMS-Systemen über ein Netzwerk. Moderne Versionen von VMS unterstützen sowohl das traditionelle Phase IV DECnet-Protokoll als auch die OSI-kompatible Phase V (auch bekannt als DECnet-Plus ). Unterstützung für TCP/IP wird durch die optionalen TCP/IP-Dienste für OpenVMS- Schichtprodukte bereitgestellt (ursprünglich als VMS/ULTRIX Connection bekannt , dann als ULTRIX Communications Extensions oder UCX). TCP/IP-Dienste basieren auf einer Portierung des BSD- Netzwerkstapels auf OpenVMS, zusammen mit Unterstützung für gängige Protokolle wie SSH , DHCP , FTP und SMTP . Aufgrund der Tatsache, dass der offizielle TCP/IP-Stack erst 1988 eingeführt wurde, und des begrenzten Funktionsumfangs der frühen Versionen wurden mehrere TCP/IP-Stacks von Drittanbietern für VMS erstellt. Einige dieser Produkte befinden sich noch in der aktiven Entwicklung, wie TCPware und MultiNet .

Digital verkaufte ein Softwarepaket namens PATHWORKS (ursprünglich bekannt als Personal Computer Systems Architecture oder PCSA), das es PCs mit MS-DOS , Microsoft Windows oder OS/2 oder dem Apple Macintosh ermöglichte, als Terminal für VMS-Systeme zu dienen oder VMS-Systeme als Datei- oder Druckserver verwenden. PATHWORKS basierte auf LAN Manager und unterstützte entweder DECnet oder TCP/IP als Transportprotokoll. PATHWORKS wurde später in Advanced Server for OpenVMS umbenannt und schließlich zur Zeit der Itanium-Portierung durch einen VMS-Port von Samba ersetzt .

Digital stellte das Local Area Transport (LAT)-Protokoll bereit , das es ermöglichte, entfernte Terminals und Drucker über einen Terminalserver wie einen der DECserver- Familie an ein VMS-System anzuschließen .

Programmierung

Digital (und seine Nachfolgeunternehmen) stellten eine Vielzahl von Programmiersprachen für VMS bereit. Offiziell unterstützte Sprachen auf VMS, entweder aktuell oder historisch, umfassen:

Zu den bemerkenswerten Eigenschaften von OpenVMS gehört das Common Language Environment , ein streng definierter Standard, der Aufrufkonventionen für Funktionen und Routinen festlegt, einschließlich der Verwendung von Stacks , Registern usw., unabhängig von der Programmiersprache. Aus diesem Grund ist es möglich, eine Routine, die in einer Sprache (zB Fortran) geschrieben ist, von einer anderen (zB COBOL) aufzurufen, ohne die Implementierungsdetails der Zielsprache kennen zu müssen. OpenVMS selbst ist in einer Vielzahl verschiedener Sprachen implementiert und die gemeinsame Sprachumgebung und der Aufrufstandard unterstützen das freie Mischen dieser Sprachen. Digital hat ein Tool namens Structure Definition Language (SDL) entwickelt, mit dem Datentypdefinitionen für verschiedene Sprachen aus einer gemeinsamen Definition generiert werden können.

Entwicklungswerkzeuge

Die "Graue Wand" der VAX/VMS-Dokumentation bei Living Computers: Museum + Labs

Digital stellte eine Sammlung von Softwareentwicklungstools in einem mehrschichtigen Produkt namens DECset (ursprünglich VAXset genannt ) bereit . Dieser bestand aus dem Language-Sensitive Editor (LSE), einem Versionskontrollsystem (dem Code Management System oder CMS), einem Build-Tool (dem Module Management System oder MMS), einem statischen Analysator (dem Source Code Analyzer oder SCA), a Profiler (der Performance and Coverage Analyzer oder PCA) sowie ein Testmanager (der Digital Test Manager oder DTM). Darüber hinaus sind eine Reihe von Texteditoren im Betriebssystem enthalten, darunter EDT , EVE und TECO .

Der OpenVMS Debugger unterstützt alle DEC-Compiler und viele Sprachen von Drittanbietern. Es ermöglicht das Debuggen von Breakpoints, Watchpoints und interaktiven Laufzeitprogrammen entweder über eine Befehlszeile oder eine grafische Benutzeroberfläche . Ein Paar untergeordneter Debugger namens DELTA und XDELTA kann zusätzlich zum normalen Anwendungscode zum Debuggen von privilegiertem Code verwendet werden.

Im Jahr 2019 hat VSI eine offiziell unterstützte integrierte Entwicklungsumgebung für VMS basierend auf Visual Studio Code veröffentlicht . Auf diese Weise können VMS-Anwendungen remote von einer Microsoft Windows- , macOS- oder Linux- Workstation aus entwickelt und debuggt werden .

Datenbankmanagement

Digital hat eine Reihe optionaler Datenbankprodukte für VMS entwickelt, von denen einige als VAX Information Architecture- Familie vermarktet wurden . Zu diesen Produkten gehörten:

• Rdb – Ein relationales Datenbanksystem , das ursprünglich die proprietäre Abfrageschnittstelle des relationalen Datenoperators (RDO) verwendete, später jedoch SQL- Unterstützung erhielt.
• DBMS – Ein Datenbankverwaltungssystem, das das CODASYL- Netzwerkmodell und die Data Manipulation Language (DML) verwendet.
• Digital Standard MUMPS (DSM) – eine integrierte Programmiersprache und Schlüsselwertdatenbank .
• Common Data Dictionary (CDD) – ein zentrales Datenbankschema- Repository, das die gemeinsame Nutzung von Schemata zwischen verschiedenen Anwendungen und die Generierung von Datendefinitionen für verschiedene Programmiersprachen ermöglicht.
• DATATRIEVE – ein Abfrage- und Berichtstool, das auf Daten aus RMS-Dateien sowie Rdb- und DBMS-Datenbanken zugreifen kann.
• Application Control Management System (ACMS) – Ein Transaktionsverarbeitungsmonitor , der die Erstellung von Anwendungen mit einer High-Level- Task Description Language (TDL) ermöglicht. Einzelne Schritte einer Transaktion können mithilfe von DCL-Befehlen oder Common Language Environment-Prozeduren implementiert werden. Benutzeroberflächen können mit TDMS, DECforms oder Digitals Büroautomatisierungsprodukt ALL-IN-1 implementiert werden .
• RALLY , DECadmire – Programmiersprachen der vierten Generation (4GLs) zum Generieren datenbankgestützter Anwendungen. DECadmire bietet die Integration mit ACMS und bietet später Unterstützung für die Generierung von Visual Basic- Client-Server- Anwendungen für Windows-PCs.

1994 verkaufte Digital Rdb, DBMS und CDD an Oracle , wo sie weiterhin aktiv weiterentwickelt werden. 1995 verkaufte Digital DSM an InterSystems , das es in Open M umbenannte und schließlich durch sein Caché- Produkt ersetzte .

Beispiele für Datenbankverwaltungssysteme von Drittanbietern für OpenVMS sind MariaDB , Mimer SQL und System 1032 .

Sicherheit

OpenVMS bietet verschiedene Sicherheitsfunktionen und -mechanismen, einschließlich Sicherheitskennungen, Ressourcenkennungen, Subsystemkennungen, ACLs , Einbruchserkennung und detaillierte Sicherheitsprüfungen und Alarme. Bestimmte Versionen, bewertet nach den Trusted Computer System Evaluation Criteria Klasse C2 und mit der SEVMS Security Enhanced Release nach Klasse B1. OpenVMS besitzt auch ein ITSEC E3-Rating (siehe NCSC und Common Criteria ). Passwörter werden mit dem Purdy-Polynom gehasht .

Schwachstellen

• Frühe Versionen von VMS enthielten eine Reihe von privilegierten Benutzerkonten (einschließlich SYSTEM, FIELD, SYSTESTund DECNET) mit Standardkennwörtern, die von Systemmanagern oft unverändert gelassen wurden. Eine Reihe von Computerwürmern für VMS, darunter der WANK-Wurm und der Weihnachtsmann-Wurm, nutzten diese Standardpasswörter aus, um Zugang zu Knoten in DECnet-Netzwerken zu erhalten. Dieses Problem wurde auch von Clifford Stoll in The Cuckoo's Egg als ein Mittel beschrieben, mit dem Markus Hess sich unbefugten Zugriff auf VAX/VMS-Systeme verschaffte. In V5.0 wurden die Standardpasswörter entfernt und es wurde obligatorisch, Passwörter für diese Konten während der Systemeinrichtung anzugeben.
• Eine 33 Jahre alte Schwachstelle in VMS auf VAX und Alpha wurde 2017 entdeckt und mit der CVE-ID CVE - 2017-17482 versehen . Auf den betroffenen Plattformen, erlaubt diese Sicherheitsanfälligkeit einem Angreifer mit Zugriff auf die DCL - Befehlszeile ein durchzuführen privilege escalation Angriff. Die Sicherheitsanfälligkeit beruht auf der Ausnutzung eines Pufferüberlauffehlers im DCL-Befehlsverarbeitungscode, der Möglichkeit für einen Benutzer, ein laufendes Image ( ausführbare Programmdatei ) zu unterbrechen CTRL/Yund zur DCL-Eingabeaufforderung zurückzukehren, und der Tatsache, dass DCL die Berechtigungen des unterbrochenen Images behält . Der Buffer Overflow Bug ermöglichte es, Shellcode mit den Privilegien eines unterbrochenen Images auszuführen . Dies könnte in Verbindung mit einem Image verwendet werden, das mit höheren Rechten als das Konto des Angreifers installiert ist, um die Systemsicherheit zu umgehen.

Plattformübergreifende Kompatibilität

VAX/VMS enthielt ursprünglich eine RSX-11M- Kompatibilitätsschicht namens RSX Application Migration Executive (RSX AME), die es ermöglichte, RSX-11M-Software im Benutzermodus unverändert auf VMS auszuführen. Dies beruhte auf dem in den VAX-11- Prozessoren implementierten PDP-11-Kompatibilitätsmodus . Die RSX AME spielte eine wichtige Rolle bei frühen Versionen von VAX/VMS, die bestimmte RSX-11M-User-Space-Dienstprogramme wiederverwendeten, bevor native VAX-Versionen entwickelt wurden. Dies wurde in VAX/VMS V3.0 eingestellt, als alle Dienstprogramme des Kompatibilitätsmodus durch native Implementierungen ersetzt wurden. In VAX/VMS V4.0 wurde RSX AME aus dem Basissystem entfernt und durch ein optionales mehrschichtiges Produkt namens VAX-11 RSX ersetzt , das auf Softwareemulation beruhte, um PDP-11-Code auf neueren VAX-Prozessoren auszuführen. Ein VAX-Port der RTEM- Kompatibilitätsschicht für RT-11- Anwendungen war auch von Digital erhältlich.

Für VMS wurden verschiedene offizielle Unix- und POSIX- Kompatibilitätsschichten erstellt. Die erste davon war DEC/Shell - ein mehrschichtiges Produkt, das aus der Portierung der Unix- Bourne-Shell der Version 7 und mehreren anderen Unix-Dienstprogrammen auf VAX/VMS bestand. 1992 veröffentlichte Digital das geschichtete Produkt POSIX für OpenVMS , das eine auf der Korn-Shell basierende Shell enthielt . POSIX für OpenVMS wurde später durch das Open-Source- Projekt GNV ( GNU 's not VMS) ersetzt, das erstmals 2002 in OpenVMS-Medien aufgenommen wurde. Neben anderen GNU-Tools enthält GNV eine Portierung der Bash-Shell auf VMS. Beispiele für Unix-Kompatibilitätsschichten von Drittanbietern für VMS sind Eunice .

Digital lizenzierter SoftPC (und später SoftWindows) und verkaufte ihn als mehrschichtiges Produkt sowohl für die VAX- als auch für die Alpha-Architektur, wodurch Windows- und DOS-Anwendungen auf VMS ausgeführt werden können.

1995 kündigte Digital Affinity for OpenVMS (auch bekannt als NT Affinity ) an, das OpenVMS ermöglichen sollte, als Persistenzschicht für Windows NT- Client-Server-Anwendungen zu dienen . Als Teil dieser Initiative wurde OpenVMS Alpha um eine Implementierung des Distributed Component Object Model (DCOM) erweitert, das erstmals in der Version V7.2-1 erschien.

Open-Source-Anwendungen

Einige der Open-Source- Anwendungen, die auf OpenVMS portiert wurden, umfassen:

Es gibt eine Reihe von Community-Projekten, um Open-Source-Software auf VMS zu portieren, einschließlich VMS-Ports und GNV (GNU's Not VMS).

Hobbyprogramme

1997 wurden OpenVMS und eine Reihe von mehrschichtigen Produkten im Rahmen des OpenVMS-Hobbyisten-Programms für Bastler und nicht-kommerzielle Zwecke kostenlos zur Verfügung gestellt . Seitdem stellen mehrere Unternehmen, die OpenVMS-Software herstellen, ihre Produkte unter denselben Bedingungen zur Verfügung, wie beispielsweise Process Software. Vor der x86-64-Portierung machten das Alter und die Kosten der Hardware, die OpenVMS ausführen konnte, Emulatoren wie SIMH zu einer häufigen Wahl für Bastlerinstallationen.

Im März 2020 gab HPE das Ende des OpenVMS-Hobbyisten-Programms bekannt. Es folgte im April 2020 die Ankündigung des Community License Program (CLP) durch VSI , das als Ersatz für das HPE Hobbyist Program gedacht war. Das CLP wurde im Juli 2020 eingeführt und bietet Lizenzen für VSI OpenVMS-Versionen auf Alpha- und Integrity-Systemen. OpenVMS x86-64-Lizenzen werden zur Verfügung gestellt, wenn eine stabile Version für diese Architektur veröffentlicht wird. OpenVMS für VAX wird nicht durch das CLP abgedeckt, da es keine VSI-Versionen von OpenVMS VAX gibt und die alten Versionen noch im Besitz von HPE sind.

Beeinflussen

In den 1980er Jahren sollte das MICA- Betriebssystem für die PRISM-Architektur der spätere Nachfolger von VMS sein. MICA wurde entwickelt, um die Abwärtskompatibilität mit VMS-Anwendungen aufrechtzuerhalten und gleichzeitig Ultrix- Anwendungen auf demselben Kernel zu unterstützen. MICA wurde schließlich zusammen mit dem Rest der PRISM-Plattform eingestellt, was dazu führte, dass Dave Cutler Digital für Microsoft verließ. Bei Microsoft leitete Cutler die Entwicklung des Betriebssystems Windows NT , das stark von der Architektur von MICA inspiriert war. Daher gilt VMS zusammen mit RSX-11 , VAXELN und MICA als Vorfahr von Windows NT , und zwischen VMS und NT bestehen viele Ähnlichkeiten. Diese Abstammung wird in Cutlers Vorwort zu "Inside Windows NT" von Helen Custer deutlich.

Ein inzwischen eingestelltes Projekt namens FreeVMS versuchte, ein Open-Source- Betriebssystem nach VMS-Konventionen zu entwickeln. FreeVMS wurde auf dem L4-Mikrokernel aufgebaut und unterstützte die x86-64- Architektur. Frühere Arbeiten , die Umsetzung von VMS mit einer Mikro - Kernel-basierten Architektur hatten die Untersuchung bisher als Prototyping - Übung von Dezember Mitarbeitern mit Unterstützung unternommen Carnegie Mellon University mit der Mach 3.0 Microkernel auf portierte VAXstation 3100 Hardware, ein Multi - Server - Architekturmodell verabschieden.

Ein inoffizielles Derivat von VAX/VMS namens MOS VP ( russisch : Многофункциональная операционная система с виртуальной памятью , ВП , wörtlich  'Multifunktionales Betriebssystem mit virtuellem Speicher' der Sowjetunion 1700 wurde 1980 das Vs of the Soviet Union ' SM der Linie 1 .700 geschaffen Klonen von Hardware. Der Hauptunterschied zwischen MOS VP und den offiziellen digitalen Versionen war die Übersetzung von Befehlen, Nachrichten und Dokumentation ins Russische und die Unterstützung der kyrillischen Schrift mit KOI-8- Kodierung. Ähnlich modifizierte Derivate von MicroVMS, bekannt als MicroMOS VP ( Russisch : МикроМОС ВП ) oder MOS-32M ( Russisch : МОС-32М ), wurden ebenfalls erstellt.

Zeitleiste für die Hauptversion

Siehe auch

• Vergleich der Betriebssysteme
• Terry Shannon
• Ereignisflagge

Verweise

Weiterlesen

• Erste Schritte mit OpenVMS, Michael D. Duffy, ISBN  1-55558-279-6
• Einführung in OpenVMS, 5. Ausgabe, Lesley Ogilvie Rice, ISBN  1-55558-194-3
• Ruth Goldenberg; Saro Saravanan (1994). OpenVMS AXP Interna und Datenstrukturen: Version 1.5 . Digitale Presse. ISBN 978-1555581206.
• OpenVMS Alpha Interna und Datenstrukturen: Speicherverwaltung, Ruth Goldenberg, ISBN  1-55558-159-5
• OpenVMS Alpha Internals and Data Structures : Scheduling and Process Control : Version 7.0, Ruth Goldenberg, Saro Saravanan, Denise Dumas, ISBN  1-55558-156-0
• VAX/VMS-Interna und Datenstrukturen: Version 5.2 ("IDSM"), Ruth Goldenberg, Saro Saravanan, Denise Dumas, ISBN  1-55558-059-9
• Writing Real Programs in DCL, zweite Auflage, Stephen Hoffman, Paul Anagnostopoulos, ISBN  1-55558-191-9
• Schreiben von OpenVMS Alpha-Gerätetreibern in C, Margie Sherlock, Leonard Szubowicz, ISBN  1-55558-133-1
• OpenVMS Performance Management, Joginder Sethi, ISBN  1-55558-126-9
• Erste Schritte mit OpenVMS System Management, 2. Auflage, David Donald Miller, Stephen Hoffman, Lawrence Baldwin, ISBN  1-55558-243-5
• Das OpenVMS-Benutzerhandbuch, Zweite Ausgabe, Patrick Holmay, ISBN  1-55558-203-6
• Verwendung von DECwindows Motif für OpenVMS, Margie Sherlock, ISBN  1-55558-114-5
• Wayne Sewell (1992). Inside VMS: Das Handbuch für Systemmanager und Systemprogrammierer zu VMS-Interna . Van Nostrand Reinhold. ISBN 0-442-00474-5.
• Der Tramper-Leitfaden zu VMS: eine nicht unterstützte-undokumentierte-kann-jederzeit-weg-gehen-Funktion von VMS, Bruce Ellis, ISBN  1-878956-00-0
• Roland Hughes (Dezember 2006). Das Minimum, das Sie wissen müssen, um ein OpenVMS-Anwendungsentwickler zu sein . ISBN 978-0-9770866-0-3.

Externe Links

• VMS-Software: Aktuelle Roadmap und zukünftige Releases
• VMS-Software: Dokumentation
• VSI Quickspecs & Software Produktbeschreibungen
• VSI OpenVMS-Forum
• Kanal des offiziellen VSI -Kanals auf YouTube
• HPE OpenVMS-Systemdokumentation
• OpenVMS at 20 (1997) an der Wayback Machine (archiviert 2017-07-07), enthält historische Fakten
• 30-jähriges OpenVMS-Jubiläum (2007) auf der Wayback Machine (archiviert am 3. Dezember 2013), enthält historische Fakten
• Hoffmanlabs.org HP OpenVMS FAQ
• Arne Vajhøjs OpenVMS-Bibliographie
• comp.os.vms Usenet-Gruppe , Archive bei Google Groups
• OpenVMS-Konten auf DEC Alpha- , VAX- und IA64- Architektur bei Polarhome
• OpenVMS-Anfänger-FAQ
• Einführende Informationen für neue OpenVMS-Hobbyisten auf Hoffmanlabs.org
• OpenVMS-HILFE-Seiten
• OpenVMS.org an der Wayback Machine (archiviert 2014-08-01)
• OpenVMS Freeware-Sammlung
• OpenVMS Programmer's Corner , hauptsächlich VSI BASIC für OpenVMS- Programme
• OpenVMS Resource Center bei Process Software , OpenVMS FILESERV
• OpenVMS-Webring
• Bei der Wayback-Maschine praktisch unhackbar (archiviert am 15. Juli 2011), DEF CON 9
• OpenVMS-Bewerbungsstatusbericht zum 1. Oktober 2007 (102 Seiten lange Antragstabelle)