Ein einheitliches Betriebssystem, um "offene Systeme" zu erreichen, sollte kein Glaubensbekenntnis der Computergemeinde sein, forderte der erste Teil des Beitrages, der als Muster für einen alternativen Weg CTOS anführte. Dieses Betriebssystem wurde 1980 im Hinblick auf die sich abzeichnenden Anforderungen des Distributed-Processing vorgestellt.
Statt dessen sollten die Standards zur Sicherstellung der Softwareportabilität und der Konnektivität zu fremden Systemen zuverlässig implementiert werden. Der Begriff "Multiuser" erhält unter diesem Aspekt eine etwas andere Definition als in der Unix- und OS/2-Welt.
Der Begriff "Multiuser" wird von der CTOS-Seite auf den ersten Blick in verwirrender Weise benutzt. Die Verwirrung kommt daher, daß die herkömmliche Terminologie von den Begebenheiten der prozedurorientierten Technik ausgeht. Wenn man Microsoft nach einer Charakterisierung von OS/2 fragt, dann ist die Antwort "Multitasking, Singleuser". Bei Unix hieße es "Multitasking, Multiuser". Unix kann von einer CPU aus eine Anzahl von Terminals ohne eigene Intelligenz betreiben, OS/2 braucht zwingend an jedem Arbeitsplatz eigene Intelligenz mit im übrigen recht voluminösem Arbeitsspeicher (sehen wir dabei von "angehängten" Erweiterungen für den Terminalbetrieb ab).
Wie OS/2 arbeitet CTOS ausschließlich mit Workstations, also kompletten Computern an jedem Arbeitsplatz, was bei Unix lediglich eine Option ist. Deshalb möchte man es wie OS/2 "Multitasking, Singleuser" einordnen. Die CTOS-Anbieter begründen ihre Definition von "Multitasking, Multiuser" wie folgt: CTOS geht nicht von der Prämisse "alle Ressourcen auf einer Maschine" aus, sondern ist von vornherein so angelegt, daß Prozesse, die zu einer Anwendung gehören, auf verschiedenen CPUs oder Prozessoren ablaufen können.
Das Prinzip "Messagebased" fürs Netz
Die Verteilung der Intelligenz ist als Normalfall vorgesehen. Die Ressourcen - Prozessoren, Arbeitsspeicher, Massenspeicher und sonstige Peripherie rechnen mit der Situation, daß mehrere Benutzer auf sie zugreifen, während bei prozedurorientierten Betriebssystemen nach diesem Modell die Verteilung der Intelligenz und der Ressourcen gewissermaßen simuliert wird - daher also die Bezeichnung "Multiuser" für ein Betriebssystem, das an jedem Arbeitsplatz einen kompletten Computer erwartet.
Eng verbunden mit dieser Eigenschaft ist der Begriff "Message-based". Wenn CTOS auf eine entfernte Ressource zugreifen will, geschieht dies nicht durch eine Prozedur, sondern durch eine Nachricht, die dort in einem Cache falls nötig solange abgelegt wird, bis sie beantwortet werden kann. Diese Antwort wird mit der empfangenen Workstation-Adresse wieder zurückgeschickt. Dies erweist sich als eine weitaus effizientere Zustellungsmethode als in Ethernet oder Token-Ring, weil die Übermittlung direkt zwischen Sender und Empfänger stattfindet.
Das traditionelle DV-Modell beruht nicht nur auf der Prämisse "alle Ressourcen auf einer Maschine", sondern auch auf die Voraussetzung "eine Maschine, mehrere Benutzer". Aufgrund der vor 20 Jahren vorgegebenen Verhältnisse konnte man Verarbeitungsleistung
nicht verteilen, sondern umgekehrt mußten sich viele Benutzer mit vielen Anwendungen eine Maschine teilen.
Unix folgt diesem Muster zwangsläufig. Bei dem "jungen" OS/2 ist dies um so mehr erstaunlich, als es normalerweise gar nicht mit mehreren Benutzern pro Maschine arbeitet. CTOS wurde von Convergent Technologies, dem damals noch selbständigen Entwickler, sogleich nach dem neuen Paradigma angelegt, daß mit der Verfügbarkeit beliebig vieler Prozessoren und/oder CPUs an beliebig vielen geographisch verteilten Plätzen zu rechnen sei. Dementsprechend hat man das Prinzip der Interaktion der Programmteile und Ressourcen auf der Basis des Nachrichtentransports zugrunde gelegt. Derselben Logik folgen die objektorientierten Programmsysteme. "Multiuser" heißt also in der CTOS-Welt, "eine Anwendung auf gegebenenfalls mehreren Maschinen zu fahren oder auf einer Maschine gegebenenfalls mehrere Anwendungen und Zugriffsmöglichkeiten durch mehrere Benutzer" zu realisieren.
Das Message-orientierte Betriebssystem kennt nur eine einzige Aufgabe, die von den Messages ausgeführt wird: Anfragen und Antwort abzuwickeln, analog zu dem Verhältnis Client zu Server.
Auch OS/2 ist prozedurorientiert
Auch innerhalb des Systems beruht der Zusammenhalt der Prozesse auf diesem Prinzip der Messages. Es besteht deshalb kein Unterschied zwischen Nachrichten innerhalb einer CPU, solchen in einem lokalen Netz oder einem Wide Area Network. Auf dieser Tatsache fußt letzten Endes der Effekt, das ein Remote-Procedure-Call in dieser Umwelt erstaunlicherweise rund hundertmal schneller ist als in einem der benannten prozedurorientierten Betriebssysteme.
Der Message-orientierte Ansatz hat allerdings auch einen Nachteil: Innerhalb der gleichen CPU ist diese Arbeitsweise etwas langsamer als die prozedurorientierte. Man tauscht hier einen Vorteil, den man nicht mehr braucht, gegen einen, der immer mehr Bedeutung gewinnt: Hohe CPU-Leistung ist ja heute zu vergleichsweise geringen Kosten an jedem Arbeitsplatz verfügbar, so daß solche Unterschiede im Ablauf buchstäblich ohne Wirkung auf die Anwendung bleiben. Die Kommunikation im Netz hingegen ist immer zeitkritisch, und hier wirkt sich die "eingetauschte" Leistung aus.
Ressourcen-Erweiterung leichter gemacht
Die tatsächlich unter Benutzern geteilte Maschine hat übrigens ihre Schwächen insbesondere dort, wo die heute häufigen prozessorintensiven Anwendungen laufen, wie beispielsweise Textverarbeitungs- und Kalkulationsprogramme. Da andererseits Text schon für einen der kaum noch angebotenen 8086-XTs eine leichtere Übung ist, zeigt sich der Unterschied dort, wo verteilte (beziehungsweise verteilende) gegenüber geteilten Systemen ihre Stärke haben, besonders kraß: Geteilte Systeme, inklusive Mainframes, sind im Vergleich wirklich leistungsfähig nur noch bei transaktionsorientierten Anwendungen also bei Anfragen, Antworten und Updates an Datenbanken, wobei die lnanspruchnahme des Arbeitsspeichers vergleichsweise gering ist, während die Hauptlast auf den Plattenzugriffen liegt. Dementsprechend liegt die Hauptaufgabe der Hosts heute im Betrieb großer, zentraler Datenbanken.
CTOS hat einen extrem kleinen Kern. Er ist lediglich zuständig für das Memory Management, das Zustellen der Anfragen (request routing) und die Prozeßsteuerung (scheduling). Andere Aufgaben werden aufgrund der Message-orientierten Arbeitsweise außerhalb der Kernebene angesiedelt und sind mit diesem nicht verknüpft, sondern die Interaktion erfolgt ebenfalls durch Messages: Dateisystem, Tastatur, Bildschirm et cetera. Auf diese Weise ist die Unterstützung neu hinzukommender Ressourcen wesentlich vereinfacht, denn die Kernebene wird davon nicht berührt. Das gilt ebenso für grundlegende Softwareressourcen wie Objekt-Manager in einem objektorientierten Programmsystem wie für Geräte und andere Hardwarekomponenten.
In der Praxis heißt das, daß Ressourcen wie Prozessoren, Arbeitsspeicher-Erweiterungen, Platten oder Drucker in bestehende lnstallationen eingeführt werden können, ohne daß der Benutzer des betroffenen Arbeitsplatzes irgendwelche Änderungen an der Betriebssystem-Konfiguration vorzunehmen braucht. Insbesondere ist dies von Bedeutung, weil Server in solchen Situationen nicht neu gebootet zu werden brauchen, also ihren Betrieb nicht unterbrechen.
Systemkenntnisse nicht notwendig
Anwender wissen das zu schätzen: So berichtet das AOK-Rechenzentrum Westfalen-Lippe, von der CTOS und die zugehörigen Rechner vor sechs Jahren bei MDS erworben wurden, daß CTOS-Cluster bei örtlichen Krankenkassen eingesetzt würden, wo die Benutzer von keinem lokalen Systemadministrator betreut werden. Systemkenntnisse sind auch bei solchen Erweiterungen nicht notwendig.
Da Vernetzung eine der grundlegenden Eigenschaften dieses Betriebssystems ist, steuert es ohne jegliche andere Variante die Arbeitsplätze und den oder die Server, und zwar nicht nur im lokalen Netz, sondern auch im WAN. Für OS/2 gilt indessen wie bekanntlich für DOS, daß ein spezieller LAN-Manager, sei es Novell Netware, 3 + Open oder einer Unter mehreren anderen, absolut notwendig ist. Für ein reguläres Workstation-Netz gilt das auch unter Unix, hier wäre die Sun-Entwicklung NFS zu nennen.
Im Verbund mit IBM - und anderen Mainframes
Soweit die Interaktion innerhalb des CTOS-Netzes. Eine der Forderungen an ein offenes System ist jedoch die Interaktion mit anderen Betriebssystemen.
Der Übergang zu Mainframes, insbesondere in einer SNA-Umgebung, ist dabei ein besonders häufiger Fall. Zusätzlich sieht CTOS die Unterstützung älterer Protokolle wie BSC mit Emulationen von 3270 und 2780/3780 vor. (wird fortgesetzt)