Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

10.05.1991 - 

Kommunikation im Rahmen von OS2, Teil 1

OS/2 im Netz: Sinnvoll nur in einer reinen IBM-Welt

10.05.1991

Zwei Faktoren bestimmen die Leistungsfähigkeit eines Netzes: die Netzsoftware und sein Zusammenspiel mit den Betriebsystemen auf Servern und Workstations. OS/2 sollte hier die Kluft schließen, die zwischen den Möglichkeiten von MS-DOS und Unix bestand. Inzwischen ist die Kluft verschwunden. Übrig blieb eine Nische.

Richtig realisiert kann eine Vernetzung die Arbeit mit Personal Computern entscheidend verbessern. Auf der Basis von LAN-Standards wie IEEE 802 wurden Ethernet- und Token-Ring-Produkte entwickelt, die eine nachrichtentechnisch höchst leistungsfähige und problemlose Koppelung der Geräte erlauben.

Voraussetzung für eine sinnvolle Nutzung dieser Koppelung ist jedoch eine Brücke zwischen den Einzelplatz-orientierten PC-Betriebssystemen wie DOS oder OS/2 und einer netzfähigen Anwendung. Das heißt, die Leistungsfähigkeit einer Lösung steht und fällt mit dem verwendeten Netz-Betriebssystem und seinem Zusammenwirken mit den Betriebssystemen der Workstations und Server.

So wie die Dinge liegen, könnte sich ein Datenkommunikations-Manager heute eigentlich entspannt zurücklehnen und seine Workstations unter DOS mit Windows und die Server unter Unix laufen lassen wäre da nicht IBM, die einen immensen Druck in Richtung OS/2 ausübt.

OS/2 füllt eine nicht mehr vorhandene Lücke

Um es vorweg zu nehmen: Aus der Perspektive der Informatik und der Konstruktion von Betriebssystemen bräuchte man kein OS/2.

Vor zirka fünf Jahren bestand eine große, fast unüberwindliche Kluft zwischen der Leistung von DOS (in seinen damaligen Versionen) und den Möglichkeiten der Unix-Betriebssysteme. Es gab eine Reihe von Anwendungsprogrammen, etwa Desktop-Publishing-Programme, die unter DOS keine Chance hatten, angemessen zu laufen, und für die sich auch die Benutzung eines Unix-Systems - unter anderem wegen schlechter Wirtschaftlichkeit und haarsträubender Benutzeroberflächen nicht anbot.

Mit dem Aufkommen der 286- und 386-Prozessoren verstärkte sich der Bedarf für ein Betriebssystem "zwischen" dem Singleuser/Singletasking-System DOS und dem Multiuser-Multitasking-System Unix, und das wurde OS/2 mit Multitasking für einen Benutzer.

Der Markt für OS/2 war also vorhanden. Dennoch hat kaum ein Werbefeldzug jemals so wenig Wirkung bei den Benutzern gezeigt wie der für OS/2. Die Akzeptanz ist auch heute noch gering, und das mit gutem Grund. Denn auch die Hersteller von Anwendungsprogrammen haben sich zurückgehalten, und so wurde OS/2 von der Entwicklung der Betriebssysteme im wahrsten Sinne des Wortes zerquetscht: DOS plus Windows (Multitasking!) auf der einen sowie die neueren Unix-Versionen (hier besonders AIX 3) auf der anderen Seite haben die Kluft geschlossen, die OS/2 ursprünglich überbrücken sollte. Es gibt heute praktisch keine Anwendung mehr, die nicht unter dem einen oder anderen System vernünftig laufen könnte.

Konzeptionell ist Microsofts Standard Edition von OS/2 (OS/2 SE) ein Zwitter aus DOS und Unix. Selbst wenn in künftigen Versionen 32-Bit-Rechner und mehrere Benutzer unterstützt werden, bleibt fraglich, ob der fast jahrzehntelange Entwicklungsvorsprung von Unix noch aufzuholen ist. Während Microsoft sich noch mit den notwendigsten Erweiterungen abmüht, bastelt man an der Unix-Front schon längst an verteilten Systemen, bei denen die Ressourcen im Netz komplett abstrahiert und über ein Single System Image für den Benutzer verfügbar gemacht werden dadurch entfallen praktisch alle Probleme, die man heute in PC-Netzen kennt, aber das ist ein anderes Thema.

Um die heutige Rolle der IBM zu verstehen, muß man wissen, daß sie von Anfang an ein anderes Ziel verfolgte als Microsoft. Sie wollte ein Betriebssystem, das die logische und physische Einbindung von PCs in eine klassische SNA-Umgebung und die daraus abgeleitete SAA-Umgebung in weitaus höherem Maße unterstützt, als DOS dies je könnte. IBM hat deshalb von Anfang an die Standard Edition im Sinne seiner System-Anwendungs-Architektur (SAA) erweitert.

In der SNA (Systems Network Architecture) laufen die Verbindungen zwischen den Großrechner-Anwendungen und den Endgeräten logisch über sogenannte Sessions". Um die Aufgaben zwischen Host und Endgeräten besser zu verteilen, hat IBM eine Reihe von Konzepten entwickelt, die letztlich alle eine Session-Unterstützung erfordern, wie APPC (Advanced Program-to-Program Communication) oder SRPI/ECF (Server Requester Programmers Interface/ Enhanced Connectivity Facility). Will man diese Struktur um Funktionen für den Endanwender erweitern, wie etwa den Presentation- oder den Datenbank-Manager, so benötigt man Multitasking-Fähigkeiten und die Möglichkeit, dynamisch ladbare Module an das Betriebssystem anzulagern. Dazu aber wird DOS nie in der Lage sein.

Von den beiden OS/2-Varianten, die es gibt - der Standard Edition (SE) und der Extended Edition (EE) - ist die Extended Edition von IBM die einzig interessante und legitime Version - auch was die Datenkommunikation angeht.

OS/2 SE: Netztauglich erst mit dem LAN-Manager

Die OS/2 SE muß erst mittels des LAN Managers, einer gemeinsamen Entwicklung von Microsoft und 3Com, netztauglich gemacht werden. Von sich aus kann es im Netz nicht mehr als DOS, nämlich nichts. Dabei muß man unterscheiden zwischen OS/2 SE auf den Workstations und OS/2 SE auf den Servern. Auf den Workstations kann die Standard Edition über die gleichen Wege kommunizieren wie DOS - über Requester für die üblichen LAN-Betriebsprogramme (LAN Manager, Vines, Netware) -, und die Leistungen für den Benutzer unterscheiden sich kaum von denen, die ihm unter DOS/Windows zur Verfügung stehen (wenn man einmal davon absieht, daß die Integration der Betriebsmittel unter Windows eleganter ist). Wer also auf der Workstation unbedingt OS/2 SE fahren will, kann dies tun, ohne auf die üblichen Funktionen im Netz verzichten zu müssen.

Auf dem Server ist die OS/2 SE noch unwichtiger, da Novells Netware gar kein Betriebssystem auf dem Server braucht, Banyans Vines unter Unix läuft und auch der zusammen mit OS/2 SE vorgestellte LAN Manager mittlerweile für die Benutzung auf Unix-Servern angekündigt und teilweise auch schon ausgeliefert wurde.

Fazit: Außerhalb der IBM-Welt muß man für den Einsatz der OS/2 SE in den meisten Fällen erst mühsam einen Grund suchen (eine Ausnahme ist die Kombination von SE und LAN Manager für einen LAN-Server, den man nur zu diesem Zwecke benutzt). Was die Kommunikation angeht, können wir die Standard Edition also erst einmal "abhaken". Kommen wir statt dessen zu der wichtigeren Extended Edition.

OS/2 EE: Ein System für spezielle Fälle

IBMs OS/2 Extended Edition (EE) beinhaltet gegenüber der Standardausgabe zusätzlich einen Datenbank-Manager und einen Kommunikations-Manager. Letzterer versorgt die EE mit allen erforderlichen Kommunikations-Schnittstellen. Der Datenbank-Manager ist SAA-konform, arbeitet mit einer SQL-Schnittstelle und bietet Möglichkeiten zur Konvertierung vorhandener Daten (1-2-3, Dbase). Darüber hinaus ist er kompatibel zur Datenbank-Schnittstelle des Großrechners.

Für ein Grundsystem mit Kommunikations- und Datenbank-Manager sind mehr als 6 MB Hauptspeicher erforderlich (siehe Tabelle 1). Als Faustregel für den minimalen Speicherausbau gilt folgende Empfehlung:

- Requester möglichst nicht unter 5 MB,

- Server möglichst nicht unter 8 MB.

Im Kommunikations-Manager sind standardmäßig enthalten:

- asynchrone Kommunikations-Schnittstellen,

- die 3270-Emulation inklusive Drucker-Support,

- IBM-5250-Support,

- APPC-Schnittststelle,

- X.25-SNA-Support,

- LAN-Support für IBM- und Ethernet-LANs (Etherand),

- Gateway-Support.

Nicht enthalten ist die eventuell noch zusätzlich erforderliche Hardware.

Die Installation des Kommunikations-Managers erfolgt optional bei der Installation des Gesamtsystems, kann aber auch später leicht nachgeholt werden. OS/2 EE legt alle erforderlichen Directories automatisch an und überprüft sie auf Vollständigkeit. Standard-Konfigurationsdateien sind vorhanden und erleichtern die systemspezifische Anpassung. Diese wird vom Systemverwalter vorgenommen, der die entsprechenden Parameter hinzufügt und auf alle anderen Systeme überträgt. Aktivierte Features des Kommunikations-Managers können jederzeit angezeigt und verändert werden. Fehler beim Verbindungsaufbau oder während der eigentlichen Verbindung werden automatisch aufgezeichnet (auch Installationsfehler).

Die 3270-Emulation unter OS/2 EE ermöglicht dem Anwender den Aufbau von bis zu zehn simultanen Sessions (Nutzung der "Distributed-Function-Terminal-Funktion"). Filetransfer ist menügefürt oder aus der OS/2-Session heraus möglich. Wird das SRPI-Interface gewünscht, muß es gesondert generiert werden (es belegt etwa 300 KB zusätzlich). Die PC-Tast ist an die jeweilige Landessprache anpaßbar. APL wird bisher nicht unterstützt, dafür werden aber die IBM-Grafiksoftware-Treiber (GDDM) auch für OS/2 EE angeboten.

Die Gateway-Funktionen unter OS/2 EE sind sehr ausgeprägt. Pro Gateway lassen sich bis zu 255 LUs (logical Units) definieren; 64 davon können gleichzeitig aktiv sein. Aus der Sicht des Großrechners verhält sich das Gateway wie eine PU2 mit bis zu 255 LUs (1, 2, 3, 6.2). Aus der Sicht der Workstation ist das Gateway transparent. LUs können Gruppen zugeordnet und gepoolt werden. Verbindungen, die innerhalb einer vorgegebenen Zeitspanne nicht mehr aktiv waren, können automatisch durch das Gateway abgebaut werden, um die damit freiwerdenden Ressourcen anderen Benutzern anzubieten.

Auch an Ethernet-LANs angeschlossene OS/2-Workstations werden von den Gateways unterstützt. Voraussetzung dafür ist, daß in die PCs eine von IBM unterstützte Ethernet-Karte (von 3Com, Ungermann-Bass oder Western Digital) eingebaut ist. Welche IBM-Software im Token-Ring benutzt wird, ist für das Gateway nicht von Bedeutung. Es ist im wahrsten Sinne des Wortes "IBM-transparent".

Darüber hinaus unterstützt OS/2 EE auch die asynchrone VT100- und 3101-Terminalemulation. Von drei möglichen Verbindungen kann allerdings immer nur eine aktiv sein. Auch hier ist Filetransfer über IBM-kompatible Protokollkonverter unter TSO oder CMS und über das X-Modem-Protokoll (Blocklänge fest auf 128 Bytes) möglich. Die Kommunikation läuft über Fest- und Wählverbindungen mit Geschwindigkeiten zwischen 300 und 9600 Bit/s.

OS/2 EE unterstützt fünf Programmschnittstellen:

- 802.2,

- Netbios

- ACDI,

- APPC,

- SRPI.

Die Standard-Schnittstelle "Logical Link Control" (LLC oder 802.2),wurde im wesentlichen unverändert übernommen. Je nach Adaptertyp sind bis zu 254 sogenannte Link-Stations pro Adapter möglich. Der Aufruf erfolgt per CALL und nicht mehr - wie unter DOS - über einen Interrupt-Aufruf.

Das geräteunabhängige Asynchronous Common Device Interface (ACDI) ist nur unter OS/2 EE verfügbar. Es kann von mehreren Anwendungen gleichzeitig benutzt werden und als Grundlage für die Entwicklung eigener Terminalemulationen dienen.

Die Implementierung der APPC-Schnittstelle (Advanced Programm-to-Program Communication) in der OS/2 EE basiert auf den Regeln der LU6.2 (SNA). Mehrere Transaktionsprogramme können sich eine LU teilen, wobei sich zwischen zwei Partner-LUs mehrere Sessions parallel aufbauen lassen. Die Verwaltung der Session und die Regelung des Datenflusses erfolgt nur durch die LU. APPC-Anwendungen setzen keine 3270-Emulation und damit keinen IBM-Host im Netz voraus. Nach den Regeln der LU6.2 können auch Verbindungen zwischen zwei PCs oder Workstations aufgebaut werden, sofern eine davon die Funktionen des SSCP (System Service Control Point) des Mainframes übernehmen kann (PU 2.1). Voraussetzung für APPC unter OS/2 EE sind die Dynamic Link Libraries APPC.DLL und ACSSVC.DLL.

ECF/SRPI (Enhanced Connectivity Facility /Server Requestor Programming Interface) wird normalerweise nur zur Kommunikation zwischen IBM-Host (VM oder MVS/XA) und IBM-PC benutzt. Die Server-Funktion wird auf dem Host implementiert, das entsprechende PC-Programm wird als Requestor bezeichnet. Diese Schnittstelle ist nach wie vor die komfortabelste Schnittstelle zwischen Großrechner und PC, allerdings nicht so flexibel wie die APPC-Schnittstelle. Jedes Programm kann die SRPI-Schnittstelle aufrufen. Setzen zwei oder mehrere Requesterprogramme gleichzeitig das SEND_REQUEST-Verb ab, werden die Anforderungen vom SRPI nacheinander abgearbeitet.

Falls konkurrierende Anwendungen ihre Anforderungen über die SRPI-Schnittstelle gleichzeitig, aber über unterschiedliche 3270-Verbindungen stellen, werden diese auch gleichzeitig abgearbeitet.

Alle diese Schnittstellen sind entweder von IBM oder von anderen Herstellern auch unter DOS verfügbar. Es handelt sich dabei jedoch um relativ umfangreiche speicherresidente Programme, die kaum noch Platz für ein Anwendungsprogramm lassen und den Rechner schwer belasten.

In vielen Fällen wird man an den Arbeitsplätzen keine Maschinen einsetzen, die groß genug sind, um OS/2 EE auf ihnen laufen zu lassen. Wenn OS/2 EE auf einem LAN-Server installiert wird, macht dieser die Funktionen von OS/2 EE für eine größere Zahl von Anwendern mit kleineren Maschinen nutzbar. Eine Alternative hierzu bietet beispielsweise Novell, wo vergleichbare Kommunikationsfunktionen auf dem Netware-Server zu haben sind.

Große Unterschiede zwischen den beiden Möglichkeiten bestehen weniger bei der Kommunikationsunterstützung, als vielmehr beim Datenbankzugriff (Zugriff auf DB2-Daten, Query-Manager) und bei sonstigen Hilfsfunktionen (IBM-spezifische Erweiterungen für "klassische" IBM-Kunden). Nicht unterschätzen sollte man auch den Installationsaufwand, der bei OS/2 EE wegen der vielen Optionen und Funktionen weitaus höher ist als etwa bei einem DOS-System.

Praktisch sinnvoll ist der Einsatz von OS/2 EE letztlich nur in einer reinen IBM-Umgebung, und hier auf den Workstations wegen des großen Speicherbedarfs auch nur in besonderen Fällen.

LAN Manager (Microsoft):

Microsoft, der Entwickler von DOS und OS/2, bietet als Pendant zu IBMs LAN Server für OS/2 den LAN Manager an. Dieser LAN Manager stellt eine eigenständige Einheit dar und unterschied sich in den ersten Versionen stark von IBMs Konkurrenzprodukt. Inzwischen erfolgte jedoch eine Angleichung der beiden Systeme, so daß die Unterschiede im wesentlichen nur noch die Kommunikations-Schnittstellen (zur SAA-Welt der IBM) betreffen. LAN-Manager-Produkte werden von 3Com, Ungermann-Bass, Siemens und anderen vertrieben. Jedes dieser Produkte unterscheidet sich durch Zusatzprodukte und andere Oberflächen beziehungsweise Integrationshilfen für die jeweilige Herstellerwelt von den anderen. Die Basis aber ist für alle angebotenen Produkte gleich und wird im folgenden kurz beschrieben.

Wie schon unter DOS das PC-Netzwerkprogramm unterstützt der OS/2-LAN-Manager die gemeinsame Nutzung der am Server angeschlossenen Platten und Drucker. Im Gegensatz zu der Netzwerksoftware unter DOS benutzt der LAN Manager aber die Multitasking-Fähigkeit und den erweiterten Speicherbereich von OS/2. Bis zu zwölf Tasks können simultan ausgeführt werden. Der Server wird damit zu einem multifunktionalen System für alle angeschlossenen Systeme und entwickelt sich - von Leistung und Funktionsumfang - zunehmend zur Konkurrenz für klassische Systeme der Mittleren Datentechnik.

Einer der größten Vorzüge des OS/2-LAN-Managers sind die neuen Möglichkeiten der Benutzerkommunikation und des Informationsaustausches zwischen Prozessen, die "verteilt" im LAN ablaufen können. Zwei grundlegende Mechanismen stehen zur Verfügung: "Named Pipes" und "Mailslots".

Die Named Pipes werden vor allem für die Remote-Interprozeß-Kommunikation verwendet. Named Pipes ermöglichen Simplex- und Duplex-Kommunikation und erweitern die Funktionen der "normalen" Pipes unter OS/2, indem sie sowohl lokal als auch auf Distanz gleichermaßen verwendet werden können. Eine "unbenannte" Pipe gibt es bereits in DOS, allerdings nur auf die lokale Umgebung bezogen. So ließ sich zum Beispiel die Ausgabe eines Programms oder Systemkommandos - etwa DIR (Auflisten der Verzeichniseinträge am Bildschirm) - umleiten in ein anderes Programm, das sie sofort weiterbearbeitet (DIR: SORT > HUGO.DAT bewirkt, daß das Ergebnis des DIR-Befehls in sortierter Form in der Datei HUGO.DAT abgespeichert wird).

Named Pipes haben einen im gesamten Netzwerk gültigen eindeutigen Namen, der bei ihrer Erzeugung vergeben wird. Mit der Einführung der Named Pipes in OS/2 ist es möglich, über Standardschnittstellen auf die Ressourcen eines Rechners zuzugreifen, und zwar unabhängig davon, ob sie auf dem Rechner vor Ort, also der Workstation, auf dem Server oder auf beiden Rechnern verteilt installiert sind.

Wird diese Schnittstelle für die Anwendungsentwicklung benutzt, können die Programme einheitlich entwickelt werden. Es macht keinen Unterschied mehr, ob sich das Anwendungsprogramm auf einer Workstation, auf dem Server oder verteilt auf beiden Systemen befindet.

Sie sind damit ideal für den Aufbau der Client-Server-Anwendungen im LAN geeignet. Datenbankanwendungen mit dem Server als Back-end und dem Client als Front-end lassen sich leicht realisieren, vor allem, wenn für den Zugriff auf den Server eine Standardsprache wie SQL benutzt wird. Die Suche nach einem bestimmten Datensatz (Übergeben der Suchkriterien an den Server, Übernehmen des Ergebnisses) kann nun mit Hilfe einer Named Pipe realisiert werden.

Um mehreren Clients den gleichzeitigen Zugriff auf den Server zu gestatten, werden unter OS/2 sogenannte "Threads" genutzt. Threads ermöglichen die ParaIlelisierung von Abläufen innerhalb eines einzigen Prozesses. Dazu wird am Server eine vorgegebene Zahl gleichnamiger Named Pipes angelegt und bereitgestellt.

Dem Front-end-Prozeß wird nun immer die nächste freie Pipe zugeordnet. Dadurch entsteht für den Anwender der Eindruck des quasi parallelen Verarbeitens der Daten am Server. Welcher Bereich zugeordnet wurde, ist für den Anwendungsentwickler nicht von Bedeutung, da die Zuordnung automatisch erfolgt.

Andere Möglichkeiten der Interprozeß-Kommunikation bieten Netbios und die sogenannten "Mailslots". Netbios ist die aus der DOS-Umgebung bekannte Schnittstelle mit hoher Netzwerkabhängigkeit, aber auch mit ihrem hohen Komfort und ihrer enormen Schnelligkeit bei der Datenübergabe.

Mailslots dagegen sind ein sehr einfaches Hilfsmittel, kurze Nachrichten im Netz zu verteilen. Mailslots arbeiten verbindungslos und unidirektional und bieten keine Sicherungsmechanismen. Sie können mit Datagrammen verglichen werden. Wenn erforderlich, können Mailslots auch quittiert werden, ähnlich dem Verfahren der gelben Post, wo Einschreiben ebenfalls vom Empfänger quittiert werden müssen.

Wie hier heißt dies aber noch lange nicht, daß die Information wirklich weiterverarbeitet wird. Mailslots eignen sich ideal zum Absetzen von Meldungen an Gruppen oder an alle angeschlossenen Teilnehmer (Broadcasting).

LAN Server (IBM):

Der OS/2-LAN-Server von IBM basiert auf zwei voneinander unabhängigen Softwarepaketen. Das eine, das in der OS/2 EE enthalten ist, beinhaltet die sogenannte Requester-Funktion (Workstation-Funktionen), während das andere, das getrennt bestellt werden muß und OS/2 EE als Basis benutzt, die Server-Funktionen enthält. Hier zeigt sich bereits ein erster großer Unterschied zu den PC-LAN-Funktionen unter DOS, wo für, alle Systeme - sowohl für die Workstation (Requester) als auch für den Server - die entsprechenden Programme gekauft und installiert werden mußten.

Der Server muß nicht dediziert werden. Zum Beispiel ist es sinnvoll, bei nicht zu intensiver Nutzung des Servers den OS/2-LAN-Manager ebenfalls auf dem System zu installieren. In den meisten Fällen empfiehlt es sich allerdings nicht, den Server auch als Arbeitsplatz-Rechner zu benutzen, da zum einen die Performance darunter leiden kann und zum andern Sicherheitsgründe dagegen sprechen. Bedienungsfehler an dieser Workstation-Server-Kombination könnten dazu führen, daß alle Stationen im LAN blockiert würden.

Wie unter dem PC-LAN-Programm können die Server bei Bedarf zu einem einzigen logischen System zusammengefaßt werden, der sogenannten "Domäne". Genau wie dort definiert der Systemadministrator (ADMIN) Benutzer und Benutzergruppen, für die Anwender nutzbare Plattenbereiche, Netzwerkanwendungen, Druckerwarteschlangen sowie Endgeräte an asynchronen Schnittstellen, auf die von entsprechend autorisierten Benutzern oder Benutzergruppen zugegriffen werden kann.

Jeder Benutzer kann sich von jedem im Netz befindlichen Arbeitsplatz in das Gesamtsystem einloggen. Falls vom Administrator vorgegeben, muß der Benutzer zusätzlich ein Paßwort eingeben, das er dann selbst verändern kann. Vergißt er es, ist nur der Administrator in der Lage, das Paßwort zu lesen beziehungsweise zu ändern. Die gesamte Benutzerverwaltung erfolgt unter Zuhilfenahme der Presentation-Manager-Oberfläche erheblich komfortabler als bei DOS.

Der OS/2-LAN-Server kann auch von DOS-Workstations aus benutzt werden. Das PC-LAN-Programm ist hierfür ab der Version 1.2 des LAN-Servers nicht mehr erforderlich. DOS-Requester und IBM LAN-Support-Programm werden mit dem Server-Programm zusammen ausgeliefert. Die meisten Funktionen und Kommandos des LAN Servers stehen mit kleinen Ausnahmen auch unter DOS zur Verfügung.

Benutzer von DOS-Workstations können beispielsweise nicht selbst Programme auf dem Server zur Ausführung bringen (Batch-Verarbeitung). Es läßt sich nicht auf seriell am Server angeschlossene Endgeräte zugreifen (außer Drucker mit seriellen Schnittstellen), und es werden keine Ethernet-LANs unterstützt (was aus meiner Sicht eher ein Vor- als ein Nachteil ist).

Auch das LAN-API (Application Programming Interface) steht DOS-Anwendern - wenn auch mit Einschränkungen gegenüber OS/2-Workstations zur Entwicklung verteilter Anwendungen im LAN zur Verfügung. Hierzu zählen ab LAN-Server-Version 1.2 die Möglichkeiten der Interprozeß-Kommunikation mittels der Named Pipes und Mailslots, verschiedene Funktionen für die Netzwerkverwaltung sowie für zusätzliche Netzwerk-Utilities und Datenschutzmechanismen wie etwa die Paßwort-Verschlüsselung. Das LAN-API ist aus den gängigen Hochsprachen aufrufbar und erlaubt die Automatisierung vieler Vorgänge, vom automatischen Einloggen in die Anwendung auf einem Server bis hin zum automatischen Datentransfer nach vorgegebenen Auswahlkriterien.

Ein an einem OS/2-LAN-Server angeschlossener Benutzer hat auch Zugriff auf ältere Server oder DOS-Server, wenn sie im Server als EXTERNAL-Resource eingetragen wurden. Die Möglichkeit zur gleitenden Migration ist so sichergestellt. Der Administrator definiert:

- welche Netzwerkanwendungen für welche Benutzer erlaubt sind (Startup-Menü),

- die Zuweisung der Netzwerkplatten beziehungsweise Directories,

- die Druckerzuordnung und

- die direkte Endgerätezuordnung an den seriellen Schnittstellen.

Der OS/2-LAN-Server verfügt über ausgeprägte Zugriffsschutzmechanismen. Geschützt werden können - einzelne Dateien oder Dateigruppen,

- Anwendungsprogramme,

- der Zugriff auf Druckerwarteschlangen,

- der Zugriff auf serielle Endgeräte und

- der Zugriff auf externe Ressourcen.

Benutzer können zu Benutzergruppen zusammengefaßt werden und sind dadurch leichter verwaltbar. Der Administrator definiert außer den Benutzerprofilen die Profile für die jeweilige Anwendung auf dem Server.

Die Schutzmechanismen für den LAN Server sehen verschiedene Zugriffsrechte auf seine' Dateien beziehungsweise Dateigruppen vor, die untereinander kombinierbar sind. Zugriffrechte werden pro Benutzer, pro Gruppe und global vergeben. Wird für einen Benutzer keine, Autorisierung vorgenommen, so hat er auch keinerlei Zugriff auf die entsprechenden Ressourcen.

Dateien lassen sich auch so schützen, daß sie vom Benutzer nicht kopiert werden können eine nicht unbedeutende Tatsache, wenn man an die häufigen Probleme im Zusammenhang mit Raubkopien denkt. Der OS/2-LAN-Server selbst kann bis zu 8000 Dateien gleichzeitig verwalten. Auch größeren Datenbankanwendungen sind damit eigentlich keine Grenzen mehr gesetzt.

Zur Netzwerküberwachung stehen mehrere Möglichkeiten zur Verfügung. Bei Bedarf können sämtliche Zugriffe im LAN mitprotokolliert werden. Jeder Zugriff von einer Workstation mit einer falschen Benutzernummer oder einem falschen Paßwort wird automatisch mit Uhrzeit aufgezeichnet.

Automatisch zu startende Prozesse auf dem Server helfen beispielsweise, die Platten automatisch zu sichern. Der Prozeß oder das Programm läßt sich zeitgesteuert aktivieren.

Unterstützt wird auch die Nutzung mehrerer Drucker nebeneinander. Jeder Benutzer kann seine Druckjobs in der Druckerwarteschlange überprüfen und beeinflussen. Er wird informiert, wenn ein Druckauftrag abgearbeitet ist oder wenn ein Fehler auftrat. Der Administrator hat Sonderrechte und kann auf alle anstehenden Druckaufträge zugreifen.

Um die Auslastung der Drucker zu verbessern, besteht die Möglichkeit, sie zu Gruppen zusammenzufassen (Administrator). je nach Bedarf werden dazu eine Warteschlange für mehrere Drucker oder aber mehrere Warteschlangen für einen Drucker eingerichtet (das empfiehlt sich, wenn beispielsweise der Drucker mit speziellen Schriftarten, Papierarten, Fonts etc. geladen werden soll).

Der direkte Zugriff auf die seriellen beziehungsweise parallelen Schnittstellen ermöglicht unter Kontrolle des jeweiligen Anwenderprogramms und ohne Spooling den Zugriff auf am Server angeschlossene Systeme wie Digitizer oder Hochleistungsplotter, Scanner etc.

Auch der Zugriff auf serielle Endgeräte läßt sich mittels des LAN-API automatisieren beziehungsweise steuern. Mehrere gleichartige Endgeräte können zu einem Pool zusammengefaßt und verwaltet werden, so daß mehrere Anwendungen über eine Warteschlange gleichzeitig Zugriff auf die Endgeräte im Pool haben. Die folgenden API-Aufrufe stehen zur Steuerung serieller Endgeräte durch ein Anwendungsprogramm zur Verfügung:

- Anzeigen aller verfügbaren Geräte eines Pools,

- Anzeigen aller Geräte-Pools,

- Informationen über spezielle Geräte,

- Löschen von nicht ausgeführten Befehlen in einer Warteschlange,

- Verändern des Zustands einer Wartesschlange auf dem Server,

- Löschen von Requester-Anforderungen, die aus irgendwelchen Gründen nicht zu Ende ausgeführt wurden, sowie

- Stoppen eines Gerätes, auch wenn es gerade durch eine Anwendung belegt ist.

Auf andere Funktionen des OS/2-LAN-Servers soll hier nicht näher eingegangen werden (näheres dazu findet sich im IBM OS/2 Extended Edition Cookbook). Eine Übersicht über die wichtigsten Kommandos zeigt die Tabelle 2.

Alles im allem ist Microsoft und IBM mit dem OS/2-LAN-Server ein nahezu perfektes Netzwerk-Betriebssystem gelungen. Erst mit OS/2 und dem LAN-Server besteht die Möglichkeit, Programme direkt auf dem Server auszufahren und abgestufte Zugriffsrechte für die einzelnen Dateien zu definieren. Die Definition von mehreren Warteschlangen pro Endgerät beziehungsweise die Zuordnung mehrerer Endgeräte zu einer Warteschlange erleichtert dem Benutzer den Zugriff auf solche Geräte und erhöht den Durchsatz. Der Presentation Manager vereinfacht die Bedienung des Systems und erlaubt endlich die vernünftige Darstellung mehrerer Prozesse am Bildschirm, wie dies bei Apple- und Xerox-Systemen schon seit Jahren möglich ist.

Ob dieser Sprung nach vorne ausreicht oder ob die Konkurrenz (Novell und Unix) wieder an OS/2 vorbeizieht, werden die nächsten Monate und Jahre zeigen. Microsoft setzt auf die Weiterentwicklung von OS/2 für den 80386/486-Prozessor und bietet den LAN Manager auch für das Unix-Betriebssystem an. Die Chancen stehen damit nicht schlecht, weitere Anteile an diesem zukunftsträchtigen Markt hinzuzugewinnen.

Noch aber ist die Schlacht nicht geschlagen. Sun, AT&T, Locus und auch IBM und Co. erweitern kontinuierlich die Netzwerkfunktionen unter Unix nach unten (zu DOS, OS/2) und oben (IBM SAA, Decnet, ISO/OSI Networking etc.). Novell und Banyan als große Netzwerkhersteller sorgen im DOS-, OS/2- und Unix-Bereich dafür, daß dem Anwender nach wie vor die Wahl zur Qual wird.