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.

CONNECTIVITY


14.08.1992 - 

Connectivity zu IBM: APPN verspricht besseres Routing

Trotz der marktführenden Position von IBM und langjährigen Etabliertheit von

SNA wird es zunehmend wichtiger, die vernetzte IBM-Systemwelt im

Gesamtzusammenhang eines heterogenen Unternehmensnetzwerkes zu

betrachten. Petra Borowka* beschreibt Connectivity- und Internetworking-Möglichkeiten, insbesondere hinsichtlich des Multiprotokoll Betriebes in

heterogenen Netzen, der TCP/lP-Kommunikation sowie der in den meisten

Fällen gewünschten PC-Host-Anbindung.

Connectivity: Ein Modewort im Trend

Es war schon immer so, daß jeder Trend sein eigenes Modewort her vorbrachte. Als Kunstwort des Wandel von homogenen zu heterogenen Netzwerkstrukturen - gern als Trend der 90er Jahre bezeichnet - hat sich der Begriff` "Connectivity" in aller DV-Munde eingebürgert. So schnell wie dieser Begriff im DV-Jargon auftauchte, so nahtlos ging er auch in unseren alltäglichen Sprachgebrauch über - ohne jedoch eindeutig definiert zu sein. Vergeblich sucht man jedenfalls in den meisten Lexika und Fachwörterbüchern nach diesem Terminus, findet höchstens einen Verweis, beispielsweise auf das Stichwort Vernetzung.

Im allgemeinen versehen wir alles, was der Verbindung oder Integration verschiedener DV Systeme dient, grobschlächtig mit dem Etikett Connectivity, egal, ob Software oder Hardware. Doch wie dem vagen Sprachgebrauch auch sei, der Zweck heiligt die Mittel: Sicher ist, daß als Ergebnis dieser neuen DV-Kultur die in den 80er Jahren so oft geforderte und erwünschte offenen DV-Welt herauskommen soll. Auf diese Welt bewegen wir uns zweifellos zu. Der Erfolg der " Connectivity-Spezialisten" wie Cisco oder Wellfleet, die binnen kürzester Zeit aus dem Nichts zu etablierten Marktgrößen avancierten, beweist den Bedarf der Anwender an solchen Brücken schlagenden Produkten.

Manchen wir uns aber auch nichts vor: Von der absolut offenen Welt sind wir noch ein gutes Stack entfernt. Der Datentransfer zwischen Token-Ring- und Ethernet-Netzen geht zum Beispiel wegen der unterschiedlichen Realisierung der Protokol Stacks noch längst nicht so reibungslos vonstatten, wie es eigentlich wünschenswert wäre (siehe nebenstehender Artikel: "Connectivity zu IBM APPN verspricht besseres Routing"). Zu oft erfordert die Connectivity zwischen verschiedenen Herstellerarchitekturen - ja sogar innerhalb dieser - noch softwaretechnische Balance- und Kraftakte zur Trimmung der Protokolle.

Tröstlich ist jedoch, daß die Zeiten selbstherrlicher Hersteller vorbei sind. Mittlerweile ist allen klar geworden: Mit proprietären Ansätzen ist beim Anwender kein Blumentopf mehr zu gewinnen. Bester Beweis dafür ist die jüngst bekanntgegebene APPN-Strategie von IBM, die damit nicht nur SNA-intern, sondern auch extern für mehr "Connectivity" sorgt. Hinzu kommt, daß Begriffe wie Ethernet, TCP/IP, XNS, Netware oder Decnet in der Philosophie Big Blues keine Tabuthemen mehr sind. Was für Big Blue gilt, sollte für alle gelten. Es lebe die " Connectivity" pg

Open Enterprise

Offenheit ist angesagt, auch bei der IBM, deren Open-Enterprise-Strategie so aussehen konnte: Die vereinheitlichte Systembasis greift über Standardnetze mit den Kommunitationsprotokollen SNA, TCP/IP und OSI auf unternehmensweite Daten und Applikationen zu.

Die Statistik ist eher dazu angetan, die LAN-Freaks der Internetworking-Gemeinde zu entmutigen: Immer noch ist über die Hälfte des installierten SNA-Equipments mit SDLC oder sogar noch Binary Synchronous Communication (BSC) und anderen LAN-fremden Zugriffs- modulen ausgerüstet. Wenn Anwender bei Host-Anbindung der PCs von Irma-Karten sprechen, ist häufig gar nicht die Irmalan-Workstation-Emulation über Token Ring gemeint, sondern die gute alte Koax-Karte.

Für den AS/400-Bereich gibt es überhaupt erst seit diesem Frühjahr eine Token-Ring-fähige Steuereinheit (IBM 5494), für die PC-Anbindung ist "PC/Support" von IBM fast das einzige Produkt zur Direktanbindung an den Token Ring. Alle anderen Emulationshersteller setzen ein Twinax- oder SDLC-Gateway (PC) vom LAN zur AS/400 ein. Über Koax oder Twinax vernetzte Geräte Ó la 3174, 3274, 8100, S/1, /3x und zu SNA kompatible Third-Party-Minis sind in einer Anzahl vorhanden, die nicht von heute auf morgen vom Markt wegzudiskutieren ist.

Der Trend weist eine steigende Vernetzung mit PCs in den Unternehmen, aber auch eine rückläufige Tendenz in der Nutzung von Terminals aus. Der vernetzte PC mit seinen Vorzüg- gen in der IDV und den Möglichkeiten verschiedener Host-Anbindungen (nicht nur zur IBM-Welt) setzt sich mehr und mehr durch. Zusammenfassend sind folgende wesentliche Entwicklungen zu berücksichtigen:

- 16-Mbit/s-Token-Ring mit zu nehmender Bedeutung,

- Übergang vom homogenen Netz zum heterogenen Netz mit Multiprotokoll -Anwendungen,

- erweiterte Anwendungs vielfalt im Token Ring,

- Fortsetzung und Ausdehnung der SNA-Linie durch IBM, - integrierte Anwendungen mit LU6.2 und SAA

- APPN als Peer-to-peer-Basis für die LU6.2 und

- Ausweitung der AIX-Strategie von IBM.

Neben der Öffnung für weitere Märkte (Ethernet, OSI, TCP/IP, Unix) wird die IBM in den Nächsten Jahren ihre SNA-Linie verstärken. Dazu zählt unter anderem eine Forcierung der Token-Ring-Technik durch leistungsfähigere Produkte (neue Controller, aktive Ringleitungsverteiler IBM 8230, neue Steuereinheiten 3172 Modell 1 und 2), neue Anschlußtechniken (FDDI), die Einbindung von Kommunikationstechnik in Integrierte Anwendungen (LU6.2, SAA, Lotus Notes) sowie die Einführung und Ausdehnung neuer Produkte (Netware von IBM, Netware für SAA, LAN Server, Archiv Server, OSF DCE, verteilte CD-Anwendungen). Über den Versuch der IBM, LU6.2 als Untermenge der höheren OSI-Protokolle standardisieren zu lassen, da es den OSI-Grundsätzen eher entspricht als die bis dato benutzten SNA-Protokolle, ist noch nicht entschieden.

Parallel dazu und beeinflußt von dieser Entwicklung änderte sich die traditionelle hierarchische SNA-Struktur gravierend. Die Koppelung von LAN-Inseln und deren Nutzung als Backbone für einen Rechnerverbund beraubte die SNA-Pyramide ihrer klassischen Form: streng hierarchische, Host-basierte WANs wandelten sich in einen unorthodoxen WAN-Verbund gleichrangiger LANs, in denen Gateways die Host-Verbindung herstellen.

Außenseiterprotokolle (aus Sicht von SNA) wie Netbios, Novell oder TCP/IP wurden leider nicht unterstützt, ganz zu schweigen von XNS oder gar Decnet. Die konsequente Weiterentwicklung in dieser Richtung ist die Konzentration verschiedener LANs über einen noch leistungsfähigeren Backbone, zum Beispiel FDDI. Die funktionale Weiterentwicklung von Brücken-Backbones ist der Einsatz von hybriden Routern, um die Vorteile von Routing in Multiprotokoll-Umgebungen nutzen zu können - mit dem entsprechend höheren Betriebsaufwand und Preisaufschlag.

Real betrachtet, sind protokoll-integrierte Router-Backbones für SNA und die heterogene Welt allerdings noch Zukunftsmusik, die meisten Router-Backbones basieren heute auf TCP/ IP) und laufen parallel zu SNA-Backbones. Wird SNA tatsächlich über einen Router-Backbone geleitet, so ist heute als Stand der Technik die Verbindung mehrerer Token-Ring-Netze über Brückentechnik mit Source Routing im lokalen Bereich zu sehen, im WAN-Backbone die SNA-Encapsulation mittels TCP/IP und TCP/IP-Routing.

Der Vorteil dieser Lösung besteht in der Nutzung eines gemeinsamen Backbones, der Nachteil in der aufwendigen und nicht OSI-gemäßen Protokolltechnik der Encapsulation in der ein Frame mit allen Kontrollinformationen in ein quasi umhüllendes weiteres Protokoll eingebettet wird.

Dies bedeutet zweifachen Protokoll Overhead bei Übertragung und Encapsulation beziehungsweise Decapsulation.

Da längst nicht alle Endgeräte und Hosts über LANs vernetzt sind, sondern immer noch eine große Installationsbasis mit SDLC und BSC existiert, ist eine vollständige Integration der SNA-Welt über Router heute nur möglich, wenn diese Protokolle vom Router direkt unterstützt werden, also den parallelen Protokoll-Stacks des Routers ein weiteres Protokoll hinzugefügt wird. Diesbezüglich lassen sich weitere Möglichkeiten zur SNA-Integration in unternehmensweite LANs nennen: SDLC-Transport mittels TCP/IP-Encapsulation (Synchronous Passthrough, Serial Tunneling) unter Umständen inklusive Remote Polling (Poll-Spoofing) oder mittels SDLC/DLC-Konversion wobei Stand der Technik Encapsulation ist - lediglich die Hersteller Cisco, Wellfleet und Proteon haben Konversionssoftware angekündigt.

Neu ist dabei nur die Einrichtung eines oder mehrerer SDLC-fähiger Ports im Router, so daß auch SNA-Pakete verarbeitet werden können, die nicht über eine traditionelle SDLC-Verbindung ankommen. Einen Kommunikationsrechner der Preisklasse 3745 mit Token-Ring-Interface auszustatten bedeutet immerhin einen Aufwand von gut 40 000 Mark.

Bei Poll-Spoofing oder auch Remote Polling (oder auch Local Polling, je nach Sichtweise des Herstellers) wird die Verschwendung von WAN-Kapazität durch das lästige Idle Polling umgangen. Ein sogenanntes Primarmodul, das im Downstream Router liegt, schickt Polls an die Endgeräte und emuliert eine SDLC Primary Link Station (37xx). Ein Sekundärmodul im Upstream Router beantwortet die Polls der wirklichen 37xx. Indem "oben" ein Dummy (im Router) auf die echten Polls antwortet und ,unten" ein Dummy (im Router) pseudoechte Polls schickt, ist das Polling auf dem Backbone ausgeblendet. Daten werden nur dann über das Backbone übertragen, wenn es sich um SDLC-lnformations-Frames oder BSC-Textblöcke handelt (siehe Abbildung 1).

APPN wird schon bald im Router realislert

Fazit: Unter Abwägung der technischen und wirtschaftlichen Vor- und Nachteile scheint es derzeit noch nicht angeraten zu sein, den Router mit zuviel SNA-lntelligenz (sprich PU4 oder PU5) auszustatten. Nach der neuerdings möglichen Lizenznahme von APPN kündigt sich hier eine fortschrittlichere Routing-Alternative an, nämlich die Realisierung von APPN im Router. Leider ist APPN derzeit nur für die allerwenigsten SNA-Anwendungen nutzbar. Der Trend zeigt jedoch eine Wandlung in Richtung dieses neuen Protokolls. Nüchtern betrachtet, sind Router noch nicht in der Lage, die beachtliche Anzahl von Remote-Leitungen zu konzentrieren, die ein Front-end in weitverzweigten SNA-Zentralen mit vielen Außenstellen handhabt. Ein Router kann hier lediglich zur Entlastung und sinnvollerweise auch zum Backup herangezogen werden. Bei geringerem Verzweigungsgrad ist jedoch ein Router-Einsatz als Alternative zum Front-end-Prozessor in Erwägung zu ziehen.

Zur Anbindung verschiedener LAN-Verfahren und heterogener Protokolle wie MAP und vor allem TCP/IP wird seit rund zwei Jahren der Interconnect Controller IBM 3172 vermarktet und stetig weiterentwickelt, obwohl dieses Gerät anfanglich nur eine verbesserte Ablösung der LAN Channel Box IBM 8232 (Ethernet-Anschluß des Host für TCP/IP) zu sein schien. Durch die neueren Ankündigungen im September 1991 präsentiert sich dieses Gerät als "Multiprotokoll-LAN-Steuereinheit" neben der rein SNA-bezogenen 3174, zumindest solange, bis die 3745 oder Nachfolgermodelle in der Lage sind, ihre Funktionalität zu integrieren.

Da keine Direktanbindung (lokal oder remote) von Terminals möglich ist, stellt die 3172 nur eine Konkurrenz zur 3174 dar, wenn diese als reines Token-Ring-Gateway zum Host eingesetzt wird. Da die Anbindung von SNA (ab ICP Version 2.0, III/91) noch nicht ohne Probleme läuft und auch noch nicht alle SNA-Features unterstützt (zum Beispiel Sicherheit, Systemkontrolle), ist nicht damit zu rechnen, daß die 3174 mittelfristig von der 3172 verdrängt wird. Vielmehr ist letztere eine Host-Zugangsmöglichkeit für vernetzte PCs, Unix-Systeme und Workstations oder auch AS/400 Systeme über verschiedene LANs wie Ethernet Token Ring, Token Bus (mit MAP) und FDDI.

Auf den höheren Kommunikationsebenen werden dann in der Regel MAP (in Fertigungsumgebungen) oder TCP/IP zum Zuge kommen. Weder die 3174 noch die 3745 unterstützen bis dato einen anderen LAN-Anschluß als Token Ring (für die 3745 ist Ethernet angekündigt, jedoch nur zusammen mit TCP/ IP); aus diesem Grund stellt die 3172 derzeit die einzige Möglichkeit der Anbindung anderer LANs an ein IBM-Großsystem dar, insbesondere für FDDI (siehe Abbildung 2).

Mit der Version 2.2 der 3172-Steuerungssoftware (ICP, Interconnect Controller Program), die Mitte 1992 verfügbar werden soll, lassen sich mit zwei IBM-3172-Steuereinheiten über bis zu vier 2-Mbit/s-Leitungen (E1/X.21) oder auch CTC Remote-Verbindungen zwischen (IBM-)Hosts schalten. Dies ist insbesondere im Zusammenhang mit Notfallösungen für denkbare Host-Ausfälle oder automatische Backup-Lösungen interessant. Damit gibt es für diese Verbindung eine weitere Alternative zum Kommunikationsrechner IBM 3745, die im übrigen auch durch Router derzeit so nicht geleistet werden kann, da Router mit einer Ausnahme (NSC) keinen Kanalanschluß haben.

Die theoretisch zwar längst überfällige, praktisch aber revolutionäre Ankündigung eines Ethernet-Adapters für die 3745 hat einerseits Auswirkungen auf den wachsenden TCP/IP-Markt, andererseits den Erhalt von SNA-Backbones im Multiprotokoll-Umfeld: Durch die TCP/IP-Routing-Fähigkeit, die eine 3745 zusammen mit dem Ethernet-Adapter erhält, kann sie eine Art TCP/IP-SNA-Protokollkonverter darstellen und TCP/ IP-Pakete über ein SNA-WAN-Backbone transportieren. Dies ist ein genau umgekehrter Ansatz im Vergleich zu Multiprotokoll-Routern: Statt SNA-Pakete in TCP/IP zu enkapsulieren und über ein Router-Backbone zu leiten, werden TCP/IP-Pakete in SNA enkapsuliert und über das (in vielen Fällen ja vorhandenen) SNA-Backbone mit übertragen. Reine SNA-Kommunikation kann der Ethernet-Adapter nicht verarbeiten (hier verläuft die Entwicklung gleichermaßen schleppend wie bei der 3172). Für SNA-Kommunikation mit einem Host ist nach wie vor das Token-Ring-LAN erforderlich, das trotz der eher unfreiwilligen Anerkennung und Unterstützung von Ethernet durch die IBM immer noch eine Vorzugsstellung innehat.

Die Annäherung zwischen Token Ring und Ethernet wurde durch die lokale Brücke IBM 8209 zwischen Ethernet- und Token-Ring-LANs (IBM 8209, zukünftig mit neuem Microcode für verbessertes Management) eingeleitet. Zunehmend ziehen in diesem Jahr andere Hersteller mit dieser Funktionalität als Brücken-, Router- oder Hub-Features nach (Cisco, Wellfleet, 3Com, Microsom). Zur Zeit läßt sich ein völlig problemloser Transfer zwischen Ethernet und Token Ring aufgrund der verschiedenen Realisierungen gleicher Protokoll-Stacks für Ethernet und Token Ring nicht immer realisieren (zum Beispiel Novell, 3Com, 3270-Emulationen). Eine Anpassung der verschiedenen Implementierungen ist jedoch durch das verstärkte Zusammenwachsen beziehungsweise die verstärkte Ausweitung von LAN-Verbundstrukturen schon teilweise erfolgt und in den nächsten Jahren verstärkt zu erwarten. Der Einsatz von Source Routing Transparent in Token-Ring-Netzen statt des reinen IBM Source Routing wird das Zusammenwachsen von CSMA/CD und Token Ring erleichtern.

Im Rahmen von Open Enterprise wird TCP/IP (theoretisch) als gleichwertiges Protokoll zu SNA und OSI betrachtet. Die Ankündigung des TCP/IP-fähigen Ethernet-Adapters für die 3745 ist in diese Entwicklung einzuordnen. Ein zweiter Schritt sind neue TCP/IP-Versionen von IBM:

- TCP/IP (2.0) für DOS mit NFS-Unterstützung und Zugriff auf NFS-Server sowie netzweite NFS-Dateisysteme; zusätzlich Unterstützung von MS-Windows 3.0,

- TCP/IP (1.2) für OS/2 mit X-Windows-Oberfläche und X.25-Unterstützung - auch die Firma ftp bietet übrigens inzwischen eine TCP/IP-Version für OS/2 an.

Zusammen mit der Verfügbarkeit des TCP/IP-Etherrlet-Adapters für die 3745 soll dann die Kommunikation zwischen TCP/IP-Systemen über ein SNA-WAN-Backbone möglich sein.

TCP/IP kümmert auf der AS/400 vor sich hin

Während TCP/IP auf der AS/400 noch mit einer kümmerlichen Funktionalität kämpft (Telnet-Client mit VT100 nur im Line-Modus, TN 5250 wäre für Full Screen erforderlich, ist aber in den meisten Anwendungen für PCs oder gar andere Systeme nicht implementiert), von NFS ganz zu schweigen, können MVS-Systeme immerhin Client- und Server-Funktionen für Telnet und FTP erhalten. Serverfunktion für NFS inklusive RPC-Unterstützung sowie X-Windows-Clients sind ebenfalls unter MVS und VM verfügbar. Die beste TCP/IP-Unterstützung ist naturgemäß bei IBM-AIX-Systemen zu finden, mit Ausnahme von AIX PS/2, das dem OS/2 hinsichtlich TCP/IP unbegreiflicherweise hinterherhinkt. So verfügt AIX/370 über mehr Features als MVS und AIX 3.0 (RS/6000) über mehr Features als der gesamte Rest der IBM-Systemwelt.

Im Rahmen der Open-Enterprise-Ankündigungen wird ersichtlich, daß IBM den neuen Weg einschlägt, die Existenz anderer System- und Kommunikationswelten als SNA auf der Basis von /370, /390, AS/400 öffentlich zur Kenntnis zu nehmen und integrative Ansätze ins Auge zu fassen. Als Eckpunkte einer Unternehmens-DV werden dabei gesehen:

- Client-Server-Konzepte (zum Beispiel OSF/DCE, CPI-CI), wobei auch ein Großsystem in der Rolle des potentiellen Servers vorgesehen ist,

- technisch-wissenschaftlicher Bereich (traditionelle Ethernet-Domäne),

- Networking (global),

- Unternehmenssicherheit,

- Transaktionsverarbeitung (die Sicherung der Host-Existenz),

- Anwendungsentwicklung und

- Systems Management, das das Netzwerk-Management gleich beinhaltet.

PS/2, RS/6000, AS/400 und S/390 (9370 und /370 werden schon nicht mehr genannt) werden mittels SAA von unten nach oben in eine durchgängige Linie gebracht. Die so vereinheitlichte Systembasis greift über beliebige Standardnetze auf unternehmensweite Daten zu, die in technisch-wissenschaftlichen oder transaktionsorientierten Anwendungen, in Client-Server-Applikationen oder der Anwendungsentwicklung vearbeitet werden.

TCP/IP wird neben SNA und OSI als gleichwertiges Kommunikationsprotokoll anerkannt, AIX gehört zwar noch nicht direkt zu SAA, kann aber als Seitenpfad von SAA betrachtet werden, wobei sich die Distanz zu SAA schrittweise verringert. Alle Daten und Systeme sind, einem "Information Warehouse" vergleichbar, in beliebigen Umgebungen verfügbar und verarbeitbar, falls der Zugriff erlaubt ist Verglichen mit der Realität, kann dieses durchgängige Konzept nur als Vision eingeordnet werden - aber Visionen sind bekanntlich erforderlich, um umwälzende Entwicklungen einzuleiten (siehe Aufmachergrafik) Um von den Visionen zum Alltag zurückzukommen: Die PC-Host-Kommunikation wird zur Zeit funktional durch die Terminal-Emulation dominiert, erweitert um Filetransfer zwischen PC und Host. Im Rahmen dieser traditionellen Linie ist die Anpassung der Emulationseigenschaften (emulierte Terminal-Typen) an das jeweilige Leistungsvermögen der PCs (CPU, Grafikadapter) klar erkennbar. Die SAA/PM-Linie und NAS/Decwindows (X.11) ebenso wie die Microsoft-Windows-Linie definieren eindeutige Standards für Benutzeroberflächen, die den Einsatz von Farbe und zunehmend hochauflösender Grafik voraussetzen. Emulationen, die zumindest optional einen Grafikstandard nicht unterstützen, sollten nur bei anderen funktionalen Vorzügen in die Auswahl einbezogen werden.

Neben der Terminal-Emulation gewinnt der PC ebenso wie die Workstation als intelligente Endpunkte verteilter Anwendungen an Bedeutung. Eine aussagekräftige Perspektive liefert die Entscheidung der OSF für einen Ansatz zur verteilten Verarbeitung über RPC und verteilte Betriebssystem-Funktionen (OSF/1)CE). Die technische Basis wird durch Interprogramm-Kommunikationsschnittstellen wie LU6.2 oder DCE geliefert.

PC-Host-Anbindungen werden zukünftig überwiegend auf der Basis von Standard- IEEE-Netzen (Ethernet, Token Ring) und nicht mehr auf der Basis von Spezialkarten (Koax, SDLC, Twinax oder ähnlichem) realisiert. Für den PC geht diese Entwicklung einher mit einer zunehmend breiteren Produktpalette für Controller-Karten und Netzwerksoftware.

Zusammenfassend müssen folgende Entwicklungen berücksichtigt werden:

- verstärkte Anbindung über Standard-LANs, - Dateizugriff, - Terminal-Emulation mit Grafik und Farbe (GUI),

- Interprogramm-Kommunikation in verteilten Systemen (LU6.2/RPC, DCE) und

- Schnittstelleneinheitlichkeit nach SAA.

Die Host-Abindung in der 3270-Welt erfolgt über Steuereinheiten oder Front-end-Pro-

zessoren, die mit dem Feature "Token Ring Gateway" ausgerüstet sind, das die LAN-Protokollstrukturen (DLC) in kompatible SNA-Datenströme umwandelt. Insbesondere Netbios-basierte Emulationen müssen uber ein weiteres Gateway erst einmal auf das DLC-Protokoll umgesetzt werden, denn nur dieses wird von den IBM-Produkten 3174 und 37xx verstanden. Den Anfang der Gateway-Entwicklung in der Geschichte der PCHost-Koppelung über LAN schreiben die sogenannten Passthrough- und Controller-Gateways: SNA legt fest, daß je SNA Boundary Node exakt eine einzige Physical Unit (PU2) existiert. Beim Einsatz von Gateways handelt es sich jedoch mindestens um zwei LAN-Komponenten, die an der Kommunikation beteiligt sind - wo aber ist die PU-Funktionalität der beiden implementiert? Die zwei gängigsten Ansätze sind: Implementation entweder im Anwender-PC oder im Gateway.

Wird die PU im Anwender-PC implementiert, so leitet das Token-Ring-SNA-Gateway den Datenstrom transparent zwischen beiden Welten hin und her, wie der Name Passthrough-Gateway schon sagt.Jeder PC ist eine DSPU (Down Stream Physical Unit), die zum Beispiel in einer 3174 als Passthrough-Gateway 1:1 übernommen wird. Diese Anbindung kann als eine Art Direktanbindung an den Host bezeichnet werden - entsprechende Emulationen heißen in diesem Sinne oft Stand-alone-Workstation-Emulation oder ähnlich. Das einzig mögliche LLC-Protokoll ist in diesem Fall DLC, da nur dieses von Passthrough-Gateways (3174/L 3174/R, 3745, AS/400, OS/2) verstanden wird.

Beim Einsatz einer 3174L muß jede PU für einen DSPU-Client als separate Subchannel-Adresse konfiguriert werden dies bedeutet aber, daß mit 255 PCs ein Host-Kanal vollständig belegt ist. Wird statt dessen ein Front-end Prozessor eingesetzt, belegen alle DSPUs zusammen nur eine Subchannel-Adresse im Host. Dafür ist der Kostenaufwand eines Front-end Prozessor-Gateways auch erheblich höher. Beim Einsatz von Passthrough-Gateways hat der Host nicht wenig Arbeit: Zu jedem einzelnen PC wird eine SSCP-PU Session aufrechterhalten Entsprechende Emulations-Produkte, die eine PU2 Anbindung des PCs realisieren, sind zum Beispiel von Attachmate, DCA Irma, Novell, Rumba etc. erhältlich. Die meisten Produkte liefern jedoch nur eine DOS- oder Windows basierte Emulation; 3270-Emulationen für OS/2 sind offensichtlich noch nicht einträglich genug.

Um mehrere PCs auch ohne Front-end-Prozessor in einer PU zu konzentrieren, kann die zweite Gateway-Alternative, ein Controller-Gateway, eingesetzt werden. Der Anwender-PC erhält in diesem Falle gar keine PU (diese kann Ja nur entweder im Gateway oder im PC residieren), sondern nur eine LU. Dies bedeutet, daß alle Funktionen um die SNA Path Control jetzt im Gateway ausgeführt werden; die SNA-Welt endet sozusagen im Gateway, das die PC-Anbindung seinerseits in Analogie zur Namensgebung vollständig kontrolliert. Vom Gateway zum PC fließt kein SNA Datenstrom mehr, sondern nur noch ein LAN-Datenstrom, was die angenehme Eigenschaft hat, daß auch andere Protokolle als DLC unterstützt werden, zum Beispiel Netbios, IPX, zur Not auch TCP etc. Das Gateway setzt die "PC-Protokolle" auf SNA um.

Ein Controller-Gateway kann LAN-vernetzte PCs über Koax, SDLC, X.25 oder auch LAN an die SNA-Welt anbinden. Im letzteren Fall wird es als DSPU zusammen mit einem Passthrough-Gateway eingesetzt, wobei das Controller-Gateway das vom PC benutzte Protokoll auf DLC umsetzt, das Passthrough-Gateway die Umsetzung von Token Ring nach SNA vervollständigt, aber die PU wiederum nur durchreicht. In diesem Fall ist also eine Art Doppel-Gateway-Konfiguration erforderlich.

Controller-Gateway entlasten den Host im Vergleich zu einer reinen Passthrough-Gateway-Lösung: Für alle angebundenen PCs ist nur eine einzige SSCPPU-Session zwischen Controller Gateway und Host erforderlich. Nachteilig bei Controller-Gateways ist, daß sie in der Regel völlig herstellerspezifisch arbeiten, das heißt ein Netware-Gateway kann nur Netware-Emulationen unterstützen, ein DCA-Irmalan-Gateway nur Irma-Emulationen etc. Wünschenswert wäre dagegen eine einheitliche LU- und Gateway-Implementierung mit der Möglichkeit zum Austausch und parallelen Einsatz verschiedener Produkte. ControllerGateways sind alle Emulations-Gateway-Produkte von Drittherstellern, zum Beispiel Extral Gateway Option, Exygate, Eicon, Irmalan EP, Irmalan SNA Gateway, NCPe Gateway, Netware SNA Gateway etc.

PC-Anindung erfolgt nur über Twtnax oder SDLC

Im Rahmen der PC-AS/400-Anbindung findet sich ein ähnliches Dilemma: Die meisten Hersteller von 5250-Emulationen bieten Produkte mit Twinax- oder SDLC-Karten an. Anbindung über LAN erfolgt nur durch den Einsatz von Twinax oder SDLC-Gateways, die dann jeweils mehrere vernetzte PCs bedienen. Eine Direktanbindung des PC an die AS/400 ist nur über PC Support von IBM möglich.

Im Zusammenhang mit den oben beschriebenen PC Host-Anbindungsmöglichkeiten einerseits und dem wachsenden Trend zum Einsatz heterogener Protokolle andererseits (insbesondere TCP/IP) fällt das Produkt "Rumba" innerhalb der Emulationswelt besonders auf. Hier wird sowohl eine 3270-Emulation als auch eine 5250-Emulation (die auf PC-Support aufsetzt und auch von IBM mitvertrieben wird), direkt über Token Ring und auf der Basis von Windows 3.0 angeboten Darüber hinaus läuft Rumba auch auf OS/2 EE, Version 1.3 oder OS/2, Version 2.0, mit den Extended Services als Voraussetzung. Der Hersteller hat Rumba von Anfang an als GUI-Produkt (Windows oder PM) konzipiert - konsequenterweise gibt es daher keine DOS-Applikation (ohne Windows). Um die Emulation unter Windows beim Wechsel in eine andere Applikation nicht abzuhängen, wird ein TSR-Modul (Terminate and Stay resident) mitgeladen, das die Emulation für einen späteren Wechsel zurück ins Emulationsfenster aktiv hält.

Die Nutzung von IPX als Basisprotokoll bis hin zum LAN-Gateway ist insbesondere dann interessant, wenn es sich um große Installationen handelt, in denen es sich lohnt, IPX-Routing einzusetzen. Ist der PC über Ethernet angebunden, so kann die Emulation mit DLC-Treiber über eine IBM- 8209-LAN-Brücke an die IBM 3174/37xx angebunden werden. Das bedeutet, daß ein PC, der an Decnet angeschlossen wird (und diese nicht über Token-Ring realisieren kann), auf den IBM Host-Zugriff nicht verzichten muß.

Wer so fortschritlich ist und TCP/IP auf seinem IBM-Host fährt, kann im PC TCP/IP laden (von ftp, Novell, Wollongong) und die Rumba-Emulation über das TCP/IP-Protokoll an den Host bringen, was derzeit noch eine 3172-Steuereinheit erfordert. Somit wird im PC ein paralleles Protokoll eingespart (Netbios oder DLC).

Die Host Anibindung aus anderen Protokollwelten

Da in einer Reihe von Fällen in denen eine zweite Host-Welt an SNA angebunden werden soll, die über TCP/IP erhältlichen Funktionen nicht ausreichen, wird zur Verbindung dieser zwei Welten nach wie vor ein Gateway eingesetzt, das zwar nur exakt diese zwei Protokolle ineinander umsetzt, jedoch mit einer relativ umfangreichen Funktionalität hinsichtlich emuliertem Terminaltyp, Anzahl paralleler Sessions, Programm-Programm-Kommunikation etc. So sind von HP Gateways zwischen HP NS und SNA erhältlich, von Digital Interlink und SEL Gateways zwischen Decnet und SNA, von Siemens Gateways zwischen Transdata und SNA. Von IBM werden in der Regel keine Gateways zu anderen herstellerspezifischen Protokollen angeboten, das heißt wenn ein Hersteller die Verbindung zur SNA-Welt sucht, ist er auf eigene Entwicklungen (oder solche von Fremdherstellern) angewiesen.

Eine weitere Möglichkeit ist, die Integration der heterogenen Welt (Digital, Hewlett-Packard, Prime, Sun, Tandem etc.) mit TCP/IP zu fahren und dann ein TCP/IP-SNA-Gateways zu installieren, das diese übriggebliebene Welt auch noch integriert. Solche Gateways sind zum Beispiel von Interlink oder Servocomp (Mitek Openconnect) erhältlich.

Fazit: Gateway-Lösungen als Host-Host-Verbindung werden um so fraglicher, je mehr verschiedene Herstellerprotokolle in ein integriertes Unternehmensnetz einzubinden sind. Bei steigender Anzahl der Protokolle nimmt die Anzahl der Gateways quadratisch zu, soll jedes Protokoll in jedes andere umgesetzt werden (N x (N-1)/2 bei N Protokollen). Gateway-Einsatz kann im wesentlichen nur zur Verbindung zweier Herstellerprotokolle empfohlen werden.