Mit der Entwicklung immer höherstehender Kommunikationssysteme wurde des öfteren der Schwanengesang für DOS angestimmt. Doch gerade die Client-Server-Umgebung von LAN-Programmen, wie Netware oder der LAN Manager, verhilft DOS zum Überleben in den Client-Workstations.
Totgesagte leben länger. DOS, der aufgeblasene Tastaturtreiber, nein danke! Auch der Autor dieses Artikels war 1988 überzeugt davon, daß die Entwicklung von MS-DOS rückläufig verlaufen würde, zu Gunsten von OS/2. Aus heutiger Perspektive jedoch hat OS/2 ziemlich den Anschluß verloren und wird zwischen DOS und Windows einerseits und Unix andererseits aufgerieben, falls nicht - wie in der engeren IBM-Umgebung gewaltige Stützungsmaßnahmen vorgenommen werden.
Kombination der konträren DV-Welten
Wie sieht nun die Zukunft von DOS im Netz aus? Soviel gleich vorweg: Es steht gut, sogar sehr gut um DOS. Um dies näher zu verifizieren, müssen wir die Rolle von DOS-PCs in Netzen im Rahmen der verteilten Datenverarbeitung betrachten. Funktionen und Fähigkeiten von DOS sind denen anderer Betriebssysteme gegenüberzustellen. Die wichtigen LAN-Softwarekonzepte Netware und LAN Manager spielen hierbei eine entscheidende Rolle.
Weder die rein zentrale Datenverarbeitung auf der Basis großer Hosts noch die rein dezentrale mit PCs oder Minis weisen den Weg in die Zukunft. Leidet die zentrale Datenverarbeitung an zu hohen Kosten und geringer Flexibilität, so steht die rein dezentrale Datenverarbeitung permanent und mit Recht unter Beschuß, was Datensicherheit, Datenschutz und Verläßlichkeit der Informationsverarbeitung anbetrifft.
Diese Schwachpunkte lassen sich nach heutigem Kenntnisstand nur durch eine Kombination der beiden konträren DV-Welten beseitigen: Die verteilte Datenverarbeitung fügt sie mit allen ihren Ressourcen und Vorteilen zusammen, wobei - wenn man es richtig macht - die Nachteile weitgehend eliminiert werden. Diese Integration geschieht auf der Basis von Netzen, meist lokalen Netzen.
Das Rechenzentrum bietet Leistungen, die ein einfaches Endgerät nicht erbringen kann, und Zugriffe auf Services, die dieses nicht unkanalisiert haben sollte (Datenbanken, Fernnetze etc.). Dazu erlaubt es ein zentrales Backup und ein Host-basiertes Netzwerk-Management. Personal Computer sind in diesem Zusammenhang die natürlichen Nachfolger der Terminals. Zwischen Host- und PC-Ebene lassen sich "mittlere" Rechner als Servermaschinen für die PC-Umgebungen und als Puffer beim Zugriff auf Hosts denken.
Auch in reinen SNA-Umgebungen sind die Tage der Kommunikations-Vorrechner und Cluster- oder Establishment-Controller ebenso gezählt wie die der Terminals. Denn die Auslagerung von Netzsteuerungs-Funktionen in derartige Spezialgeräte ist bei Nutzung der vorhandenen Intelligenz der PC-Endgeräte nicht mehr nötig: LAN-Lösungen bieten hier elegante Alternativen. Die funktionalen Aspekte einer Brücke zwischen PC-Welt und Host-Umgebung lassen sich auch in einem Serversystem behandeln.
Beschäftigt man sich mit der Zukunft von DOS im Netz , drängt sich die Frage nach DOS im Rahmen der verteilten Datenverarbeitung auf. Wenn es hier eine Zukunft hat, dann auch in vernetzten Umgebungen, die keinerlei Zugriff auf einen Host besitzen.
Zunächst ist es sicher nützlich, einen Blick auf mögliche PC-Betriebssysteme und ihre Aufgaben in vernetzten Umgebungen zu werfen.
MS-DOS, dessen Überlebenskampf Thema dieses Artikels sein soll, ist ein SUST-Betriebssystem (Singleuser, Singletasking). Da es nur einen einzigen Prozeß gibt, der die Hardware nutzt, kann ein SUST-System zu einer Zeit nur eine Aufgabe erledigen .
Für den Betrieb in einem Netz ist das äußerst hinderlich: In einer verteilten Umgebung braucht man Verbindungen zu anderen Rechnern. DOS allein kann nur eine einzige Verbindung aufbauen - und dann kein Anwendungsprogramm mehr laufen lassen. Interaktion zwischen DOS-Rechnern und Anwendungsprogrammen auf einem Host ist konzeptionell nicht vorgesehen. Immerhin wurde DOS ab der Version 3.1 um wenigstens einen weiteren Prozeß, nämlich den für die Kommunikation in einem lokalen Netz, erweitert.
Aber nicht nur im Netz stört das Singletasking. Wer einen einfachen Artikel schreibt, möchte schnell zwischen der Textverarbeitung und der Grafiksoftware hin- und herschalten können (wenn er denn unbedingt nicht-integrierte Software einsetzen muß). Als Lösung bietet sich hier Windows an, speziell Windows 3.0. Es verleiht einem PC unter DOS zumindest rudimentäre Multitasking-Fähigkeiten. Ob das Multitasking, wie bei OS/2, Unix und Großsystemen, auf der Ebene des Betriebssystem-Kerns realisiert wird oder - wie bei Windows zwischen Kern und Anwendungsprogramm, ist zwar für strategische
Überlegungen im Performance-Grenzbereich relevant, kaum jedoch für den Anwender.
Ein weiteres Problem von DOS ist der zu kleine adressierbare Speicherbereich. Hier schafft Windows Abhilfe, wobei natürlich, wie bei OS/2 oder Unix, ein Zusammenhang zwischen Hauptspeicher-Ausstattung, Parallelität von Programmen und Geschwindigkeit besteht. Auch Windows kann nicht zaubern. Grob gesagt braucht ein komfortables Anwendungsprogramm der neueren Generation 500 KB Speicher. Möchte man fünf Anwendungsprogramme gleichzeitig laufen lassen, benötigt man demzufolge entweder 2,5 MB Speicherplatz oder einen fleißigen Auslagerungsalgorithmus, der permanent Programmcode und Daten zwischen dem (eigentlich zu kleinen) Realspeicher und dem Hintergrundspeicher hin- und herbewegt. Im letzteren Fall sind natürlich Performance-Einbußen zu erwarten.
In der OS/2-Format klaffen große Lücken
OS/2 sollte der Nachfolger von DOS werden. Als SUMT-System (Singleuser Multitasking) durchbricht es die Grenzen von DOS: mehr Prozesse, mehr Speicher, mehr Leistung - aber auch mehr Aufwand (in jeder Hinsicht) und höhere Kosten. OS/2 hat zwei Entwicklungslinien: die Standard Edition (SE) von Microsoft und IBM gemeinsam und die Extended Edition (EE) von IBM allein.
OS/2 EE ist das strategische IBM-Produkt für die PS/2-Systeme. Allerdings klaffen in der OS/2-Front auch bei IBM mittlerweile große Lücken. Der Grund dafür ist die wohl miserabelste Produktplazierung seit der Erfindung des Bits. OS/2 ist in allen Versionen bis heute auf den 80286-Prozessor fixiert und nutzt die Möglichkeiten der 80386-Familie nicht. Für den 80286 kam es jedoch drei bis vier Jahre zu spät. Alle 80286-Benutzer hatten schon viel Geld in DOS-Software investiert und waren damit zufrieden. Wer sich nicht damit begnügte, faßte eher den Kauf eines 80386-Rechners ins Auge, auf dem seine alte Anwendungssoftware schneller und besser läuft, als den
eines neuen Betriebssystems für den alten Rechner. Zudem gab es kaum Anwendungssoftware für OS/2, und der Betrieb von DOS-Programmen unter OS/2 in der sogenannten Kompatibilitäts-Box brachte in
jedem Fall weniger Leistung bei höheren Kosten. OS/2 EE enthält einen "Kommunikations-Manager", OS/2 SE braucht den "LAN Manager". Der Kommunikations-Manager stellt umfangreiche Instrumente zur Einbettung von PCs und lokalen Netzen in eine SNA-Umgebung bereit.
Die Version EE 1.0 unterstützt schwerpunktmäßig die PC-Host-Koppelung mit dem Kommunikations-Manager und den Elementen APPC, SRPI (ECF) und ACDI, die in einer gehobenen SNA-Umgebung fast unabdingbar sind. Sie enthält zusätzlich einen "Datenbank-Manager" für die Verwaltung von SQL-Datenbanken und dient primär als Entwicklungsumgebung.
OS/2 EE 1.1 ist das vollständige Werk - es enthält die Möglichkeiten der Version 1.0, den Presentation Manager, einen erweiterten Datenbank-Manager zur Unterstützung auch großer Dateien und einen System-Editor. Der Communication Manager ist um Token-Ring- und PC-Network-Support sowie um Programmierschnittstellen für Netbios und die allgemeine Hardware-unabhängige IEEE 802.2 Logical Link Control erweitert. Die bislang letzte Version 1.2 enthält neben Ethernet- und X.25-Support auch das verbesserte HPFS-Dateisystem (was der Standard Edition ebenfalls zugute kommt), ist jedoch nicht immer kompatibel zu alten DOS-Programmen und -Dateien (Naming-Problematik).
An dieser Stelle muß erwähnt werden, daß IBM die Entwicklung der OS/2 Extended Edition für die Zwecke einer echt verteilten Transaktionsverarbeitung durchführte. Wer vorhat, in den nächsten Jahren verteilte Transaktionsverarbeitung bis zur Ebene der Endsysteme hin zu realisieren, kommt mit DOS nicht mehr weiter. Solche Anwendungen setzen echtes Multitasking auf allen Geräten voraus. Noch ist allerdings nicht abzusehen, wie viele Programme in Zukunft solche Voraussetzungen wirklich stellen.
Momentan ist es sehr still um die OS/2 Standard Edition. Es ist ziemlich unklar, wozu sie gut sein soll: Wo sind die Programme, die man unter DOS 4.0 und Windows 3.0 nicht mehr sinnvoll ausführen kann, für die SCO Unix oder PC/AIX jedoch zu mächtig sind? Standardanwendungen sind das jedenfalls nicht! Das wirklich neue Konzept der OS/2 SE war der LAN Manager. Er jedoch hat in seinen neuesten Versionen die Liaison mit OS/2 still und heimlich gelöst. Internen Gerüchten zufolge hat Microsoft sogar Leute aus der OS/2-Küche abgezogen, um sie Windows und DOS 5.x entwickeln zu lassen. Dazu versteht es IBM, OS/2 die EE so geschickt in der SNA-Umgebung unterzubringen und feine Programme - etwa zur Verwaltung von Token-Ring-LANs - ausschließlich darunter anzubieten, daß die IBM-Gemeinde fast automatisch auf EE hochrüstet (allerdings selten alle PS/2-Systeme, sondern nur die an strategisch wichtigen Punkten, also Server, Gateways, Bridges und Management-Arbeitsplätze).
Der letzte wichtige Betriebssystem-Kandidat ist Unix. Es wurde Ende der sechziger Jahre in den Bell-Laboratorien für kleine DEC-Rechner entwickelt. Von vornherein legten die Verantwortlichen Wert auf Portabilität und so wurde es zu 90 Prozent in der Programmiersprache C geschrieben. Ab 1982 paßten es Microsoft und SCO (Santa Cruz Operation) für Personal Computer an. Das Betriebssystem hatte lange Zeit mit Akzeptanzproblemen zu kämpfen, weil es relativ schwierig zu benutzen war. Mittlerweile konnte es jedoch dazulernen und verbirgt seine Komplexität hinter grafischen Oberflächen wie OSF/Motif.
Unix ist ein echtes MUMT-System (Multiuser, Multitasking). Es hat die funktionalen Grundeigenschaften von Großrechner-Betriebssystemen, was Speicher-, Prozeß- und Benutzerverwaltung betrifft. Im Gegensatz zu DOS und OS/2 besitzt Unix in den neueren Versionen eine Reihe von hochwertigen Kommunikationsmechanismen bereits standardmäßig.
Zunächst können die Prozesse auf einer Maschine untereinander kommunizieren, je nach Unix-Typ über sogenannte Sokkets und/oder Pipes. Beide Arten der Interprozeß-Kommunikation lassen sich grundsätzlich auch auf Prozesse in entfernten Rechnern ausdehnen. Unix geht hier den Weg der "Remote-Procedure-Calls" (RPC) auf der Basis von Pipes, unidirektionalen Datenströmen, die ein leistungsfähiges und logisch hochwertiges Transport-Subsystem benötigen. Dieses Transport-Subsystem ist in den meisten Unix-Systemen auf der Basis der TCP/IP-Protokollfamilie realisiert.
Grundsätzlich besteht jedoch das Problem, daß der Egoismus der Hersteller bis heute alle fachlichen Argumente für ein einheitliches Unix beiseite drängen konnte. Lediglich bei der Kommunikation zeichnet sich eine Einigung auf TCP/IP, Sun-RPC, OSI TP4 und APPG ab.
Ob man Unix im Endsystembereich einsetzen soll, hängt von der Komplexität der Aufgaben ab. Falls ja, wäre allerdings meist nicht der PC das ideale Endgerät, sondern eher eine Workstation. Viele Unix-spezifische Dienste wie das verteilte Dateisystem NFS stehen auch für DOS-Clients zur Verfügung (AIX for DOS-Users oder generell TCP/IP-Implementierungen auf PCs).
Sieht man einmal von Unix ab, haben die PC-Betriebssysteme keine sonderlichen Kommunikationsfähigkeiten. Damit sie im Netz überleben können, muß man ihnen zusätzliche Software spendieren. Oft wird sie als "Netz-Betriebssystem" bezeichnet - wir wollen sie hier lieber "Metasoftware" nennen, weil sie zwischen Betriebssystem und Anwendung liegt.
Folgende Anforderungen werden an diese Meta-Ware gestellt:
(Ergonomische Arbeitsoberfläche, wenigstens mit Menüs, ist notwendig.
(Benutzerfassung nach einem Environment-Konzept, das heißt, der Benutzer sieht die ihm zur Verfügung stehenden Möglichkeiten nicht explizit, sondern er sieht einen Objektraum (Objekte hier: Gegenstände seiner Arbeit) und Operationen (Programme) auf diesen Objekten, zu deren Ausführung er autorisiert ist. Was über seinen Autorisierungsrahmen hinausgeht, darf er nicht und sieht er auch nicht.
(Realisierung des exklusiven Zugriffs auf gemeinschaftlich genutzte Ressourcen, so daß beispielsweise Dateien immer in dem Zustand sind, in dem sie sein sollen (File- und Record-Locking), oder damit in Druckausgaben nicht der Output mehrerer Programme durcheinander geworfen wird.
(Parallelverarbeitung auf dem Server, um dessen Dienstleistungen einer Vielzahl von Clients im Netz zur Verfügung stellen zu können.
(Realisierung der Netzübergänge in Richtung Host je nach den zur Verfügung stehenden Möglichkeiten: Für jede der vorhandenen Alternativen ist eine spezielle Lösung vorzusehen. Am elegantesten ist natürlich die Einbettung in eine Netzwerk-Systemarchitektur, da sich deren Kontrollelemente auch auf den PC-Pool erstrecken.
(Funktionen für das Netzwerk-Management, darunter auch solche, die es ermöglichen, Kosten für Fernverbindungen den Verursachern zuzuordnen: Wenn es in einem LAN zwei Arten von Rechnern gibt - Clients und Server - kann DOS auf den Clients und ein MUMT-Betriebssystem auf den Servern eingesetzt werden. Die Steuerungs- und Kontrollfunktionen realisiert der Multiuser-Teil, die Parallelzugriffe das Multitasking. Damit hat DOS nach heutigem Kenntnisstand auf einem Server nichts mehr verloren.
Die Realisierung des MUMT-Betriebssystems im Server kann variieren: Entweder nimmt man ein echtes General-purpose-System wie Unix, eine spezielle LAN-Software wie Netware oder eine Kombination aus einem SUMT-System wie OS/2 und einer Multiuser-Erweiterung wie dem LAN Manager.
(wird fortgesetzt)