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.

11.09.1992

Die Kommunikation mit IBM-Host-Systemen

11.09.1992

SNA wurde Ende der sechziger Jahre von der IBM entwickelt. Die damals noch in den Kinderschuhen steckende Datenfernverarbeitung verlangte mit steigender Komplexität und Rechnerleistung nach einem Konzept, das den Anforderungen der kommenden Entwicklungen auf diesem Sektor standhalten sowie möglichst Software- und Hardware-unabhängig sein sollte. Die Systems Network Architecture ist also nicht nur ein Protokoll, sondern auch ein ganz allgemeines Konzept, um die verschiedenen Rechner, Kommunikationsgeräte und Endgeräte mit unterschiedlichen Netzwerken zu verbinden. Sie ist eher als Empfehlung zu verstehen, wie sich ein Gerät im SNA-Netz zu verhalten hat.

Die SNA-Struktur ist allerdings hierarchisch geordnet. Ausgehend von einem zentralen Gerät, meist dem Host selbst, verläuft sie baumartig erst zu intelligenten Kommunikationsgeräten, den Communication Controllern oder auch FEPs (Front -End -Processors), die mit Hilfe eines eigenen Steuerprogramms in der Lage sind, ihre angeschlossenen Subnetze selbst zu verwalten.

Das NCP (Network Control Program) im Communication-Controller fungiert als oberster Knoten in seiner Subarea. Das nächste Element danach ist der Cluster-Controller. An ihn der bis auf ein Betriebssystem im Mikrocode keine eigene Intelligenz hat, sind wiederum die Endgeräte wie Terminals und Drucker angeschlossen.

Die einzelnen Elemente im Netz differieren also in ihrer Funktionalität und Leistungsfähigkeit. Sie werden durch eine spezielle Terminologie unterschieden. Der Begriff der Physical Unit (PU) wurde am Anfang der SNA-Geschichte geprägt. Inzwischen setzt sich langsam die Bezeichnung Node Type durch (siehe Abbildung 2).

Eine weitere Einteilung besteht innerhalb der einzelnen Geräte. Dort werden vorhandene Ressourcen als Logical Unit (LU) bezeichnet. Man unterscheidet folgende LU-Typen: (siehe Abbildung 3).

Die Anwendungen, also die Programme auf den Host-Systemen selbst, haben ebenfalls eine Art Schnittstelle. Diese Logical Unit wird Anwendungs-LU genannt. Wenn nun eine RS/6000 an ein Host-System angeschlossen wird, ist diese Physical Unit immer vom Typ 2 oder Typ 2.1(Peer Node). Das System verhält sich dem Host gegenüber wie eine Steuereinheit, an die Terminals oder Drucker angebunden sind. Mit einem Unterschied : Die Funktionen, die sonst das 3270-Terminal (LU2) und der 3270-Drucker (LU1 und LU3) übernommen haben, werden jetzt ebenfalls von der RS/6000 realisiert. Das System emuliert also 3270-Terminals und LU1/3 Drucker. Im Falle einer LU 6.2-Verbindung verhält sich die RS/6000 wie ein Peer-Node vom Typ 2.1.

Im Gegensatz zu einer Steuereinheit, die ihr Geschäft per Hardware und Mikrocode abwickelt, gibt es für die RS/6000 spezielle Software, die die Funktionen der PU2 und PU2.1 und die Funktionen der LU0, 1, 2, 3, 6.2 unterstützt. Die SNA-Services/6000 stellen die Funktionen der PU2(.1) und allen anderen verfügbaren LU-Typen zur Verfügung. Wenn die RS/6000 als 3270-Terminal oder 3270-Drucker fungieren soll, ist jeweils noch ein Zusatzprodukt erforderlich, das die eigentliche Anwendungsschicht (Application -Layer) darstellt. Dieser Bildschirm-Emulator (oder 3270-Druckeremulator) stellt die Verbindung zwischen der SNA-Logik und den Ausgabegeräten (Bildschirm und/oder Drucker) dar.

Neben der Verwendung eines Bildschirmemulators in der Applikationsebene ist auch der Einsatz eines RJE (Remote-Job Entry-)Dienstes möglich. Die RS/6000 dient dann als RJE-Station.

Über die LU0-Koppelung, einer Programm-zu-Programm-Verbindung, in der es im Gegensatz zu einer LU6.2-Verbindung (APPC) keine speziellen Verfahren oder Protokolle gibt, stehen nun einige Anwendungen zur Verfügung, die auch dem Netzwerk- Management dienen.

Verbindungen zu Netview auf dem Host sind mit Netview Servicepoint / 6000 möglich. Damit können Fehler auf` der RS/6000 gesammelt und zu Netview durchgereicht werden (Collecting). Außerdem dient das Produkt der Sammlung und Konvertierung von Fehlern in einem TCP/ IP-Netzwerk, in dem sich die RS/ 6000 befindet.

Die dort auftretenden SNMP-Traps (Simple Network Management Protocol) werden in Netview-Alerts umgewandelt und können dann im Netview weiterverarbeitet werden (siehe Abbildung 4).

Die Kontrolle einer RS/6000 vom Host aus gelingt mit dem Produkt HCF (Host Command Facility), mit dem es möglich ist, sich von 3270-Bildschirmen in die RS/6000 einzuloggen. Allerdings funktioniert das Verfahren nur im Line-Modus; immerhin können von der Kommandozeile alle AIX-Befehle eingegeben

werden. Host-unterstützte Softwareverteilung, die auch automatisch ablaufen kann, ist mit Netview/DM (Distribution Manager) möglich. Dabei kommuniziert Netview/DM auf dem Host mit einem Client auf der RS/6000.

Der Netview/DM-Catcher führt dann alle Befehle, die von Netview/DM kommen, als Hintergrundprozeß aus. Daten, Programme oder Betriebssystem-Teile können so aus der zentralen Netview/DM-Datenbank über einfache Befehle interaktiv oder mit Transmissionsplänen automatisch an alle angeschlossenen RlSC-Systeme verteilt werden .

In der Praxis trifft man gerade auch in großen komplexen Netzwerken auf Geräte, die entweder als reine SNA-Geräte die Bedingungen der SNA-Architektur erfüllen oder aber den hierarchielosen Eigenschaften des TCP/IP-Protokolls entsprechen. Wie ist es nun möglich, diese doch recht verschiedenen Netzwerke miteinander zu koppeln?

In der Tat ist die Aufgabe auch mit der RS/6000 nicht einfach zu lösen. Zumindest das Weiterreichen von

SNA-Diensten über das TCP/IP-Netz ist möglich (X-Window-Protokolle etc.). Eine wirkliche logische Koppelung mit Router-Fähigkeiten setzt eine komplexe Software auf der RS/6000 und eine TCP/IP-Implementierung auf dem Host voraus. Leider ist diese "offene" Lösung nicht ganz billig. Aber die angeführten Fähigkeiten mit den Kombinationen ergeben schon beachtliche Möglichkeiten zur Kommunikation der RS/6000 mit IBM-Host Systemen.

Stephan Daub ist Systemberater für RS/6000- und AS/400-Maschinen bei der Compunet Projekt

Management GmbH, Köln .