MÜNCHEN - Die Architektur von IBM- oder PCM-Großrechnern beruht auf den IBM-Principles of Operation (GA 22-7000-8). Gemäß dieser Spezifikationen sind die Betriebssysteme DOS, VM und MVS ausgelegt. Diese Architektur wurde in den 60er Jahren von IBM angekündigt (/360-Serie) und bis heute weiterentwickelt. Das bedeutet nichts anderes, als daß eine 3081 im Prinzip wie eine 360/30 funktioniert.
Dazu ein Beispiel: Gegeben sei ein Anwender mit einer 3083E16 unter VM, DOS/VSE, BTAM, CICS und DL/1. Was passiert, wenn dieser Anwender die Transaktion ABCD ausführen möchte?
1. Die Kontrolle geht an VM (I/O-Interrupt).
2. VM überprüft dieses Ereignis (I/O-Interrupt) und gibt die Kontrolle an das DOS.
3. DOS überprüft das von VM mitgeteilte Ereignis und gibt die Kontrolle an BTAM.
4. BTAM überprüft das von DOS mitgeteilte Ereignis und gibt die Kontrolle an CICS.
5. CICS überprüft das von BTAM mitgeteilte Ereignis und gibt die Kontrolle an das Anwenderprogramm.
6. Das Anwenderprogramm läuft an.
7. Läuft das Anwenderprogramm auf einem SVC (Op-Code OA) kommt es zu einem SVC-Interrupt.
8. Der SVC-Interrupt bewirkt durch einen hardwaremäßigen PSW-Austausch ein Verzweigen ins VM.
9. VM gibt die Kontrolle ans DOS.
10. DOS führt den SVC durch.
11. DOS gibt die Kontrolle über VM zurück an CICS.
12. CICS gibt die Kontrolle an das Anwendungsprogramm.
Nicht berücksichtigt in diesem Beispiel sind andere I/O-Interrupts, External Interrupts, Dispatching Mechanismen und Paging-Mechanismen der Betriebssysteme VM und DOS sowie des TP-Systems CICS.
Das heißt im Klartext, bis eine Maschineninstruktion im CICS-Anwendungsprogramm (also in dem Teil, den der Benutzer gerne möchte) ausgeführt wird, laufen wahrscheinlich mindestens 500 000 Maschineninstruktionen ab (grob geschätzt und nicht gezählt).
Wo liegen die Gründe für dieses total unausgeglichene Verhalten?
Jeder IBM-TP-Monitor (IMS/DC oder CICS) benötigt als Basis ein Betriebssystem (DOS, MVS), wobei der TP-Monitor sich gegenüber dem Betriebssystem wie ein Anwendungsprogramm verhält, was er de facto auch ist. Das Betriebssystem stellt die Verbindung zur Hardware her (Interrupt-Handling). Das Betriebssystem ist jedoch überhaupt nicht TP-orientiert konzipiert, noch weniger ist es die Hardware, die gar nicht weiß, daß ein TP-System installiert ist. Auch der TP-Monitor ist im Prinzip ein Batch- beziehungsweise Anwendungsprogramm.
Dies zeigt, daß die Kombination Betriebssystem Hypervisor (VM) und TP-System auf der Basis der Principles of Operation veraltet ist. Es ist dringend notwendig, eine echte dialogorientierte Architektur zu schaffen. Ansätze zu dieser Architektur sind gemacht:
1. Unter Beibehaltung der Principles of Operation zum Beispiel durch des ACP (Airline Control Programm), einer Verbindung von Betriebssystem und TP-Monitor
2. Durch die Neuentwicklung einer dialogorientierten Architektur auf der Basis der 360/370/4300/30XX. Serien
3. Durch die völlige Neuentwicklung einer dialogorientierten Architektur.
Für die Engpässe in der IBM-Architektur existieren eine Reihe von Gründen:
1. Jede CPU führt nur eine Instruktion zu einer Zeit durch (AP/MP = zwei Instruktionen, Q = vier Instruktionen)
2. Jeder Kanal kann zu einer Zeit nur einmal Daten auf oder von einem Gerät in den Hauptspeicher übertragen
3. Nur ein CAW, CSW (Channel Adress-Word, Channel Status Word)
4. Nur ein Länderbar (Alter Memory)
5. Der Low-core ist veränderbar (Alter Memory)
6. Nur 16 allgemeine Register
7. Nur 16 Kontroll-Register
8. Interrupts (nicht vorsehbar) entziehen ohne Berücksichtigung der laufenden Prioritäten dem Anwender die Kontrolle
9. Das Current PSW hat 64 Bits (wie IBM 360 zum Beispiel Problem-/State - SV-State Bit 15)
10. Der Hauptspeicher besteht aus Low-core, Instruktionen, Daten, E/A-Bereichen
Aus diesen Überlegungen lassen sich einige Aussagen ableiten:
1. Die /360-Architektur ist nicht zeitgemäß.
2. Sie erfüllt nicht die Anforderungen für eine zeitgemäße Dialogverarbeitung.
3. IBM ist Gefangener der eigenen Architektur.
4. Ein Großteil der bestehenden EDV-Frustration ist direkt auf die bestehende, veraltete Architektur zurückzuführen, ohne daß der Anwender dies unmittelbar erkennt.
5. Datenschutz ist unter dieser Architektur schwer konsequent realisierbar.
6. Diese Architektur ist für IBM ein geeignetes Instrument, die bestehenden Marktsegmente konsequent auszubauen.
7. Engpässe in der Architektur können nicht beseitigt werden.
8. Die Architektur ist an vielen Stellen aufgeweicht, inkonsequent und mit vielen Ausnahmen versehen, also verwässert.
9. Diese Architektur muß der Anwender durch einen sehr hohen wirtschaftlichen Preis kaufen.
Generell ist die IBM-Architektur nicht der Weisheit letzter Schluß. Die langjährige Entwicklung läßt folgenden Schluß zu:
1. IBM hat in der Hardwareentwicklung ausschließlich schnellere im Preis/leistungs-Verhältnis günstigere CPUs und Peripherien entwickelt. Eine Verbesserung der Architektur wurde weitestgehend vermieden. Nur die für die Hardwareentwicklung absolut notwendigen Änderungen wurden vollzogen.
2. Alle in der Hardwareentwicklung nicht vollzogenen Verbesserungen wurden softwaremäßig kompensiert beziehungsweise vergewaltigt, das kostet ja bekanntlich das Geld des Anwenders und nicht das der IBM.
3. Es bleibt abzuwarten, ob IBM die Kraft hat, eine zeitgemäße Architektur zu realisieren.
4. Die Entwicklung verläuft evolutionär (Originalton IBM).
5. Für einen anderen Hersteller eröffnen sich hervorragende Perspektiven.
* Franz Müller, Geschäftsstellenleiter der CACI GmbH, München