Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

20.09.1991 - 

Digitals VAXVMS gegen IBMs System370 (Teil 2)

Über den "Style of Computing" unterschiedlicher DV-Kulturen

Das momentane DV-Szenario ist gekennzeichnet durch die immer rasanter werdende Entwicklung hin zu heterogenen, verteilten und offenen Systemen. Schlüsselworte sind dabei "Interoperabilität" und "Portabilität". Dieser Trend beinhaltet eine immense technologische Herausforderung mit viele Chancen, aber auch einige Stolpersteine. (siehe CW Nr. 25, vom 21. Juni 1991, Seite 37).

Der Autor beschreibt in dem zweiteiligen Artikel die Unterschiedlichkeiten, die allein zwischen den zwei weitverbreiteten Rechner-Welten von DEC und der IBM existieren. Der abschließende zweite Teil befaßt sich mit der Ein-Ausgabeverarbeitung, den generellen Unterscheidungsmerkmalen zwischen dem DEC-VMS- gegenüber dem /370-Betriebssystem und geht auf das /370-Betriebssystem VM und die VAX/VMS-Umgebung ein.

Mit der Vorstellung der /370 Extended Architecture (XA) änderte sich außer der Adressierung auch die Architektur des "Channel Subsystems", welches Teil des I/O-Systems ist. Die prinzipiellen Abläufe sind jedoch im wesentlichen gleichgeblieben. Die wichtigsten Komponenten:

1. Logical IOCS

2. Physical IOCS:

1. I/O Instruktionen

2. I/O Channel

3. Channel Command Word (CCW)

4. Channel Address Word (CAW)

5. Channel Status Word (CSW)

Unter dem Begriff "Logical Input Output Subsystem (LIOCS)" versteht man im System 1370 im allgemeinen die Vorgänge, die während einer Ein- oder Ausgabe nicht unmittelbar von der Hardware durchgeführt werden. Das sind beispielsweise das Verwalten von Ein-, Ausgabe-Warteschlangen, das Blocken, oder Entblocken von Dateien, sowie das Bereitstellen von Daten in der Page 0, also der Hard- und Software-Schnittstelle.

Je nach Betriebssystem oder Systemsoftware gibt es hier unterschiedliche Implementierungen in der /370-Welt. Teile des LIOCS bilden zusammen mit einigen Physical IOCS-Komponenten, sogenannte "I/O-Subroutinen". Diese Subroutinen werden in der VAX/VMS Welt Device Driver" genannt.

Im Gegensatz zu VAX/VMS existieren im /370-Instruktionssatz einige Instruktionen, die sich explizit mit Ein-Ausgabe-Operationen befassen. Die wichtigste ist "Start Input Output (SIO)" (In der XA-Architektur ist SIO durch "Start Subchannel" (SSCH) ersetzt worden).

Eine weitere wichtige Komponente ist der Kanal (Channel). Er ist ein zusätzlicher Prozessor, der sich mit der Ausführung einer Ein-Ausgabe-Anforderung beschäftigt.

Die I/O-Subroutinen steuern die Kanäle eines /370-Systems durch eine eigens dafür definierte Assemblerinstruktion, das "Channel Command Word (CCW)".

Eine Ein-Ausgabe-Anforderung kann aus drei miteinander verketteten Kommandos bestehen. Das erste enthält den "Command Code" für das Einstellen des Zugriffsarms, im zweiten wird der entsprechende Zylinder aufgesucht und im dritten CCW wird dann die Schreib- oder Leseoperation ausgeführt. Dabei werden die einzelnen CCWs über Statusbits miteinander verkettet, so daß man auch von "CCW chains", beziehungsweise "Channel Programs" spricht. Diese Kanalprogramme sind in der Regel Teil der I/O- i Subroutinen des Betriebssystems.

Das "Channel Address Word (CAW)", welches sich in den "Fixed Storage Locations" befindet, enthält die Startadresse eines solchen Kanalprogrammes.

1. Zunächst muß der entsprechende Kanal darüber informiert werden, wo sich das Kanalprogramm befindet. Das heißt, die I/O Subroutine muß die Anfangsadresse der CCW Ketten in das "CAW" übertragen.

2. Die /370-Assemblerinstruktion "SIO" spezifiziert zusammen mit der Einheitenadresse (zum Beispiel einer Platte) den Beginn einer I/O Operation. Beispiel: "SIO 421" (starte I/O für die Einheit 21, Kanal 4)

3. Der Kanal, der nun die Verarbeitung übernimmt, wird über das Channel Address Word zu dem Kanalprogram geleitet und führt diese aus.

4. Die für die Platte 421 zuständige Kontrolleinheit setzt am Ende der Ein-Ausgabe-Operation im "Channel Status Word (CAW)" entsprechende Kontrollinformationen, die von der I/O-Routine ausgewertet werden können.

5. Ein I/O-Interrupt beendet schließlich den Zyklus, so daß die Routine, welche die Ein-Ausgabe angefordert hat, wieder die Kontrolle zurückerhalten kann.

Der auffälligste Unterschied zum System /370 liegt zunächst darin, daß im VAX/VMS-Assembler keine besondere I/O-Instruktion ist. Der Begriff "Kanal" ist zwar auch in VAX/VMS vorhanden, ist aber nicht mit einem /370-Kanal zu verwechseln.

Ein l/O-Kanal in VMS bedeutet einen logischen Softwarepfad von einem Programm zu einer I/O-Einheit. I/O-Kanäle im Sinne des Systems 1370 gibt es im VAX/VMS-System nicht. Die Funktionalität eines 1370-Kanals wird in VAX/VMS durch den "I/O-Bus" und die jeweilige "Control Unit" wahrgenommen.

VAX/VMS kennt zwei Arten von Ein-Ausgabe, welche hauptsächlich von der Geschwindigkeit der involvierten Ein-Ausgabe-Einheit abhängig sind. "Programmed I/O" wird für langsame Einheiten benutzt.

"Direct Memory Access (DMA)" oder auch "Nonprocessor Request I/O (NPR)" wird für schnelle Einheiten, beispielsweise Platten benutzt. VAX-I/O Kontrolleinheiten haben spezielle Kontroll- und Datenregister. Diese Register werden über physikalische Adressen durch den normalen VAX Instruktionssatz angesprochen. Eine Start-Input-Output-Instruktion (SIO) wie im System /370 ist daher nicht notwendig.

Die Anzahl und Bedeutung der Kontroll- und Datenregister variiert je nach Ein-Ausgabe-Einheit. Ein standardisiertes Protokoll, das "Mass Storage Control Protocol (MSCP)", erlaubt es, etwa für alle Plattenlaufwerke dieselbe Input/Output-Schnittstelle zu verwenden.

Beim VAX/VMS Programmed I/O überträgt die CPU jeweils ein Zeichen in das Datenregister der Kontrolleinheit. Das geschieht mit "normalen" Instruktionen, zum Beispiel "MOVB" (move binary) Nachdem beispielsweise das Zeichen gedruckt worden ist, generiert die Kontrolleinheit einen Interrupt, und die CPU kann das nächste Zeichen übertragen. Die Verarbeitung kann zwar mit der Ein-Ausgabe überlappen, jedoch muß jedes einzelne Zeichen von der CPU in das Datenregister übertragen werden Diese Funktionalität ist nicht vergleichbar mit I/O im System /370.

Dagegen ist DMA oder Nonprocessor Request I/O funktional vergleichbar mit der Art und Weise des I/O im System /370. Hier werden ganze Datenblöcke durch die Kontrolleinheit direkt zwischen dem Speicher und der Ein-Ausgabe-Einheit übertragen. Dadurch wird eine wesentlich höhere Übertragungsgeschwindigkeit erreicht.

Bis hierher wurden die wichtigsten Architekturgrundlagen beider Systeme behandelt. Wenden wir uns nun ein wenig genauer den Betriebssystemen zu:

Es folgt die Beschreibung einiger Funktionen und Komponenten, welche integraler Bestandteil von MS sind und in vergleichbarer Implementierung in einem 1370-Betriebssystem nicht oder nur teilweise vorhanden sind, oder als zusätzliche Systemsoftware angeboten werden:

- Das "Librarian Utility" für eigene definierte Online-Help-Funktionen

- VAX/VMS Calling Standards für die Entwicklung eines SW-Moduls aus Quelldateien unterschiedlicher Programmiersprachen

- Decwindows, eine windoworientierte Benutzerschnittstelle, die Zugriffe auf Applikationen erlaubt, welche auf unterschiedlichen Betriebssystemen laufen.

- Distributed Transaction Manager, für verteilte Transaktionen ein "Two Phase Commit Protocol (2PC)" als Betriebssystem-Service zur Verfügung

- Digital Storage Architecture (DSA) die unabhängig von der physikalischen Beschaffenheit etwa einer Platte, eine einheitliche I/O-Schnittstelle zur Verfügung stellt, so daß Plattenwechsel keinen Einfluß auf die SW haben

- Integrierte Netzwerk- und Clusterfähigkeit.

Welches /370-Betriebssystem eignet sich am besten für eine Gegenüberstellung mit VMS? Die größte funktionale Verwandschaft besteht zwischen VMS und VM. Beides sind interaktive Timesharing-Systeme, die einige Ähnlichkeiten aufweisen. Allerdings wurde VM zunächst für einen anderen Zweck entwickelt. Insofern weisen beide Systeme Funktionalitäten auf die in dem jeweils anderen nicht zu finden sind.

Leichter Wechsel auf ein anderes Betriebssystem

So steuert beispielsweise VM die Betriebsmittel des Systems 370 für andere Betriebsysteme, die etwa MVS und/oder VSE. Das heißt, VM schafft für andere /370-Betriebssysteme eine Umgebung, in welcher diese sich so verhalten können, als verfügen sie allein über ein Computersystem, da die im Teil I dieses Artikels beschriebenen /370-Funktionen der Hard und Software-Schnittstelle durch das "VM Control Program (CP)" simuliert werden. Diese Umgebung wird auch "Virtuelle Maschine" genannt. Die Kommunikation mit CP geschieht über eine interaktive Schnittstelle, etwa vergleichbar mit den DCL-Komponenten des VMS, welche für die Systemadministration zur Verfügung stehen. Diese besondere Funktionalität ermöglicht einen leichteren Wechsel von einem /370-Betriebssystem auf ein anderes, da man auf diese Weise in der Umstellungsphase mehrere Betriebssysteme auf einer CPU betreiben kann. Die eigentlichen Funktionen eines interaktiven Systems, wie Dateiverwaltung Editor, Compiler, etc. werden jedoch von einer anderen Komponente des VM, dem "Conversational Monitor System (CMS)" zur Verfügung gestellt und eignen sich daher eher für eine Gegenüberstellung mit VMS.

Gemeinsamkeiten von VM und VMS-Betriebssystemen

Gemeinsamkeiten der VM und VMS-Betriebssysteme:

- Beide Systeme sind interaktive, auf Benutzerfreundlichkeit ausgelegte Multiprocessing Systeme.

- Helpfunktionen stehen durch entsprechende Kommandos oder Funktionstasten zur Verfügung.

- Beide Umgebungen kennen ähnliche Kommandos und Funktionen.

- Mail und Message-Funktionen sind ähnlich

- Batch-Verarbeitung ist möglich

- Beide Systeme stellen eine interaktive Programmentwicklungsumgebung mit "Test und Debug" und Editoren zur Verfügung.

- Benutzer können in beiden Systemen mit verschiedenen Privilegien ausgestattet werden und in verschiedene Benutzerklassen eingeteilt werden. Aus diesem Grund wird sich ein mit VM vertrauter Spezialist relativ schnell an VMS gewöhnen.

Ein wesentlicher Unterschied besteht allerdings darin, daß die VMS-Entwicklungsumgebung einen komfortableren Zugriff der vom System unterstützten 3GL-Sprachen auf Dienste des Betriebssystems bietet. In VM ist das standardmäßig nur im Assembler möglich.

Weitere Unterschiede, die auf den Benutzer wirken, sind die Datei- und Namenskonventionen, sowie die Benutzerumgebungen virtuelle Maschine (VM) und Prozeß (VMS).

Nachdem eine Benutzerkennung - im VM "Userid" im VMS "Account" genannt - ein gerichtet ist, kann die Anmeldung zum System erfolgen. Dies geschieht in VM im "Full Screen Modus". Nachdem der Benutzer seine User-ID und das Paßwort eingegeben hat, wird für ihn eine virtuelle Maschine aufgebaut.

Wenn es sich um einen CMS-Benutzer handelt, dann ist die Umgebung, in der sich der Benutzer nach dem LOGON befindet, in etwa vergleichbar mit einem VMS-Prozeß. Der wesentliche Unterschied ist, daß aufgrund der VM-Philosophie, welche jedem Benutzer eine "eigene Hardware" vorspielt, jede virtuelle CMS-Maschine zunächst eine "Single User" darstellt.

Das CP-Steuerprogramm baut für jede virtuelle Maschine die entsprechenden Seitentabellen (Page Tables) auf, und übernimmt das Verwalten des virtuellen Speichers durch das "Memory Management". Das entspricht dem "Virtual Address Space" Begriff, der im VMS im Zusammenhang mit einem Prozeß genannt wird.

Ebenso wird je virtuelle Maschine eine virtuelle Page 0 (siehe Teil 1 dieses Artikels) aufgebaut, so daß jeweils die Informationen zur Verfügung stehen, welche in der VMS-Terminologie als "Hardware Context" bezeichnet werden.

VMS-Prozeß besteht aus vier Komponenten

Jeder virtuellen Maschine wird durch das CP-Kontrollprogramm ein gewisser Teil auf einer Zeitscheibe zur Verfügung gestellt (Timesharing). Beim Wechsel von einer virtuellen Maschine zur anderen, werden die Informationen, welche im VMS als "Software Context" bezeichnet werden, durch das CP-Kontrollprogramm gesichert. Wie das geschieht, ist ebenfalls im ersten Teil dieses Artikels kurz beschrieben.

Die zu einer "VM virtuellen Maschine" in etwa vergleichbare VMS Einheit ist der "VMS-Prozeß". Dieser besteht aus vier Komponenten:

1. Virtual Address Space

2. Hardware Context (etwa Inhalte der Register, Prozessorstatus)

3. Software Context (Informationen, welche die Ablaufumgehung des Prozesses beschreiben)

4. Image (ablauffähiges Programm mit dem Dateityp .EXE welches einem Filetyp "MODULE" im VM entspricht)

RMS fest in das Betriebssystem eingefügt

Beim "VM Logon", beispielsweise beim "VMS Login" kann jeweils eine Prozedur ausgeführt werden, welche diverse Parameter für die aufzubauende Benutzerumgebung definiert.

Diese Prozedur wird in VM in der Datei PROFILE EXEC definiert. Sie kann CP- und CMS-Kommandos beinhalten, sowie Sprachelemente aus EXEC, EXEC2 oder REXX, die mit DCL vergleichbaren VM-Kommandosprachen, enthalten Diese Sprachelemente werden in der VM-Datei "PROFILE EXEC" definiert. Das VMS-Äquivalent ist die Datei "login.com". VMS-Dateien sind systemweit in einer hierarchischen Struktur organisiert. Diese Struktur besteht aus Verzeichnissen, "Directories", und Dateien und ist vergleichbar mit der Struktur eines Unix oder MS-DOS-Dateisystems.

Der Vergleich zu Unix beziehungsweise MS-DOS gilt jedoch ausschließlich für den Strukturaufbau. Die VMS-Komponente "Record Management System (RMS)" stellt Dienste und Funktionen zur Verfügung, die das Dateisystem erst zu einem voll funktionalen Produktionssystem werden lassen.

Wie die meisten anderen VMS-Komponenten, ist auch RMS fest in das Betriebssystem eingefügt. Die RMS-Dienste werden dem Benutzer über Systemdienste zur Verfügung gestellt.

Die wichtigsten RMS-Funktionen sind:

1. Unterstützung sequentieller, relativer und indizierter Dateien

2. feste und variable Satzlängen

3. Block I/0

4 "File Sharing" Mechanismen wie

- Datei-Zugriffs-Modi

- Satzsperren

- Gemeinsame Pufferbenutzung mehrerer Prozesse

5. Zugriffskontrolle

6 Netzwerk Datei Management Das CMS-Dateisystem bietet:

1. Unterstützung sequentieller Dateien.

2. feste und variable Satzlängen

3. Block I/0.

4. "File Sharing" Mechanismen wie

- Datei-Zugriffs-Modi

- Shared File System ab VMI SP, Release 6

5. Zugriffskontrolle

Vergleichbare Funktionalität zu dem VMS-Dateisystem wird in VM erst durch das Hinzufügen zusätzlicher Komponenten, wie etwa VSAM oder eines Datenbanksystems erreicht.

Im Unterschied zum systemweiten VMS-Dateisystem, entspricht das Minidiskkonzept des CMS, der VM-Philosophie von der Trennung der Benutzer. Ab dem VM-Release 6 gibt es ein "Shared File System", welches etwas anderen Kriterien unterliegt, das Minidiskkonzept jedoch nicht ersetzt. Eine Minidisk ist ein logischer Ausschnitt einer realen Platteneinheit. Für die virtuelle Maschine, die damit arbeitet, wird dieser Ausschnitt durch das CP-Kontrollprogramm so dargestellt, als ob es sich um eine reale Platte handelt. Das heißt, daß eine Minidisk alle Attribute der realen Platte erbt, auf der sie definiert ist.

Die Systemservice-Routine des Systems, welches in einer virtuellen Maschine läuft, in diesem Fall ist das CMS, behandelt eine Minidisk wie eine reale Platte.

Der Zugriff auf eine Minidisk eines anderen Benutzers ist möglich, aber nur in dem Modus, den der andere Benutzer zuläßt. Das ist vergleichbar mit der Funktionalität des "set protection" Kommandos in VMS.

Wie unter VMS oder auch MS-DOS und Unix, bietet das Shared Filesystem des VM ein hierarchisches Directory-Konzept auf das auch Programme zugreifen können, die in höheren Programmiersprachen geschrieben worden sind.

CMS-Dateiname besteht aus drei Teilen

Gemäß der beschriebenen Charakteristik des VM-Betriebssystems werden die Dienste des Filesystems durch virtuelle Servermaschinen zur Verfügung gestellt Das heißt, der Benutzer kommuniziert mit diesen Servermaschinen, die entsprechende Fielepools verwalten. Diese Servermaschinen stellen im Falle eines Fehlers auch Recovery-Maßnahmen zur Verfügung.

Ein CMS-Dateiname besteht aus drei Teilen:

1. Dateiname, Filename, maximal acht Stellen

2. Dateityp, Filetype, maximal acht Stellen

3. Dateimodus, Filemode, zwei Stellen. Beispiel: PROGA COBOL A0

Filename- und Typ haben, abgesehen von der Begrenzung auf acht Stellen, die gleiche Bedeutung wie Filename und -Typ im VMS. Der Filemode resultiert aus dem Minidiskkonzept und spezifiziert die Zuordnung der Datei zur Minidisk, sowie, in Verbindung mit den Zugriffsmodi, den Dateischutz.

In diesem Fall bedeutet A0 daß sich die Datei auf der Minidisk "A" befindet, und daß fremde Benutzer, die diese Minidisk ebenfalls im Zugriff haben, diese Datei nicht lesen und manipulieren können.

Die Zugriffsmodi einer Minidisk werden bei der Minidiskdefinition in der Datei "USER DIRECT" spezifiziert. Sie gelten immer für die gesamte Minidisk und bilden zusammen mit der Filemode Nummer, die sich nur auf die jeweilige Datei beschränkt, den Dateischutz.

Typbezeichnung weist auf die Funktion hin

Ein RMS-Dateiname besteht ebenfalls aus drei Teilen:

1. Dateiname, maximal 39 Stellen

2. Dateityp, maximal 39 Stellen

3. Dateiversion (das kann eine Zahl zwischen 1 und 32 767 sein).

Wie in CMS, so weisen auch in RMS bestimmte Dateitypbezeichnungen auf die Dateifunktion hin, etwa "proga.cob;1" Die "1" steht für die erste Version dieser Datei. Nach einer Modifikation, beispielsweise nach dem Editieren, legt RMS eine neue Version "2" an, so daß nach Beendigung der Modifikation zusätzlich zu den bereits bestehenden, jeweils eine neue Dateiversion hinzukommt.

Mit dem DCL-Befehl "purge" werden alle Dateiversionen bis auf diejenige mit der höchsten Versionsnummer in dem jeweiligen Directory gelöscht.

Schutzmechanismen gibt es im VMS-Dateisystem individuell pro Datei. Dabei spielen die folgenden Komponenten eine Rolle:

- die Benutzerkategorien SYSTEM, OWNER, GROUP und WORLD

- der "User Identification Code"

- das DCL Kommando "Set Protection"

- "File Protection Codes"

Diese "Protection Codes" definieren, wer eine Datei lesen, modifizieren, löschen oder, wenn es sich um eine EXE-Datei, also um ein Programm, handelt, ausführen kann.

Die Möglichkeiten zur Kommunikation

Diese Codes werden mit einem Eintrag in der Datei UAF, dem User Identification Code (UIC) verglichen, in welchem die Zuordnung zu den Benutzerkategorien festgelegt werden.

Mit dem Kommando "Set Protection" kann man pro Datei bestimmen, welche Benutzerkategorie auf die Datei zugreifen kann und wie dieser Zugriff erfolgen soll.

Dabei stellt RMS sicher, daß bei gleichzeitigem Schreibzugriff die Sperrmechanismen des VMS Lock Manager aktiviert werden.

Zum Abschluß noch ein kurzer Blick auf die Kommunikationsmöglichkeiten innerhalb beider Systeme (SNA und Decnet einmal ausgeschlossen).

VM stellt insgesamt drei Möglichkeiten der Kommunikation zur Verfügung:

1. Dateiaustausch (File Transfer) über den Spoolbereich

2. Task-to-Task-Kommunikation über "Virtual Machine Communication Facility (VMCF)"

3. Task-to-Task-Kommunikation über "Inter User Communication Vehicle (IUCV)".

Dateitransfer über den Spoolbereich erfolgt durch integrierte CP/CMS-Kommandos interaktiv. VMCF und IUCV sind in VM integrierte CP-Systemdienste, mit deren Hilfe Task-to-Task-Kommunikation betrieben werden kann. IUCV ist dabei die modernere Variante mit höherer Funktionalität und Geschwindigkeit. Im Prinzip arbeiten beide Methoden mit SEND-, SEND/RECEIVE-, RECEIVE Mechanismen, also "peer to peer orientiert".

Um eine Task-to-Task-Kommunikation aufzubauen, bedarf es mindestens zweier Assemblerroutinen, eine in der aufrufenden und die andere in der aufgerufenen Umgebung.

Vereinfacht dargestellt, wird durch den Aufruf der SEND-, beziehungsweise SEND/RECEIVE-Funktion in der Zielmaschine ein External-Interrupt generiert (siehe Teil I dieses Artikels).

Die Zielmaschine fängt mit der Unterstützung eines Systemdienstes (in diesem Fall ein MACRO), alle External Interrupts in ihrer virtuellen Page 0 ab und prüft, ob dieser Interrupt für sie ist Wenn ja, werden die von der Quellmaschine erhaltenen Daten verarbeitet.

Diese Art der Kommunikation verlangt gute System- und Assemblerkenntnisse, kann aber sehr umfangreiche und komplexe Lösungen realisieren.

Unter anderem ist das eine Möglichkeit, innerhalb einer virtuellen Maschine einen Multitasking Betrieb zu etablieren.

Servermaschinen wie etwa der Fileserver des VM/SP, Release 6, Shared Filesystems, benutzen diese Technik.

Shared Memory, also gemeinsam benutzbarer Speicher, ist eine weitere Möglichkeit der Kommunikation. Das CP-Kontrollprogramm des VM stellt hier sogenannte Discontiguous Shared Segments zur Verfügung.

VMS bietet ebenfalls diverse Möglichkeiten der Benutzerkommunikation. Im Unterschied zu VM sind diese Dienste wieder von allen VAX unterstützten Programmiersprachen aus aufrufbar. Ein Teil der Funktionalität des VMS-Mail-Utilities ist in etwa vergleichbar mit den VM-Dateitransfer-Funktionen.

Der Aufruf der Mail-Funktion bringt dem Benutzer allerdings eine separate Umgebung, die ihm eine größere Funktionalität als der VM-Dienst eröffnet. Außer Dateien können mit Mail auch Nachrichten versandt werden, die der Empfänger dann als Datei ablegen kann. Darüber hinaus ist Mail, wie jede andere VAX/VMS-layered-Software netzwerk- und clusterfähig. Um die Kommunikation mit einem anderen Prozeß auf Programmebene durchzuführen, werden in VMS folgende Funktionen und Einrichtungen benutzt:

- Common Event Flags, das sind Statusbits, die gesetzt werden können, um bestimmte Ereignisse zu synchronisieren

- Resource Locks, gesetzt durch den bereits erwähnten VMS distributed Lock Manager

- Mailboxes

- Global Sections, (shared memory)

- Shared Files

Eine Mailbox ist eine virtuelle Ein-Ausgabeeinheit, in welche ein Prozeß Daten abstellen kann. Der Speicherplatz für eine Mailbox wird mit Hilfe eines VMS Dienstes kreiert.

Zugriff erfolgt über l/O-Systemdienste

Alle VAX/VMS-unterstützten Hochsprachen können auf diese Mailbox zugreifen, da der Zugriff über I/O-Systemdienste erfolgt Prozesse können auch eine fremde Mailbox mit Hilfe von VMS-Systemdiensten benutzen.

Ein AST oder "Asynchronous System Trap" entspricht funktional einem External Interrupt im System /370. VMCF und IUCV benutzen eine ähnliche Technik.

Im VMS wird dazu keine Assembler Routine benötigt Das Arbeiten mit ASTs, Mailboxes etc. ist, wenn man so will, integrierter Teil der Entwicklungsumgebung in VMS und unterstützt daher alle im VMS üblichen Programmiersprachen.

Ein Artikel wie dieser kann sich nur punktuell mit den wesentlichen Merkmalen so umfangreicher und komplexer Systeme wie /370 und VAX/VMS befassen und daher nur einen kleinen Einblick in die unterschiedlichen "Styles of Computing" dieser beiden Welten bieten. Sicher gibt es noch einiges zu ergänzen oder detaillierter auszuführen.