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 einigen Stolpersteinen. (siehe CW Nr. 25, vom 21. Juni 1991, Seite 37: "Transaktionsverarbeitung in verteilten DV-Umgebungen").

Den Spezialisten in den DV-Abteilungen obliegt die Aufgabe, den technischen Fortschritt beispielsweise in Form von Produkten und Systemen der Hersteller sinnvoll und kosteneffizient einzusetzen. Dort wo Systeme verschiedener Hersteller durch spezifizierte Schnittstellen zusammenarbeiten, dort ändert sich auch das Anforderungsprofil an die mit diesen unterschiedlichen Systemen arbeitenden Spezialisten. Nicht mehr nur Kenntnisse eines bestimmten Systems sind gefragt, sondern auch jene anderer DV-Welten. Jeder, der schon einmal versucht hat, etwa aus einem PC-Netz über einen DEC-, HP-, SNI- oder anderen Rechner mit beispielsweise einem MVS-Softwarepaket zu kommunizieren, kennt diese Problematik.

Einige Hersteller versuchen, durch entsprechende Architekturen das Zusammenwachsen dieser Welten zu beschleunigen und den Benutzern einheitliche Oberflächen anzubieten, in denen das Betriebssystem keine Rolle mehr spielt. Diese Entwicklung wird auf den verschiedenen Hardwareplattformen wohl sehr unterschiedlich verlaufen. Aus der Sicht der Systemprogrammierer beziehungsweise Systemmanager wird es jedoch weiterhin die Notwendigkeit geben, etwas über Bits und Bytes wissen zu müssen.

Dies schon deshalb, weil auf diesem technischen Level der Unterschied des "Style of Computing" verschiedener Systeme unmittelbar zu spüren ist, was nicht selten zu einer Teilung in unterschiedliche Lager innerhalb der DV-Abteilung führt, die dann miteinander aufgrund von Verständnisschwierigkeiten nur ein Minimum an Kommunikation pflegen. IBMs System /370 und DECs VAX/VMS sind zwei solcher unterschiedlicher DV-Kulturen. Beim näheren Hinsehen ergeben sich jedoch auch einige Gemeinsamkeiten.

Dieser Artikel enthält eine komprimierte technische Gegenüberstellung beider Systeme. Qualitative Bewertungen sind dabei nicht beabsichtigt, da aus der Sicht eines Anwenders, der beide Systeme einsetzt, jedes System seine eigene Berechtigung hat.

Historische Betrachtungen:

Im Gegensatz zur VAX, wo ein einziges Betriebssystem die gesamte Hardwarepalette abdeckt, stehen auf der IBM/370-Hardware eine Reihe von Betriebssystemen zur Verfügung. Eine Ursache dafür ist in der Entwicklungsgeschichte beider Systeme zu sehen. Unter dem Begriff "/370-Architektur" wird primär die Beschreibung der Hardware/Software-Schnittstelle verstanden, also die Kommunikation zwischen Hardware und Betriebssystem.

Festgelegt sind diese Regeln in einem Handbuch, welches auch "die Bibel des /370-Systemprogrammierers" genannt wird: "System /370 Principles of Operation", oder auch kurz "POO" genannt. Allgemein kann man dieses Manual als die Grundlage für die Entwicklung eines IBM-System-/370-Betriebssystems betrachten. Das heißt, auf eine definierte Hardware/Software-Schnittstelle wurden die Betriebssysteme im nachhinein implementiert.

Bei der Dynamik der DV-Entwicklung hatte das allerdings auch zur Folge, daß manches frühe Systemdesign von den technischen und marktwirtschaftlichen Erfordernissen eingeholt wurde. Die Konsequenz daraus war das Entstehen verschiedener Betriebssysteme, die, jedes für sich, den spezifischen Funktionsanforderungen und neuen Technologien zum jeweiligen Zeitpunkt optimal gerecht zu werden versuchten. Das hat im Laufe der Jahre allerdings zu einer heterogenen Betriebssystemlandschaft innerhalb einer Hardware-Architektur geführt, die man durch eine entsprechende Architektur (SAA) zu überbrücken versucht.

Die Basis der /370-Systeme ist das 1964 entstandene System /360. Ziel des Systems /360 war es, eine Prozessorfamilie zu entwickeln, deren Hardware-Architektur unabhängig von der Rechnerleistung immer dieselbe sein sollte. Der Begriff /360 stand dabei für die 360 Grad einer Windrose und sollte den universellen Anspruch dieser Rechnerfamilie symbolisieren.

Einheitliche Entwicklung versus Zusammenfassung

Zunächst wurden nur reale Betriebssysteme, wie etwa das Disk Operating System (DOS) unterstützt. Mit der Einführung der /370-Architektur begann dann für diese Familie das Zeitalter der virtuellen Verarbeitung. Im Laufe der Jahre änderte sich auch die Adressierungsbreite der /370-Systeme von zunächst 24-Bit-Adressierung (maximal 16 MB) auf heute im System ESA/370 vorhandene 48-Bit-Adressierung von theoretisch bis zu 256 Terabyte (TB).

Trotz dieser Erweiterungen hat sich an der Architektur prinzipiell nichts geändert. Schon im System /360 bestand ein Adreßregister aus 4 Bytes, also 32 Bits, von denen allerdings nur 24 genutzt wurden. (Ein Adreßraum von 16 MB war 1964 eine gewaltige Größe!). Mit der 370/XA-Architektur wurden dann sieben weitere Bits genutzt, so daß man auf insgesamt 2 GB Adreßraum kam (Bit 32 ist der Indikator für den jeweiligen Adressierungsmodus (24, 31 Bit). Dieses Prinzip gilt bis heute für das System ESA/370, wobei die zusätzlichen Adreßbits aus der Verknüpfung mit extra dafür geschaffenen "Access Registern" entstehen. Diese Prinzipien gelten auch für die Systemfamilie ESA/390, welche im technischen Sinne eher eine Zusammenfassung des Hard- und Softwarespektrums innerhalb der /370-Welt ist.

VAX/VMS kann man dagegen als einheitliche Hard/Software-Entwicklung betrachten, welche 1977 mit der ersten VAX vorgestellt wurde. Dadurch konnte von Anfang an darauf geachtet werden, die Funktionalität möglichst optimal auf die jeweiligen Hard- und Software-Komponenten zu verteilen. Der wesentliche äußere Unterschied zu den IBM/370-Systemen besteht zunächst darin, daß das Betriebssystem VMS (Virtual Memory System) unabhängig von der Größe des VAX-Rechners (VAX = Virtual Address Extension) - zur Adressierung werden 32 Bit, also bis zu 4 GB verwendet - und des Einsatzspektrums auf allen VAX-Maschinen läuft. Das heißt, es gibt keine Umstellungsproblematik beim Wechsel auf einen größeren Rechner. Allerdings muß das System damit auch einem größeren Anwendungsspektrum gerecht werden.

Ein weiterer, wesentlicher Unterschied besteht darin, daß bei VAX/VMS die Trennung zwischen Hard- und Softwareschnittstelle nicht so exakt verläuft, wie beim System /370. So sind beispielsweise einige Funktionen, die im System /370 in das jeweilige Betriebssystem (und dort unter Umständen jeweils unterschiedlich) implementiert sind, auf der VAX/VMS-Seite durch Hardwarefunktionen abgedeckt. Ein Beispiel dafür ist die Art und Weise wie unter VAX/VMS das "Context Switching" abläuft. Dieser Vorgang ist vergleichbar mit dem "PSW Swapping" im System /370, mit dem Unterschied, daß unter VAX/VMS zum Beispiel die Register- und anderen Informationen (im VMS "Hardware Context" genannt) durch eine einzige Instruktion in einen fest vorgegebenen Bereich (Stack) gesichert werden.

Der Hauptspeicher oder auch "Main Storage" beziehungsweise "Main Memory" genannt, ist in beiden Systemen ein fortlaufend adressierbarer Speicherbereich. Er enthält Programme (Instruktionen) und Daten. Kleinste adressierbare Einheit ist in beiden Systemen das "Byte", bestehend aus 8 Bit. Im System /370 enthält der Hauptspeicher außerdem noch die I/O-Kommandos, sowie die Datenpuffer des logischen I/O-Subsystemes, da der /370-Assembler-Instruktionssatz, im Gegensatz, zu VAX/VMS, extra I/O-Instruktionen enthält.

Das IBM-System /370 arbeitet im 256 Zeichen umfassenden EBCDIC-Zeichensatz, VAX/VMS benutzt den 128 Zeichen umfassenden ASCII-Zeichensatz. Ein weiterer wesentlicher Unterschied besteht in der Art de Darstellung der Daten innerhalb der jeweiligen Datentypen.

System /370 gehört zu den sogenannten "big endian systems" während VAX/VMS ein "little endian system" representiert. Das heißt die CPUs lesen und speichern Daten unterschiedlich.

Ein vereinfachtes Beispiel soll das verdeutlichen: Nehmen wir an, die Zahl 1234 ist in den Stellen 1000 bis 1003 im Hauptspeicher vorhanden (1 in Stelle 1000, 2 in Stelle 1001 usw.) und soll in ein 32-Bit-Register (vier Byte) übertragen werden, wobei das Byte, welches am weitest links steht, als "high order byte" und das Byte, welches am weitesten rechts steht als "low order Byte" bezeichnet wird.

Wenn bei der Datenübertragung Speicher zum Register nach dem Prinzip "low address (also Adresse 1000, das ist die Ziffer 1) into low order Byte" verfahren wird, dann wird das Register von rechts nach links mit den Ziffern 1, 2, 3 und 4 gefüllt, was unseren Lesegewohnheiten entsprechend von links nach rechts wie die Zahl "4321" aussieht. Beim Zurückladen des Registerinhaltes in den Speicher wird nach dem gleichen Prinzip verfahren.

In einem "big endian system" ist das genau umgekehrt. Dort heißt es "low address into high order byte". Von links nach rechts gesehen wäre das nach dem: :Übertragen Speicher zum Register die Zahl "1234". Entsprechend beginnt die Numerierung der Bits innerhalb eines Bytes auf der linken Seite mit "00" und endet auf der rechten Seite mit "07" (big endian), little endian dagegen numeriert die Bits eines Bytes mit 00 bis 07 von rechts nach links. Für einen "Systemumsteiger", der sich beispielsweise mit der Interpretation von Speicherauszügen (der gängige /370-Ausdruck ist "Dump", gängiger VMS-Ausdruck "Bugcheck Dump") befassen muß, ist dies zunächst einmal gewöhnungsbedürftig, für die Qualität des Systems jedoch ohne Bedeutung.

"byte swapping" für die Binärkompatibilität

Zur "big endian family" gehören die Systeme IBM/370, 68000, und SPARC während VAX, und alle 80X86 Systeme "little endian" implementiert haben. Systeme von Mips Computer Systems unterstützen beide Architekturen. Auf den Benutzer hat dies alles keine Auswirkungen. Wenn diese Systeme miteinander kommunizieren, dann muß allerdings entsprechende Software für die jeweilige Binärkompatibilität sorgen. In diesem Zusammenhang wird auch vom "byte swapping" gesprochen.

Die Arten der Adressierung

Die /370-Adressierungsbreite wurde bereits eingangs erwähnt. Zur Adreßdarstellung werden benötigt:

- Ein Basisregister, (eines der 16 allgemeinen Register des Systems /370),

- eine 4 KB Page.

Der (virtuelle) Speicher wird in einem /370-System in Blöcke zu 4096 Byte (4K) unterteilt. Ein Basisregister enthält die Anfangsadresse einer solchen Page, die an einer beliebigen Stelle im Adreßraum liegen kann. Sämtliche Adressen innerhalb dieser Page, also von 0 bis 4095, werden dann mit einem "12 bit displacement" relativ zum Pagebeginn angesprochen, was einer hexadezimalen Adreßbreite von X'000' bis X'FFF' entspricht.

Angenommen, Register 12 (X'C') adressiert den Beginn einer 4KB Page, dann ist die höchste ansprechbare Adresse, die durch Register 12 abgedeckt wird "CFFF" wobei "C" für Register 12 und "FFF" für dezimal 4095 steht. Es ist Aufgabe des Assemblerprogrammieres, beziehungsweise des Compilers, die jeweils richtige Zuordnung der Basisregister vorzunehmen.

Da eine volle 24- beziehungsweise 31-Bit-Adresse auf diese Weise in einer Instruktion nicht dargestellt werden kann, muß der Assembler aus Basisregister und Displacement die entsprechende volle Adresse bilden.

Die VAX/VMS-Architektur benutzt ein völlig anderes Adressierungsschema: Eine VAX/VMS-Adresse besteht aus 32 Bits, also auch hier vier Bytes. Die höchste Adresse (X'FFFFFFFF'), 4 GB, ist somit das Doppelte des /370-XA-Systems. Für die Speicheradressierung in VAX/VMS gibt es verschiedene Möglichkeiten, die prinzipiell nicht mit der /370 Technik vergleichbar sind.

Ein wesentlicher Unterschied ist, daß der Adreßmodus in einer VAX-Instruktion in der Regel explizit spezifiziert wird, während im /370-Instruktionssatz der Adreßmodus im Operationscode enthalten ist.

Basisregister im Sinne de /370-Architektur gibt es nicht. Im Gegensatz zu /370 können VAX-Instruktionen sehr lang sein, da generell für jedes Datenformat eigene Instruktionen zur Verfügung stehen, die aus bis zu sechs Operanden bestehen können.

Ein Vergleich ist auch deshalb schwierig, da es unter Umständen mehrere /370-Instruktionen benötigen kann, um einer VAX-Instruktion zu entsprechen. Dazu ein einfaches Beispiel:

Der Inhalt des vier Byte großen Feldes "SUM" soll zum Inhalt des allgemeinen Registers 2 addiert werden. Das bedeutet beim VAX-Assembler: ADDL SUM,R2.

"ADD" steht dabei für den mnemonischen Code Addieren und "L" für den 4-Byte-Datentyp "Longword". Der zweite Operand "R2" stellt den Zieloperanden dar, die Verarbeitung erfolgt also von links nach rechts.

Beim /370-Assembler stellt es sich dar als A R2,SUM. "A" steht hier für Addieren, und "SUM" bedeutet auch hier einen 4-Byte-Datentyp "Word" oder "Fullword". Der erste Operand R2 ist das Ziel. Die Verarbeitung erfolgt also umgekehrt.

Beide Systeme benötigen in diesem Fall jeweils eine Instruktion. Wenn die Operanden jedoch umgekehrt werden sollen, ändert sich das Beispiel erheblich:

Der Inhalt des allgemeinen Registers 2 soll zum Inhalt des Feldes "SUM" addiert werden, also heißt dies beim VAX-Assembler: ADDL R2,SUM.

Eine adäquate /370-Instruktion gibt es nicht. Daher muß zunächst der Inhalt des Feldes SUM in ein Register geladen werden: L R3,SUM. Danach kann der Inhalt von Register 2 zum Inhalt von Register 3 addiert werden, also AR R3,R2. Zum Schluß muß das Ergebnis wieder in Feld SUM gebracht werden: ST R3,SUM.

Prozessorstatus und Speicherschutz

Das "Program Status Word" (PSW) schreibt und kontrolliert im System /370 den Prozessorstatus. Die vergleichbare Einrichtung in VAX/VMS bildet sich aus dem "Processor Status Longword" (PSL) sowie dem "Program Counter" (PC). In VAX/VMS sind sowohl PSL als auch PC spezielle 32-Bit-Register. Anders im System /370: Das "/370 PSW" ist eine durch privilegierte Instruktionen ansprechbare 64-Bit-Informationseinheit, welche Daten aus verschiedenen Lokationen enthält.

Das PSW erscheint in verschiedenen Modi, abhängig davon, ob es sich um ein System /360 (BC-Mode), oder ein System /370 (EC-Mode) handelt. Es enthält in den Bits 0 bis 31 ähnliche Informationen wie das PSL im VAX/VMS-System. Die Bits 32 bis 63 enthalten die Adresse der nächsten ausführbaren Instruktion, das entspricht im VAX/VMS-System dem Inhalt des Program Counters (Register 15).

Im Gegensatz zu VAX/VMS kennt das System /370 nur zwei Prozessor-Zugriffsmodi:

1. "privileged" (manchmal auch Supervisor-Mode genannt)

2. "non privileged" (manchmal auch als Program-Mode bezeichnet).

Der Instruktionssatz ist dementsprechend in zwei Kategorien von Instruktionen unterteilt. Bei der Ausführung einer priviligierten Instruktion generiert die Hardware einen "Program Interrupt", in der Form einer "privileged operation exception".

VAX/VMS kennt insgesamt vier verschiedene Modi. Diese sind, vom priviligiertesten Modus abwärts:

1. "Kernel"

2. "Executive"

3. "Supervisor"

4. "User"

Der VAX/VMS-Modus bestimmt, welche Instruktionen ausgeführt und, anders als im System /370, auf welche Speicherstellen zugegriffen werden darf. Im Gegensatz zum System /370, wo jedes Betriebssystem eine andere individuelle Einteilung des Speichers vornimmt, ist der Speicher in VAX/VMS fest definiert.

Die Zugriffskontrolle kann daher auf logischer Ebene erfolgen. Im System /370 dagegen ist jede physikalische Page mit einem Zugriffsschlüssel versehen. Dieser "Access Key" wird mit dem Schlüssel im aktuellen Programm Status Word verglichen.

Interrupts und Exceptions

Um einen effizienten Multitasking-Betrieb zu ermöglichen, sind beide Systeme mit Interrupt-Mechanismen ausgestattet. Einige Interrupts resultieren aus der direkten Verarbeitung eines Programmes, beispielsweise eine Division durch 0. Diese programmgetriebenen Ereignisse werden in VAX/VMS "Exceptions" oder "Synchronous Events" genannt. Das System /370 kennt dafür den Oberbegriff "Program Interrupts", die dann wieder in diverse Exceptions unterteilt werden. Andere Interrupts können systemweit ausgelöst werden, wie etwa das Drücken der Starttaste an einer Band- oder Platteneinheit. Im System /370 führt dies zu einem "External Interrupt".

Ereignisse laufen nach dem gleichen Schema ab

In VAX/VMS wird dies als "lnterrupt" oder "Asynchronous Event" bezeichnet. Diese Ereignisse laufen in beiden Systemen im Prinzip nach dem gleichen Schema ab:

1. Ein(e) Interrupt/Exception unterbricht die CPU beim Ausführen von Instruktionen.

2. Die CPU muß die Routine des Betriebssystems lokalisieren, die für das Bearbeiten dieser Unterbrechung zuständig ist.

3. Der aktuelle Status des Prozessors muß gesichert werden.

4. Die lokalisierte Betriebssystemroutine muß abgearbeitet werden.

5. Die CPU hat die beim Eintritt des Ereignisse unterbrochene Arbeit nach der unterbrochenen Instruktion wieder aufzunehmen.

Dabei benutzt das System /370 folgende Komponenten:

1. Fixed Storage Locations

2. Program Status Word

3. Interrupts: System /370 unterscheidet sechs Interruptarten:

- Restart: Ausgelöst durch die Hardware-Restart-Taste an der Systemkonsole

-External: Ausgelöst beispielsweise durch den Hardware-Timer

- Supervisor Call: Ausgelöst durch die Assembler-Instruktion "SVC", welche Betriebssystem-Dienste anfordert.

- Program: Ausgelöst durch diverse "Program Exceptions" wie etwa eine Division durch Null etc.

- Machine Check: Ausgelöst durch Hardware-Ereignisse

- Input/Output: Ausgelöst durch eine I/O-Kontrolleinheit beim Ende einer I/O-Operation

4. PSW-Swapping

Entsprechende VAX/VMS-Komponenten:

- System Control Block (SCB) und System-Control-Block-Base-Register (SCCB)

- Processor Status Longword (PSL) und Program Counter (PC)

- Interrupts und Exceptions: Eine generelle Unterteilung erfolgt hier in:

- Device Interrupts

- Software-generated Interrupts

- Exceptions

- "Event Vector Processing"/"Context Switch"

Verarbeitungsschritte im System /370

Die realen Page 0, also die ersten 4096 Bytes des Speichers (bei 4KB Pagegröße) enthalten fest zugeordnete Adressen, in denen sowohl die Hardware als auch die Software Informationen abstellt beziehungsweise entnimmt. Diese Speicherstellen werden "Fixed Storage Locations" genannt. Hier befinden sich zum Beispiel die Adressen der Betriebssystemroutinen, die für das Abarbeiten eines Interrupts zuständig sind, in Form eines dem jeweiligen Interrupt entsprechenden "New Program Status Word".

Da nur das jeweilige Betriebssystem diese Adressen kennt, (es sind ja Zeiger auf entsprechende Betriebssystem-Routinen), werden diese beim Start des Systems, das ist im System /370 die "Initial Program Load"-(IPL-) Phase, vom Betriebssystem dort abgestellt.

Tritt ein Interrupt auf, dann wird das Programm Status Word geladen und ausgeführt, welches die dem Interrupt entsprechende Routine enthält. Gleichzeitig wird die Adresse, die der Interrupt zuletzt "bearbeitete", in den dem jeweiligen Interrupt entsprechenden Lokationen in der Page 0 gesichert. Diese Lokationen nennt man "Old Program Status Word". Der durch die Hardware gesteuerte Vorgang heißt "PSW Swapping".

Das Sichern des Prozessorstatus erfolgt in die dafür vorgesehenen Lokationen in der Page 0. Dabei sind Umfang und Art der zu sichernden Informationen abhängig von der Art des Interrupts. Dieser Sicherungsschritt wird durch die Hardware ausgeführt. Das Betriebssystem muß in seiner jeweiligen Interrupt-Routine dafür sorgen, daß die Informationen, die im Zusammenhang mit dem unterbrochenen Task stehen (entspricht in diesem Fall einem VMS-Prozeß), auf "Softwarebasis" gesichert werden.

Das sind in erster Linie die 16 allgemeinen Register des Systems /370, aber auch andere Informationen. Hier taucht wieder der Begriff der "Linkage Conventions" auf.

Im VMS spricht man in diesem Zusammenhang vom "Process Context Switching". Das Verfahren ist prinzipiell gleich, wesentliche Teile werden jedoch im Gegensatz zum System /370 von der Hardware durchgeführt.

Anders als im System 1370 sind deshalb in VAX/VMS einigen der allgemeinen 16 Register bei dieser Funktion bestimmte Merkmale zugeordnet.

Nach dem Abarbeiten der entsprechenden Betriebssystemroutine lädt das System das vor dem Interrupt gültige "Old Program Status Word" und die Verarbeitung läßt sich an der unterbrochenen Stelle fortgeführen.

Verarbeitungsschritte im VAX/VMS-System

Auch hier benötigt die CPU spezielle Kontrollinformationen, um die dem Interrupt beziehungsweise der Exception entsprechende Bearbeitungsroutine zu finden. Diese Adressen werden in 4 Byte großen Longwords, welche als "Vektoren" bezeichnet werden, gespeichert. Die Vektoren bilden zusammen eine 512 Byte große Page, den "System Control Block (SCB) " im realen Speicher.

Der SCB entspricht funktional den "New PSW Locations" der Page 0 des Systems /370. Die Adresse des SCB befindet sich in einem Register, dem "System Control Block Base Register" (SCBB). Mit dessen Hilfe wird die Adresse (Vector) der zuständigen Betriebssystemroutine gefunden.

Das ist, wie im /370-System, ebenfalls eine Hardware-Angelegenheit, mit dem Unterschied, daß in VAX/VMS nicht die Page 0 fest zugeordnet wird. Beim Sichern des Prozessorstatus schreibt das VAX-System je eine Kopie des Program Counter und des Processor Status Longword in den Hardware Interrupt Stack.

Je nach Art des Interrupts oder der Exception werden auch hier zusätzliche Informationen gesichert. Wie im /370-System ist auch dies eine Operation, die durch die Hardware ausgeführt wird.

Das Sichern der allgemeinen Register sowie der sonstigen Softwareinformationen der unterbrochenen Routine wird in VAX/VMS durch eine Hardware-Instruktion ausgeführt. Diese beim "Process Context Switching" betroffenen Informationen befinden sich in einer Datenstruktur, welche Process Control Block (PCB) genannt wird. Ein entsprechendes Register, das "Process Control Block Base Register" (PCBB), enthält die Adresse dieses Blocks.