Die Nachteile der reinen OS/2-Systeme und die Stärken der konkurrierenden Produkte, wie Novell Netware und Banyan Vines, sind Thema dieses Artikels. Die jüngsten Verhandlungen zwischen IBM und Novell haben dieses Thema wieder in den Brennpunkt des Interesses gerückt.
Seit der Herausgabe des Betriebssystems OS/2 1988 haben OS/2-Netzwerke auf dem Markt nur eine untergeordnete Rolle gespielt. Hierfür gibt es vier Gründe:
- OS/2 ist neu, und niemand möchte der erste sein.
- Der OS/2 LAN Manager 1.x hatte ursprünglich nur einen eingeschränkten Leistungsumfang.
- Die Microsoft- und IBM-Versionen waren anfänglich nicht kompatibel.
- Die Konkurrenz, hauptsächlich Novell, war besser als erwartet auf die Auseinandersetzung mit dem neuen Konkurrenten eingestellt.
Als Neuling auf dem Markt für Netzwerk-Betriebssysteme vereint OS/2 die aus der Entwicklung anderer Netzwerkprodukte gewonnenen Erfahrungen mit der heutigen Einschätzung künftiger Erfordernisse. Doch hat es sich gezeigt, daß OS/2-Netzwerke noch keinesfalls so ausgereift sind, wie das beispielsweise bei einem bewährten Produkt wie Netware der Fall ist. Fehler in der Software sind bisher noch nicht entdeckt, und während Netware auf die überaus nützliche Netwire User Community als Forum für Anregungen, Kritik oder Wünsche zurückgreifen kann, gibt es bis dato bei OS/2 kein entsprechendes Gegenstück dieser Art.
Die Funktionalität ist nicht ausreichend
Als die erste Version des LAN Managers 1988 (als 3 + Open 1.0 von 3Com) auf den Markt kam, schnitt diese im Vergleich zur Novell-Netware nicht besonders gut ab.
Obwohl Verarbeitungs- und Übertragungsgeschwindigkeit durchaus konkurrenzfähig waren, fehlte ihm doch einiges des Leistungsumfangs von Netware, insbesondere was Datensicherheit, Benutzer- und Dateiverwaltung anging.
Spätere Versionen wie 1.1 enthielten eine Serveradaption des OS/2-Betriebssystem-Kernes; außerdem war es möglich, größere Dateien zu verarbeiten und mehr Dateien gleichzeitig geöffnet zu halten. Doch der anfängliche Boom war bereits etwas abgeebbt.
Umwandlung des Microsoft-Produkts
Der IBM OS/2 LAN Server 1.0, die IBM-Version des anfänglichen LAN Managers, wurde von einem IBM-Entwickler-Team in Austin so umstrukturiert, daß einige vom IBM-Marketing geforderten Features integriert werden konnten.
Hierzu gehörten eine Domain-based-Architektur, die PPC/LU6.2-Protokollunterstützung - ein dem Resource Allocation Control Facility (RACF) auf Großrechnern vergleichbares Zugriffssteuerungssystem - und eine SAA-CUA-Benutzerschnittstelle.
Vom ursprünglichen Microsoft-Produkt war nicht viel übriggeblieben, vollständige Netzwerkkompatibilität ließ sich aber auch nicht erzielen. Obwohl Microsoft-Server und -Workstations Meldungen weder senden noch empfangen und einige Features und Ressourcen nicht nutzen konnten, waren sie in der Lage, an der IBM-Domain-Dialogverarbeitung teilzunehmen und ließen sich deshalb auch in IBM-Domain-Menüs integrieren. Außerdem war es in der begrenzten Zeitspanne, die IBM für eine Architekturänderung des LAN Servers zur Verfügung stand, unmöglich gewesen, alle Menü-Features über die Befehlszeile oder im API-Level zu unterstützen. IBM-LAN-Benutzer, die versuchten, NET-Befehle im Batch-Modus zu starten, konnten nicht auf bestimmte Domains und Zugriffsberechtigungen zugreifen; damit lieferten sie zugleich den Beweis, daß eine der wichtigsten Behauptungen von Microsoft nicht der Wahrheit entsprach, nämlich daß der LAN Manager alternative Schnittstellen von vergleichbarem Funktionsumfang anbiete (vergleiche LAN Manager Architecture von Daryl Rubin, eine Veröffentlichung von Microsoft, die 1988 bei der Markteinführung des LAN Managers erschien).
Die Unternehmen waren allgemein verärgert, in das eine oder andere Lager gedrängt zu werden, ohne die Vorteile des besseren Produktes nutzen zu können. So kam es, daß nur wenige in eines der beiden Produkte investierten.
Mit der Ankündigung von Microsoft und IBM, sich bei der Entwicklung künftiger LAN-Produkte besser aufeinander abzustimmen, hat sich die Situation insgesamt geändert.
IBM hat Nachholbedarf
Die wichtigsten Punkte dieser gemeinsamen Strategie sind der Microsoft-Veröffentlichung "Using Microsoft LAN Manager with IBM LAN Requester and IBM LAN Server" entnommen (Microsoft Document Nr. SY098-15659-0890, September 1990):
- Der Microsoft- und der IBM LAN Manager (LM) kommunizieren bei vollständiger Kompatibilität über IBM-Token-Ring- oder Ethernet-Netzwerke, aber nicht über IBM-baseband oder -broadband-Netzwerke (obwohl dies bei der Verwendung von NDIS-Treibern für spätere Versionen durchaus machbar wäre).
- Bei Ethernet unterstützen sowohl der IBM- als auch der Microsoft LM die beiden Standards CIS und IEEE 802.3.
- Microsoft LM unterstützt weder den IBM Communication Manager, Database oder Office Vision.
- Microsoft LM ist unter dem IBM-OS/2- Extended-Edition-Kernprogramm nicht lauffähig.
- Die Domain-Unterstützung weist bei beiden LAN-Manager-Produkten leichte Unterschiede auf. Die Server sollten als Domains behandelt werden. IBM LAN Requester (Workstations) sollten das erste Einloggen nur innerhalb einer IBM-Domain durchführen, während Microsoft-Workstations sich in Domains jeder Art einloggen können. Dabei ist zu beachten, daß eine Workstation, die erst einmal eingeloggt ist, auf Ressourcen einer externen Domain jeder Art zugreifen kann.
- Der Microsoft LAN Manager bietet neben der auch bei IBM vertretenen Option User Security auch die Share Security. Allerdings kann eine IBM-Workstation auch auf normalem Wege über die Angabe des Paßworts auf die Microsoft-Ressource-Share-Security zugreifen.
- Der Zugriff der gemeinsame Ressourcen erfolgt beim IBM LAN Manager über einen Aliasnamen. Jede mit einem Aliasnamen versehene Ressource hat eine UNC-Bezeichnung (Universal Naming Convention); diese Zugriffsmethode entspricht der von Microsoft verwendeten.
- Das Drucken läuft bei Microsoft wie auch IBM ohne Einschränkungen, der Zugriff von den Workstations aus erfolgt aber in unterschiedlicher Weise.
Der gerade von IBM herausgegebene LAN Server 1.3 wartet mit dem neuen Microsoft-Druck-Spooler auf, womit Kompatibilitätsprobleme zwischen Workstations und Servern gelöst werden, indem auf einen proprietären Druck-Spooler verzichtet wird.
Weiterentwicklungen in der nun eingeschlagenen Richtung sind bei den nachfolgenden Versionen dieser Produkte zu erwarten. Dennoch darf nicht unerwähnt bleiben, daß der IBM LAN Server 1.x immer noch eine Version hinter der Microsoft-Variante hinterherhinkt, und daß es, was die Verpflichtung zur Verfolgung einer gemeinsamen Strategie angeht, bei IBM noch einigen Nachholbedarf gibt.
Einer der wichtigen Konkurrenten: Novell
Novell bietet mehrere Varianten zweier getrennt voneinander entwickelter Netzwerkprodukte an, Netware 286 und Netware 386. Netware 386 wurde Ende 1989 als Flaggschiff der Produktlinie herausgebracht und läuft nur auf Intel-286- (und höheren) Architekturen.
Novell konnte seine Marktpräsenz und seine Unternehmensstärke 1989 ausbauen, der Umsatz stieg von 327 auf 422 Millionen Dollar, obwohl zu dieser Zeit die OS/2-Attacke von IBM und Microsoft mit den 65 LAN-Manager-OEMs anrollte. Im zweiten Quartal 1989 wurde Novells britischer Marktanteil auf 66 Prozent geschätzt (Romtec LAN Survey, 5/89), bei den Fortune-1000-Firmen sogar auf 70 Prozent (Computer Intelligence Survey, 9/89).
Novell ist , durch die Kampfansage seitens Microsoft und IBM keineswegs in Schwierigkeiten geraten. Im Jahre 1989 brachte man Netware 386 auf den Markt, das Produkt mit dem größten Leistungsumfang in diesem Marktsegment. Die Novell-Versionen zeichnen sich zum einen durch eine konsequente Entwicklung hin zu offenen Standards aus, zum anderen hat Novell stets versucht, durch eine gezielte Investitionspolitik in verwandte Produkte vom Gateway bis hin zur Anwendersoftware die eigenen Versionen zusätzlich zu stärken und zu unterstützen.
Architektur wurde neu konzipiert
Funktionell gesehen ist Netware 386 die konsequente Weiterentwicklung des altbewährten Netware 286, obwohl die Architektur von Netware 386 völlig neu konzipiert wurde. Netware 386 bietet einen größeren Leistungsumfang, das heißt mehr Logon-Möglichkeiten, mehr Plattenspeicher, eine höhere Verarbeitungsgeschwindigkeit und mehr gleichzeitig geöffnete Dateien, aber auch eine verbesserte Systemverwaltung, eine dynamische Konfiguration und vereinfachte Installationsabläufe.
Darüber hinaus zeichnet sich Netware 386 durch seine im Gegensatz zu Netware 286 offenere Architektur aus. Sie ermöglicht das Hinzufügen von Real-mode-Modulen, wodurch die Funktionalität des Servers erweitert wird.
Novells Entwicklungskonzept geht dahin, mit Hilfe der Netware Loadable Modules (NLM) die Funktionalität der Server grundsätzlich zu erweitern. So unterstützt Netware 386 beispielsweise "Btrieve" als NLM, wodurch eine Client-Server-Datenbankverwaltung realisiert werden kann.
Auch hat man bei Novell dem Wunsch nach offenen Netzwerkprotokollen Rechnung getragen. Novells Network-Interface-Card-(NIC)-Standard ist dem NDIS von Microsoft vergleichbar. Es trägt den Namen Open Data Link Interface (ODLI, manchmal auch ODI) und ermöglicht mehrfache Transportprotokoll-Puffer, um auch auf eine einzelne NIC zugreifen zu können. Novell hat neben IPX/SPX noch weitere Transportprotokolle angekündigt. Netbios, TCP/IP und LU6.2 von IBM sollen offenbar bald auf den Markt kommen. Netware 386 unterstützt des weiteren Microsoft-kompatible Named Pipes, was Netware die Möglichkeit verschafft, OS/2-Client-Server-Anwendungen über Novell-Protokollpuffer laufen lassen zu können.
Wie Microsoft hat auch Novell erkannt, daß ein Bedarf für die Unterstützung durch Mehrprozessor-Systeme vorhanden ist. Netware 386 unterstützt bereits die Mehrprozessor-Konfigurationen der Compaq Systempro für 386er und 486er Prozessoren. Wie es aussieht, werden in Kürze auch andere Mehrprozessor-Rechner unterstützt werden.
1991 bringt Novell eine ganze Reihe neuer Features für seine Netzwerkprodukte auf den Markt. Der Remote Management Service ermöglicht einem dazu berechtigten Benutzer, von einer Workstation des Netzwerkes aus den externen Server zu verwalten und sogar neu zu starten.
Der Netware Name Service versetzt den Benutzer in die Lage, in einer multiplen Serverumgebung zu operieren. Dabei handelt es sich (beinahe) um ein Domain-System im IBM-eigenen Sinn; der einzige Unterschied ist, daß die Unterstützung für die zentrale Steuerung der Serverressourcen (gemeinsamer Plattenspeicher, gemeinsame Drucker etc.) und für IBMs ausgeklügeltes "Application Serving", das eine direkte Verbindung zu den "Program Starter Menus" der Workstations herstellt, noch nicht möglich ist. Die entsprechende Erweiterung, die bereits schon lange hätte vorliegen sollen, ist auf jeden Fall ein Schritt in die richtige Richtung.
Mit dem älteren Produkt, Netware 286, steuert Novell klar erkennbar auf ein Dilemma zu. Netware 286, das zur Zeit etwa 2300 Pfund kostet, ist speziell für kleinere Netzwerke (bis zu 100 Workstations mit einem Server) konzipiert. Netware 386 kostet zur Zeit etwa 6000 Pfund und ist speziell für sehr große Netzwerke mit einem einzigen Server gedacht. Wenn Produkterweiterungen auf den Markt kommen, dürfte es immer schwieriger werden, sie in die veraltete 286er Architektur zu integrieren.
Angesichts der Tatsache, daß Rechner, basierend auf der 286er Architektur, als Serverplattform zum größten Teil durch den 386er abgelöst werden, gibt es aus technischer Sicht keinen Grund mehr, Netware 286 zu kaufen. Der Anwender schränkt im Grunde nur den ihm potentiell zur Verfügung stehenden Funktionsumfang ein, wenn er die billigere Netware 286 kauft.
Microsoft fordert Novell heraus
Microsoft hat Novell dadurch herausgefordert, daß der Preis für den LAN Manager 2.0 sich an der Zahl der pro Server erforderlichen Workstations ausrichtet. Dadurch war es möglich, daß ein Anwender ein Startpaket mit zehn Workstations erwerben konnte, später ein weiteres für weitere zehn Workstations etc. Der allgemeine Leistungsumfang des LAN Managers bleibt davon unberührt. Es ist zu erwarten, daß Novell die Lizenzierung von Netware 386 künftig ändern muß, was gleichzeitig das Ende der 286er Produkte bedeuten würde. Auch könnte die vor kurzem mit IBM getroffene Vereinbarung manches interessante Produkt hervorbringen.
Die erste Vines-Version, die OS/2-Workstations unterstützt, war die Version 4.10, die seit Ende letzten Jahres auf dem Markt ist.
Die Ankündigungen einer strategischen Verbindung zwischen Banyan und Microsoft vom Sommer 1990 lassen jedoch erwarten, daß sich eine Harmonisierung von Vines und der Standard-OS/2-LAN-Manager-Umgebung in naher Zukunft vollziehen wird.
Ein wichtiger Microsoft-Standard, der von Vines übernommen werden müßte, ist die Verwendung von NDIS-Treibern für Vines-Workstation-Adapter. Dadurch wäre es möglich, daß DOS- und OS/2-Workstations, die an Vines angeschlossen sind, auch die zunehmende Bandbreite NDIS-kompatibler Karten nutzen könnte, ohne daß die Adaptertreiber verändert werden müßten.
Vines verwendet Microsofts SMB-Presentation-Layer-Protokolle, und die geplante Entwicklung deutet darauf hin, daß Vines-Server oder -Workstations in Zukunft in der Lage sein werden, verschiedene Services innerhalb eines Microsoft-LAN-Manager-Netzwerks zu nutzen.
Wie weit diese Entwicklung gehen wird (ob zum Beispiel ein Vines-Server in einer Microsoft-Domain arbeiten kann), bleibt abzuwarten.
Banyans Pionierleistung: Global Naming System
Dieses Gateway läuft auf einem Banyan-AT-Server, dem Corporate Network Server (CNS), oder auf 386- und 486-Server-PCs wie dem IBM PS/2 Modell 80 oder Compaq Systempro. Der CNS-Server kann entweder mit 386er oder 486er Prozessoren ausgerüstet bis auf 24 MB RAM, 2,2 GB Plattenspeicher vier Netzwerk-Schnittstellenkarten und 30 serielle Leitungen konfiguriert werden. Diesem Rechner steht eine X.25-Adapterverbindung zur Verfügung.
Banyan Vines wurde ursprünglich für einen Unix-Kernel geschrieben (Version 4.10 verwendet einen codeunabhängigen AT&T-Unix-V-Release-Kernel). Das bedeutet, daß ein Rechner, auf dem AT&T Unix V lauffähig ist, auch mit Banyan arbeiten kann.
Banyan hat kürzlich für Mehrprozessor-Rechner, insbesondere für Compaqs Systempro, Unterstützung in Form der Banyan Symmetric-Multi-Processing-Option (Vines SMP) angekündigt. Darüber hinaus werden auch die neuen EISA-Netzwerk-Adapterkarten sowie SCSI-Bandeinheiten und große Plattenspeicher unterstützt.
Banyans wahrscheinlich bekannteste Pionierleistung war das Global Naming System, das Namen und Adressen im Netzwerk verwaltet. Global Naming taucht momentan im Zusammenhang mit dem X.500-Standard und seiner Bedeutung für Regierungsstellen durch die Gosip-Standards in der Fachpresse auf. Banyans System firmiert unter dem Namen Streettalk und wurde dem X.500-Unterausschuß als Grundlage für ein System vorgestellt, daß sich an den vorgegebenen Standards orientiert.
Streettalk ( und das beabsichtigte X.500) verwaltet eine verteilte Datenbank für alle Benutzer und Ressourcen eines Servers. Die Server "wiederholen" die Namen und Identitäten von Benutzern und Ressourcen über ein willkürlich komplexes Netzwerk hinweg, so daß ein Benutzer einer Workstation Listen durchsuchen kann, um Objekte zu identifizieren (Benutzer von Ressourcen). Die Suche wird durch Verwendung von Aliasnamen für die einzelnen Ressourcen beziehungsweise durch "fuzzy searches" beschleunigt. Neuere Erweiterungen von Vines 4.10 haben die Namensuche verbessert, um den Datenaustausch im Netzwerk und die daraus resultierenden Verzögerungen zu minimieren.
Eine weitere Ergänzung ist das Dienstprogramm STDA (Streettalk Directory Assistant), das auf Servern und Workstations integriert wurde, bei DOS-Workstations in Form von TSR-Software. Dieses Programm ermöglicht es dem Anwender ganz gleich, auf welcher Ebene des Systems er arbeitet - eine globale Netzwerk-Verzeichnis-Anfrage für eine beliebige Ressource zu starten, wobei diese Anfrage entweder über den Namen, die spezifische Zuordnung oder über den Aliasnamen erfolgen kann. Dies ist besonders wichtig für Anwendungen wie beispielsweise die elektronische Post.
Vines 4.10 ist Banyans Standardprodukt. Diese Version, die eine Reihe von Erweiterungen gegenüber älteren Versionen beinhaltet, hat Vines' guten Ruf bezüglich der hervorragenden Anbindungsmöglichkeiten zwischen Host und Netzwerk weiter gefestigt. Die Host-Netzwerk-Konnektivität umfaßt auch IBM SNA und DEC LAT innerhalb einer breiten Palette möglicher Hardware-Verbindungsoptionen. Das Banyan-3270-Gateway bietet eine 3174-Emulation mit 16 bis 96 gleichzeitig aktiven Sitzungen, die entweder über SDLC- oder Token-Ring-Direktverbindungskarten laufen. IBMs Standard-Schnittstellen wie APPC/LU6.2 und Ehllapi werden ebenfalls umfassend unterstützt. Banyan bietet im Rahmen des 3270-Gateways eine Reihe außergewöhnlicher Features, darunter den Zusammenschluß von LU-Sitzungen, das Load-Levelling von Sitzungen (Steuerung der Arbeitsbelastung im Netzwerk), die Kommunikationsmöglichkeit über mehrere Gateway-Server hinweg und Unterstützung für Lichtgriffel auf Terminals mit 3270-Emulation.
Nur 60 KB RAM-Verlust
Auf DOS-Workstations unterstützt Banyan EMS und minimiert somit die RAM-Einbuße bei den Netzwerktreibern. Je nachdem, ob die richtigen Protokolle und Karten verwendet werden, kann ein Benutzer seinen RAM-Verlust auf lediglich 60 KB eindämmen.
Die Tatsache, daß Banyan das Prinzip des Symmetric-Multi-Processing in die letzte Version von Vines 4.10 SMP integriert hat, dürfte besonders für Anwender großer Systeme von besonderem Interesse sein. Dieses Konzept zielt in erster Linie darauf ab, Compaqs Systempro mit multiplen 386- oder 486-Prozessoren zu unterstützen, der nach dem Prinzip des queue-based-Multi-Processing arbeitet.
Banyan Vines bietet deshalb auch einige leistungsstarke Features, die für Anwender großer und komplexen Systeme von Bedeutung sind. Dennoch, das größte strategische Manko bei Banyan ist nach wie vor der Mangel an Offenheit. Vines ist auf Banyan-Servern stets sehr gut gelaufen, und viele der integrierten Features benötigen spezielle Serverunterstützung.
Vines hat es allgemein versäumt, alternative Transportprotokolle zu installieren, was sich bei der zunehmenden Komplexität strategischer Netzwerke als Problem herausgestellt hat.
Große Netzwerke hängen heutzutage häufig von TCP/IP ab, damit verschiedene externe Komponenten verbunden werden können. TCP/IP-Anwender erwarten, daß ihre Investitionen auch in Zukunft geschätzt sind, wenn TCP/IP eines Tages den OSI-TP4-Protokollen Platz machen sollte,
Vines unterstützt TCP/IP; darüber hinaus wurde bereits angekündigt, daß in Zukunft auch OSI TP4 unterstützt werden soll. Darin enthalten ist eine Übersetzungseinrichtung, die auf einem Vines-Server durchgeführt wird. Eine TCP/IP-Sitzung läßt sich auf einer Vines-Workstation starten. Gültige TCP/IP-Dialoge können im ganzen Netzwerk mit Hilfe von proprietären Protokollen auf dem Server durchgeführt werden. Der Dialog wird anschließend in einen TCP/IP-Paketstrom umgewandelt, der an einen echten TCP/IP-Host zu übertragen ist. Möglicherweise kann diese etwas ineffiziente und aufwendige Kommunikationsstruktur die Leistungsfähigkeit des gesamten Systems in der TCP/IP-Umgebung schwächen.
Vines hat ein ähnliches Problem wie Netware 386 - der Preis ist für ein kleines Netzwerk einfach zu hoch. Die Standardversion Vines 4.10 kostet etwa 6500 Pfund pro Server.
Trotz des unterschiedlichen Hintergrunds haben sich Novell und Banyan in der OS/2-Umgebung eine breite Anhängerschaft sichern können und stellen für den "strategischen" LAN Manager und die dazugehörigen Server-Produkte ernst zu nehmende Konkurrenten dar. Solange beide im Preis-Leistungs-Verhältnis sowie hinsichtlich der Konnektivität mithalten können, werden sie die Benutzer mit einer breitgefächerten Auswahl an Netzwerklösungen bedienen können. Darüber hinaus muß allerdings abgewartet werden, welche Konsequenzen sich aus der Verbindung zwischen IBM und Novell ergeben, da sie zu einer weitreichenden Veränderung des OS/2-Marktes führen kann.