Die lntegrationsfähigkeit von Unix-Rechnern in einem Verbund mit anderen Maschinen ist ein entscheidender Faktor bei der Systemauswahl. Deshalb haben die Hersteller begonnen, ihre Produkte mit den erforderlichen Funktionen auszustatten. Eine Ergänzung des "klassischen" Spektrums von Unix um moderne Konzepte der Kommunikation fördert die Konkurrenzfähigkeit dieses Betriebssystems im Markt.

Unter einem Verbund, versteht man die Zusammenarbeit von mehreren Einzelkomponenten zur gemeinsamen Erfüllung einer Aufgabe. Aus der vorteilhaften Kombination der Eigenschaften der Einzelkomponenten ergibt sich eine wirtschaftlichere Betriebsweise. Dies betrifft unter anderem die Sicherung eines ununterbrochenen Betriebsablaufes trotz lokaler Ausfälle oder Störungen und die gleichmäßige und rentable Auslastung der vorhandenen Kapazitäten.

Einzelkomponenten müssen zusammenspielen

Bezogen auf das Thema bedeutet dies, die Einzelkomponente Unix-Rechner hinsichtlich ihrer Eignung für ein vorteilhaftes Zusammenspiel in einem Verbund mit anderen Komponenten (Terminals, PCs, Mainframes) zu betrachten.

Der Markt folgt heute bei der DV-Konzeption der Vorstellung des Distributed Data Processing (DDP), der verteilten Verarbeitung, die auf dem Prinzip des Verbunds aufbaut. Die Daten kommen dabei möglichst am Ort ihres Entstehens oder ihrer Verwendung zur Verarbeitung, Server werden an wirtschaftlich günstigen Plätzen bereitgestellt, die Verbindung der Verarbeitungsinstanzen erfolgt über öffentliche oder private Netzwerke.

Zur Verständigung müssen geeignete Protokolle eingehalten werden. Weil die Kommunikation nur bei Beherrschung des entsprechenden Protokolls gelingen kann, erfolgt deren Definition in internationalen Standards im Rahmen der Open System Interconnection (OSI), die im Basisreferenzmodell ein Rahmenwerk für die Kommunikation vorgibt. Es ist das Standardmodell für den Verbund von DV-Systemen.

Mit Unix gelingt es nun relativ schnell und auf einfache Weise, für Endbenutzer eine portable und komfortable Arbeitsumgebung zu schaffen. Dieses Betriebssystem bietet sich von daher also für die lokale Verarbeitung geradezu an. Für einen Einsatz im Sinne des DDP müssen die Unix-Rechner noch die entsprechenden Protokolle beherrschen können. Dieser Aufgabe des Networking haben sich alle Hersteller von Unix-Rechnern gestellt; sie begannen, ihre Systeme mit entsprechenden Funktionen auszustatten. Die Probleme sind aber nicht einfach oder ad hoc zu lösen.

Eine Erörterung von Unix-Rechnern im Verbund ist eine Betrachtung der Realisierung des Networking in Unix, von seiner historischen Entwicklung über den gegenwärtigen Stand in der Implementierung der Normen zu den absehbaren Weiterentwicklungen.

Heterogener Verbund fußt auf homogenem Unterbau

Ein Verbund von Rechnern läßt sich in "homogen" und "heterogen" klassifizieren. Im allgemeinen ist ein konkreter Verbund heterogen, aber es sind stets lokale homogene Teilverbunde erkennbar. Ein Beispiel für die folgende Betrachtung zeigt die Abbildung auf Seite 51, in der ein typischer heterogener Verbund dargestellt ist. Unix-Rechner, die einen homogenen Teilverbund bilden, sind in einem heterogenen Verbund mit Mainframes und PCs gekoppelt.

Die weitere Darstellung folgt der historischen Entwicklung. Ausgehend vom homogenen Verbund erfolgt die Weiterentwicklung in den heterogenen Verbund durch Einbeziehung zusätzlicher Kommunikationsbeziehungen und Konzepte.

Eine problemlose Kommunikation ist am schnellsten unter gleichartigen Systemen realisiert. Das war auch für Unix der Ausgangspunkt.

Ursprünglich zur Bereitstellung einer komfortablen, dezentralen Programmierumgebung entworfen und entwickelt, enthielt Unix zunächst nur Mechanismen zum materiellen Transfer von lokal erarbeiteten Ergebnissen über Datenträger (Magnetbänder und Lochstreifen) zum Ort der Weiterverarbeitung oder des Einsatzes. Diese wurden jedoch schnell um den batchorientierten Dateitransfer "uucp", der mit einem "store and forward"-Mechanismus arbeitet, und eine interaktive Kommandoschnittstelle "cu" ergänzt.

Dabei handelt es sich um Standardtools, die in jeder Unix-Version vorhanden sind. Sie arbeiten über das Fernsprechnetz oder Standleitungen, sind aber primär für die Kommunikation von Unix-Systemen untereinander vorgesehen. Es sind keine speziellen Erweiterungen im Betriebssystem erforderlich, uucp und cu setzen auf den Funktionen auf, die für die Unterstützung von Terminals über Wählverbindungen ohnehin vorhanden sind.

Mit diesen Mitteln lassen sich durchaus erfolgreiche und zweckgebundene Kommunikationsbeziehungen aufbauen, insbesondere für Mail, Softwareverteilung (kleine Datenmengen) und Print-Server. Erfolgreiche Mail-Netze sind das Usenet, mit dem EUnet als europäischem und dem von der Universität Dortmund betreuten Dnet als deutschem Teilnetz. In ihm sind mehrere tausend Systeme verbunden, über Gateways ist auch der Zugang zu zahlreichen anderen Netzen möglich.

Weniger vorteilhaft ist aber die Vielfalt der Protokolle, die sich aus individuell möglichen und erfolgten privaten Optimierungen von uucp ergibt. Auch die spezielle Adressierung der Empfänger mit teilweise kryptischen Namen, wo Tippfehler erfahrungsgemäß zu Datenverlusten führen, zusammen mit der fehlenden End-to-end-Sicherung, ist nur im Bereich unkritischer Daten akzeptabel. Die wenigen Recovery-Funktionen und die Batch-Orientierung lassen dieses Verfahren für allgemeines Networking als nicht praktikabel erscheinen.

Ethernet setzt sich als Standard durch

Die Entwicklung schlug dann auch bald eine neue Richtung ein, insbesondere ausgelöst durch den technologischen Fortschritt bei Local Area Networks (LAN), den lokalen Netzwerken. In der Unix-Gemeinschaft hat sich vor allem der Ethernet-Standard durchgesetzt, auf dem Internet-Protokolle, zum Beispiel Transmission Control Protocol (TCP), User Datagram Protocol (UDP) und Internet Protocol (IP) gefahren werden. Wegen ihrer Performance und ihres Durchsatzes gestatten sie einen Ansatz, der nahegelegt wird durch das Konzept der Unix-Architektur, jegliche I/O auf Dateizugriffe abzubilden.

Ein Ansatz für die Verteilung eines Unix-Systems zur Durchsatzerhöhung ist das Konzept der Satellitenrechner. Um einen zentralen Unix scharen sich Satellitenrechner, die nur Prozessor, Hauptspeicher und Netzanschluß enthalten. Sie bekommen vom Zentralrechner das Betriebssystem in Form eines abgemagerten Unix-Betriebssystemkerns und Benutzerprozesse zur Ausführung zugeteilt. Um Systemaufrufe zur Peripherie (Datensystem) oder Prozessverwaltung zu erfüllen, führt der Satellit eine Kommunikation mit einem Stellvertreterprozeß in der Zentrale, der die Aufrufe ausführt und die Ergebnisse zurückmeldet, aus.

Da in Unix jegliche I/O über Dateien realisiert wird, läßt sich schon durch Ausdehnung des Dateibaumes über Rechnergrenzen hinweg für die Anwender eine signifikante Erweiterung der Funktionalität erreichen. Das angestrebte Ziel ist hierbei, das unterliegende Netzwerk für den Anwender völlig transparent zu machen, also im Dateibaum die Übergänge über die Rechnergrenze in derselben Weise transparent zu gestalten, wie den Übergang zu einem als Teilbaum montierten (lokalen) Dateisystem. Das heißt, alle I/O-Funktionen sollen in derselben Weise funktionieren, unabhängig davon, ob sie im lokalen oder einem fernen System wirksam werden.

Auf diese Weise lassen sich dann Ressourcen wie Drucker, Massenspeicher und andere I/O-Geräte im Verbund teilen, ohne daß sich die jeweiligen Benutzerprogramme des Standortes des Gerätes bewußt sein müssen. Derartige Transparenz kann mit verschiedenen Konzepten erreicht werden, die sich in ihrem Aufwand bezüglich Änderungen am Betriebssystem als auch in ihrer Leistungsfähigkeit unterscheiden.

Namensraum wird um einen System-Anteil erweitert

Bei der Newcastle Connection wird die Verteilung des Dateisystems in der C-Bibliothek ohne Änderung des Kernels durchgeführt. Durch Erweiterung des Namensraumes des Dateisystems um einen "System-Anteil", der mittels spezieller Zeichen oder Präfixes vom Rest, nämlich dem üblichen Pfadnamen einer Datei abgetrennt ist, können die Funktionen der C-Bibliothek entscheiden, ob sich ein Aufruf auf eine Datei im lokalen oder fernen System bezieht. Demgemäß wird der entsprechende Aufruf an das lokale System abgesetzt oder über einen Kommunikationsweg als Nachricht an einen Stellvertreter im fernen System zur Ausführung geschickt.

Damit läßt sich der Zugriff auf ferne Dateien ohne Änderungen im Betriebsystem realisieren. Allerdings wird die C-Bibliothek durch die zusätzlich erforderliche Verarbeitung aufgebläht, wodurch sich das lokale Systemverhalten ändert.

Zudem entsteht ein Kompatibilitätsproblem, da vorhandene Programme ohne Rekompilierung die neuen Leistungen nicht nutzen können. Wegen einer aufwendigen Sicherheitsphilosophie zur Wahrung des üblichen Zugriffsschutzes und eines praktikablen Wiederanlaufes lassen sich außerdem Auswirkungen auf die Flexibilität nicht vermeiden. Aufwendig sich auch die administrativen Maßnahmen beim Hinzufügen und Entfernen von Systemen, da keine zentrale Betriebssysteminstanz die Koordination zum Netzwerk hin hält. Daher liegt es nahe, zur Transparenz des Zugriffs auf ferne Dateien tiefer im System anzusetzen.

Verteilte Dateisysteme ermöglichen es, Koordination zu erreichen. Im Unterschied zur Newcastle Connection wird die Verteilung in den Routinen für die Verwaltung des Dateisystems im Kernel vorgenommen, an Hand einer erweiterten "Mount"-Tabelle. Ferne Dateisysteme werden in den lokalen Baum montiert, bei Übergängen über die Montagepunkte werden die Aufträge als Nachrichten an Server oder Stellvertreter im fernen System zur Ausführung weitergeleitet. Die bekanntesten Konzepte für das verteilte Dateisystem sind das Network File System (NFS) von Sun und das Remote File System (RFS) von AT&T in Unix System V.

NFS arbeitet auf der Basis UDP und IP im Ethernet und verwendet an höheren Protokollen Remote Procedure Call (RPC) und External Data Representation (XDR). Es ist auch für heterogenen Einsatz konzipiert. RFS wurde für volle Unix-Kompatibilität im Dateisystem, also auch für "Names Pipes" und Gerätedateien ausgelegt und ist für den homogenen Unix-Einsatz vorgesehen. Die Netzwerkunterstützung ist soweit modularisiert und standardisiert, daß der Einsatz in privaten und öffentlichen Netzen mit offiziellen OSI-Protokollen möglich ist.

Neben diesen beiden Konzepten existieren weitere herstellerspezifische Realisierungen. Allen ist gemeinsam, daß sie, um eine akzeptable Performance zu bieten, auf schnelle lokale Netze angewiesen sind.

Sie kommen im wesentlichen in Unix-Systemen zum Einsatz, obwohl sie durch die nachrichtenorientierte Kommunikation zumindest prinzipiell im heterogenen Verbund einsetzbar sind. In diesem Falle müssen dann Probleme mit der Syntax gelöst werden, nämlich die maschinen- und systemabhängige Darstellung der Nachrichten. Auch für die Semantik gilt es Anpassungen vorzunehmen; dies ist erforderlich wegen des in Unix realisierten Zusammenspiels von Systemaufrufen und Signalen. Die Weiterentwicklung wird hier durch die Arbeiten internationaler Normierungsgremien im Bereich Abstract Syntax Notation (ASN) und Remote Procedure Call (RPC) beeinflußt werden. Die ursprünglich homogen orientierte Entwicklung in Unix schreitet also durch die zunehmende Abstraktion der Services von selbst in die heterogene Richtung fort.

Öffentliche Netzwerke gewinnen an Bedeutung

Neben der Vernetzung von Unix-Rechnern mit Mainframes und PCs über Inhouse-Netze erfolgt der Verbund zunehmend über öffentliche Netzwerke, Wide Area Networks (WAN), wobei paketvermittelnde Netze gemäß des internationalen Standards X.25, (in der Bundesrepublik das DatexP-Netz) zunehmend an Bedeutung gewinnen. Wer den X.25-Standard beherrscht, kann prinzipiell weltweit auf Netzebene mit einheitlicher Adressierung, zuverlässigem Service, End-to-end-Sicherung und fairen Tarifen rechnen.

Das zu lösende Problem für die Hersteller von Unix-Rechnern ist also die Unterstützung der in den öffentlichen Netzwerken verwendeten Protokolle. Sie umfaßt aber nicht nur die eigentlichen Netzprotokolle, wie X.25, sondern auch darüberliegende Protokolle, wie sie in der Netzarchitektur der Mainframes festgelegt sind. Die zwei heute in der Bundesrepublik am weitesten verbreiteten Netzarchitekturen sind SNA von IBM und Transdata von Siemens.

Stationskopplung dient als Ausgangspunkt

Die meisten Unix-Rechner beinhalten die Unterstützung einer oder beider Netzarchitekturen. Wie im homogenen Fall wird meistens zuerst von der Stationskopplung ausgegangen. Das heißt, daß statt eines gewöhnlichen Terminals, an dem üblicherweise ein Mensch sitzt, nun ein Unix-Rechner über dieselbe Leitung angeschlossen wird. Die Attraktivität dieser Lösung ist offensichtlich: Es ist kaum Aufwand in der Konfiguration von Hardware oder Software nötig. Auf dieser Basis wird zunächst ein mehr oder weniger leistungsfähiger Filetransfer und eine Geräte-Emulation (zum Beispiel für 3270 oder 9750) freigegeben. Bei Verwendung dieses Zugangs als Programmschnittstelle zur Anwendungs-Anwendungs-Kommunikation ergeben sich verschiedene Einschränkungen:

- Die Dateneingabe durch einen Menschen am Terminal erfolgt um Größenordnungen langsamer und seltener als durch ein Programm. Die Zielanwendung und ihr Umfeld müssen darauf vorbereitet sein, es sind daher Vorkehrungen zur Regelung der Datenrate erforderlich.

- Ein Mensch kann durch seine Assoziationsfähigkeit bei Störungen in der Ausgabe problemlos sinnvoll fortfahren, wogegen für ein Programm aufwendige Recoverymechanismen erforderlich sind. Hierzu aber bieten die Stationsprotokolle allein zu wenig Unterstützung, zusätzliche Maßnahmen beim Datenaustausch (Dialogorientierung, logische Quittungen) müssen getroffen werden.

- Über ein Terminal erfolgt der Datenaustausch im allgemeinen durch Übertragung von Bildschirminhalten, also begrenzt in der Länge, eventuell versehen mit Gerätesteuerzeichen, oft mit gerätespezifisch codierten Daten.

Von dem anfänglich durch die Beibehaltung der Konfiguration Gesparten muß dann doch wieder ein wesentlicher Teil reinvestiert werden, um durch Aufbesserung der Stationsprotokolle diesen Einschränkungen abzuhelfen. Dennoch ist dieser Weg als ein Migrationspfad für eine Übergangszeit unersetzlich.

Eine uneingeschränkt verwendbare Programmschnittstelle zur Anwendungs-Anwendungs-Kommunikation folgt im Zuge des Übergangs von der Stationskopplung auf die Rechnerkopplung unter Verwendung zuerst herstellerspezifischer, dann standardisierter OSI-Transport-protokolle. Sie bieten Anwendungsinstanzen den Dienst, Daten theoretisch unbegrenzter Länge transparent, das heißt unverändert, in Struktur und Inhalt unter Regelung der Übermittlungsrate auszutauschen.

In heutigen Unix-Rechnern sind für deren Implementierung verschiedene Ansätze verfolgt worden. Zur Realisierung wird eine Dreiteilung der Funktionalität vorgenommen in das Endbenutzer-Interface, die Protokoll- und Zustandsmaschinen für die Steuerung der Protokollabläufe und das Geräte-Interface zum Netzanschluß. Das Geräte-Interface liegt immer in einem Treiber im Betriebssystemkern vor, die beiden anderen innerhalb oder außerhalb der Kerns.

Aufrufe sind zu einer Funktion zusammengefaßt

Im Bereich der Benutzerprozesse ist es die einfachste Methode, die Funktionalität dem Endbenutzer in Funktionsbibliotheken und mehr oder weniger vielen Server-Prozessen anzubieten. Abgesehen von der Mehrbelastung des Speichers durch die Funktionsbibliotheken ist dieser Ansatz wesentlich durch die Leistungsfähigkeit der Kommunikation zwischen Server- und Endbenutzerprozessen beschränkt. Der Kern enthält nur den Treiber für das Geräte-Interface.

Die klassische Methode zur Realisierung ist aber die Implementierung eines Treibers für ein zeichenweise arbeitendes Gerät, wobei der Schwerpunkt der Funktionalität auf dem dafür gebotenen Steueraufruf "ioctl" liegt. Solche Aufrufe werden in der für die einzelnen Kommunikationsschritte adäquaten Weise zu einer Funktion zusammengefaßt und unter einem sinnfälligen Namen in einer Funktionsbibliothek abgelegt.

Die Protokoll- und Zustandsmaschinen liegen oft ebenfalls in diesem Treiber vor, werden aber bei zunehmender Komplexität der Protokolle in ladbare Prozessoren ausgelagert, die dann auch den Netzanschluß bedienen. Das Geräte-Interface reduziert sich damit auf die Bedienung dieser Prozessoren, die Protokoll- und Zustandsmaschinen umfassen nur noch Teile der obersten Protokollschicht.

Der Treiberansatz hat sich prinzipiell bewährt, bedarf aber noch der Verbesserung. Vor allem müssen solche Erweiterungen intensiv unter dem Gesichtspunkt der Portabilität des Systems betrachtet werden, damit der Anpassungsaufwand an neue Systemfreigaben von Unix minimiert wird. Da für die Unterstützung von Netzwerken flexible Kombinationsmöglichkeiten von Protokollschichten und diverse Basisdienste erforderlich sind, entstehen gelegentlich redundante Funktionskomplexe, wenn keine adäquaten zentralen Mechanismen vorhanden sind.

Ein Beispiel ist die Pufferung von Nachrichten. Die für Terminals vorhandenen Mechanismen reichen dafür nicht aus, da sie im Prinzip zeichenorientiert sind. Auch diejenigen für Massenspeicher erweisen sich als ungeeignet, da unerwünschte Interferenzen mit dem lokalen Dateisystem und dem Sekundärspeicher (paging, swapping) auftreten können. Wegen der fixen Länge der Puffer entsteht Verschnitt, wenn die Nachrichtenlängen über ein relativ breites Spektrum verteilt sind.

Sockets bilden Interface zu den Benutzern

Verfügbare Unix-Systeme bieten zur Verbesserung zweierlei Standardmechanismen: Sockets und Streams. In den Unix-Derivaten der Berkeley System Distribution (BSD) der Universität von Berkeley, Kalifornien, (UCB), ist mit "Sockets" ein Mechanismus realisiert, der in einheitlicher Weise Networking und Interprocess Communication UPC) unter einem gemeinsamen Konzept vereinigt. Von der Architektur her ist die Dreiteilung realisiert in der Socket-, Protokoll- und Netzwerk-Schicht.

Die Sockets bilden die Schnittstelle zu den Benutzern. Sockets, die Kommunikationsbeziehungen gleicher Art (Namen, Adressen, Protokolle) tragen, sind in Domänen zusammengefaßt. Als die gebräuchlichsten gelten die Unix-Domäne für die IPC und die Internet-Domäne für Networking unter Verwendung der Internet-Protokolle TCP, UDP und IP. Die Protokollsäulen liegen in der Protokollschicht, müssen allerdings per Systemkonfigurierung eingebracht werden. Die Netzschicht stellt den Anschluß zur Hardware des Netzwerkes her. Die Nachrichtenpufferung erfolgt über einen zentralen "Message Buffer"-Mechanismus (mbuf).

Lange Zeit waren die Sockets der einzige komfortable Standardmechanismus für Networking. Kürzlich erfolgte nun durch den Lizenzgeber AT&T auch in System V die Freigabe eines einheitlichen Basismechanismus zur gemeinsamen Unterstützung der IPC und des Networking.

Protokollmodule werden dynamisch verknüpft

Streams bieten eine Infrastruktur zur dynamischen Verknüpfung von Protokollmodulen für Networking und IPC. Das Konzept wird abgerundet durch eine eigene Speicherverwaltung und einen eigenen Scheduling-Mechanismus. Auch hier ist eine Dreiteilung sichtbar. Zunächst der Kopf des Stream, ferner eine Modulsequenz und der Gerätetreiber für die Anschlußhardware. Der Kopf des Stream stellt über Systemaufrufe die Schnittstelle zum Benutzer dar. Die Modulsequenz enthält dynamische konfigurierbare Module, die die stromauf (zum Benutzer) oder stromab (zum Gerät) laufenden Daten verarbeiten.

Bei Streams handelt es sich um einen Allzweckmechanismus zur Förderung der Modularisierung von Gerätetreibern. Er kommt dort zum Einsatz, wo die dynamische Verknüpfung von Leistungen und ein neues Konzept erforderlich ist. Außerdem steht er im Einklang mit der Unix-Tradition und fördert die Flexibilität und Portabilität des Systems entscheidend. AT&T-Standardpakete für Networking, RFS und das Transport Level Interface (TLI) setzen auf Streams auf.

Die Leistungsfähigkeit eines neuen Konzeptes zur Netzeinbettung wird oft daran gemessen, inwieweit sie für den Benutzer das Netzwerk unsichtbar macht, das heißt insbesondere, ob sie die vertrauten Schnittstellen und Konzepte über das Netzwerk hinweg tragen kann.

Ein Beispiel soll dies verdeutlichen. In einem Verbund von Unix-Systemen, der über die lokalen Funktionen hinaus zusätzliche Leistungen bietet, erwartet der Anwender, daß er über eine "Remote Login Facility" verfügen kann. Das bedeutet, er will von seinem Terminal aus eine Sitzung im fernen System in derselben Art eröffnen wie eine lokale Sitzung und dann in derselben Weise im fernen System arbeiten, wie er es vom lokalen gewohnt ist. Die beteiligten Instanzen für die Abwicklung der Kommunikation dürfen nicht sichtbar werden.

Für den homogenen Verbund über ein LAN auf der Basis von Ethernet und Internet-Protokollen gibt es ein auf Sockets aufsetzendes Programmpaket, das "Networking without Programming" unterstützt. Für viele Endbenutzer reicht dieses Funktionsspektrum bereits aus, nicht aber für den Implementierer neuer Kommunikationsanwendungen.

Die Anforderungen des DDP an die Kommunikation bedeuten eine echte Anwendungs-Anwendungs-Kommunikation in Form einer Programmschnittstelle. Mit deren Hilfe werden Applikationen implementiert, die dann neue Funktionen für das "Networking without Programming" bieten. In diesem Zusammenhang sind gegenwärtig zwei Trends feststellbar.

Der eine setzt an niedrigsten möglichen Level an, der Transportschicht. Sie bietet die zuverlässige, duplikatfreie und anordnungstreue Übertragung von Nachrichten zwischen Benutzern in Endsystemen, die über Transitsysteme und Teilnetze verknüpft sind. Mit anderen Worten handelt es sich dabei um einen zuverlässigen Basisdienst. An dieser Stelle scheint aber noch das Netzwerk durch, da die Phasen Verbindungsaufbau, Datentransfer und Verbindungsabbau üblicherweise programmiert werden müssen. Wiederaufsetzpunkte und Transaktionskonzepte sind hier natürlich nicht verfügbar. Für die Portabilität höherer Kommunikationsanwendungen, wie Electronic Mail gemäß X.400, Filetransfer gemäß FTAM, Print-Services und andere Bürodienste, ist ein einheitlicher Transportservice die eine wichtige Basis. Die andere ist, daß sie überwiegend in Hochsprachen (C, Pascal) geschrieben werden, für die auf den meisten Unix-Rechnern Compiler existieren.

Der zweite Trend zur Herstellung einer Programmschnittstelle zur Anwendungs-Anwendungs-Kommunikation setzt am höchstmöglichen Level an, der Anwendungsschicht. Sie bietet den Benutzern ein Höchstmaß an Komfort für die Kommunikation. Bezogen auf Unix heißt das, daß die Benutzer mit den gewohnten Sprachmitteln Kommunikation betreiben beziehungsweise die Datenströme steuern, nämlich OPEN, READ, WRITE, CLOSE.

Normungsgremien treiben Portabilitätsidee voran

In beiden Richtungen laufen intensive Entwicklungsarbeiten. Diese werden insbesondere von X/Open vorangetrieben, einer Vereinigung von Unix-Herstellern, der auch AT&T angehört. X/Open hat sich das Ziel gesetzt, Standards auszuwählen, die die Portabilität des Systems und damit dessen Attraktivität fördern. Dort, wo noch keine ausreichend stabilen Basisstandards vorhanden sind, nämlich in den höheren Kommunikationsfunktionen, entwickelt X/Open Unix-adäquate Schnittstellen, die auf der internationalen Normierung aufsetzen.

Gegenwärtig wird bei X/Open das Review des Standards zum "X/Open Transport Interface" (XTI) vorbereitet, Arbeiten zur Entwicklung der "X/Open Program to Program Communication" (XPPC) unter Verwendung internationaler Standards aus den OSI-Aktivitäten sind inzwischen im Gange.

Der Verbund von Einzelkomponenten ist ein bewährtes Mittel zur Erhöhung der Rentabilität und Gesamtfunktionalität des Systems, in dem das Ganze mehr darstellt als die Summe seiner Teile. Mit Unix steht im DV-Markt eine attraktive Einzelkomponente zur Verfügung, die sich in isolierten Umgebungen und im homogenen Verbund bereits bewährt hat.

Die Hersteller von Unix-Systemen haben die Herausforderung angenommen, ihr System auch in den heterogenen Verbund einzugliedern und geeignete Weiterentwicklungen begonnen. Sie richten sich zunehmend an internationalen Aktivitäten im Rahmen der Kommunikation offener Systeme aus. Erste Erfolge zeichnen sich bereits ab. So wird die mittlerweile klassische Funktionalität von Unix um moderne Konzepte der Kommunikation ergänzt, womit das Betriebssystem weiterhin seine Konkurrenzfähigkeit beweisen kann.

*Norbert Richter ist Laborleiter im Geschäftsbereich Datentechnik, Systemtechnik, Datenfernverarbeitung, bei der Siemens AG, München.