Von Chris Hopper*

AS/400-Netzwerke, die anfangs ausschliesslich SNA als Protokoll kannten, muessen heute aufgrund von Client-Server-Computing mit einer Vielzahl von Netzprotokollen umgehen, was dem Administrator einige Schwierigkeiten bereitet. Gemischte Systemumgebungen mit SNA, TCP/IP und Protokolle wie IPX/SPX oder Netbeui sind ueberall vorhanden.

PCs geraten jedoch an ihre Grenzen, wenn all diese Protokolle von einer Windows-Workstation gleichzeitig geladen werden sollen. Systemstabilitaet, Speicherplatz und Systemleistung stellen hierbei die groessten Probleme dar. Netz-Manager suchen daher nach neuen Wegen, zum Beispiel TCP/IP, um die Struktur des Netzwerks zu vereinfachen, ohne jedoch die Funktionalitaet einzuschraenken.

Warum ist, was einst so einfach war, naemlich eine Verbindung zwischen dem PC und der AS/400 zu schaffen, auf einmal so komplex geworden? Um dies zu verstehen, sollten wir einen kurzen Blick in die Vergangenheit werfen. Schon seit ihrer Einfuehrung ist die AS/400 die Wiege neuer Moeglichkeiten im SNA-Netzwerk. Einige dieser neuen Merkmale gingen erst Jahre spaeter in MVS-Mainframes und VTAM ueber. SNA LU6.2 Advanced Program-to-program Communication (APPC) und PU2.1 Advanced Peer-to-peer Networking (APPN) waren zwei dieser wichtigen Neuerungen, die auf der AS/400 - Jahre vor ihrer Einfuehrung auf den Mainframes - debuetierten.

AS/400: Router loest das Kommunikationsproblem

IBM bediente sich der maechtigen Program-to-program-Kommunikation von APPC durch die Entwicklung einer Reihe von Client-Server- Anwendungen, um PCs und die AS/400 miteinander zu verbinden. Diese Anwendungen ermoeglichten drei wichtige Funktionen auf dem PC: 5250-Terminal-Emulation, IBM-Drukkeremulation und File-Transfer- Dienste.

Die Verwendung von APPC hatte jedoch ihren Preis. IBM muesste feststellen, dass die Zahl der PCs, die mit der AS/400 kommunizieren konnten, stark von der Anzahl offener APPC-Sessions abhaengig war. Die meisten Anwender benoetigen wenigstens eine Terminal-Session, eine Drucker-Session sowie Dateienzugriff. Diese Notwendigkeit erfordert jedoch drei oder mehr APPC-Verbindungen, die eine erhebliche Belastung der AS/400-Netzwerke und Speicherressourcen darstellen.

Um diese beiden Probleme zu loesen, entwickelte IBM eine neue PC- Software-Komponente, den Router. Diese Software residiert auf dem PC und der AS/400 und reduziert die Anzahl der APPC-Verbindungen auf nur eine je PC, unabhaengig von der Anzahl der Anwendungen, die auf AS/400-Ressourcen zugreifen.

LAN-Interface fuer mehrere Protokolle gefordert

Ein AS/400-Router ist somit ein Session-Multiplexer. Beim Start wird der Router in den Speicher des PCs geladen und oeffnet eine reale APPC-Verbindung zur AS/400. Anwendungen, die nun mit der AS/400 kommunizieren wollen, werden als virtuelle APPC-Verbindung auf der realen Connection aufgesetzt. Auf der AS/400 demultiplext der Router die virtuellen APPC-Sessions und verteilt diese an die jeweils zustaendigen AS/400-Subsysteme.

Der Router wurde in IBMs PC Support for DOS vorgestellt. Der "PC Support Router" war ein Terminate-and-Stay-Resident(TSR)- Programm. Dies ermoeglichte dem Router, jederzeit im Speicher verfuegbar zu sein, um Terminal- und Druckeremulationen auszufuehren. Obwohl funktional, hatte der Router jedoch den Nachteil eines TSR, naemlich den Verbrauch wertvollen DOS-Speichers innerhalb der 640-KB-Grenze.

Der PC Support Router und seine Anwendungen bieten zwar eine gute Loesung fuer das PC-AS/400-Kommunikationsproblem, jedoch nicht die gesamte Netzfunktionalitaet, die Anwender benoetigen. In den meisten Unternehmen werden daher Netzwerk-Betriebssysteme wie Netware oder Vines fuer PC-File-Sharing, Drucken und E-Mail eingesetzt. Vielerorts wird noch ein drittes Protokoll wie TCP/IP fuer die Kommunikation mit Unix-Systemen benoetigt. Jedes zusaetzliche Netzprotokoll verlangt die Installation der ihm eigenen Softwarekomponenten auf dem PC. Zu Beginn benoetigte man hierzu mehrfache LAN-Hardware-Schnittstellen, Treiber, Protokoll-Stacks und Anwendungen.

Die Duplizierung der LAN-Hardware, die oft mit demselben LAN- Segment verbunden war, machte die Verbindung aller PCs mit dem LAN aus Kostengruenden oft nicht moeglich. Einige Anwender loesten das Problem durch verschiedene Boot-Konfigurationen, was natuerlich immer den Neustart des PCs erforderlich machte, wollte man seine Verbindungen aendern. Die Anforderung war also ein einziges LAN- Interface, das sich von mehreren Protokollen gleichzeitig nutzen liess.

SNA-Verlagerung vom PC auf das Gateway

Mehrere Netzwerkhersteller entwickelten hierzu unterschiedliche Softwaretechnologien; die bekanntesten sind hier Microsofts NDIS und Novells ODI-Spezifikationen. Nun war es moeglich, dass der PC Support Router, ein Netz-Betriebssystem-Protokoll und TCP/IP das gleiche LAN-Interface nutzten. Hiermit schienen alle PC- Netzwerkprobleme geloest. Oder doch nicht?

Wie sich herausstellte, war letzteres der Fall. Die Einfuehrung eines Protokollarbitrators kreierte neue Probleme. Manche Protokolle sind hochgradig zeitsensitiv, und die Zeitspanne, die der Arbitrator benoetigt, um die Datenpakete zu untersuchen, fuehrte in vielen Faellen zum Verbindungsverlust in staerker belasteten Netzen. Das machte es notwendig, dass manche Protokolle Zugriff auf die Datenpakete erhielten, noch bevor der Arbitrator diese untersucht hatte. Es erfordert viel Know-how, um zu erkennen, welches Protokoll den Zugriff sofort benoetigt, und um den Arbitrator sowie die Protokoll-Stacks richtig zu installieren. Viele Administratoren haben unzaehlige Stunden damit verbracht SNA, IPX/SPX, Netbeui und TCP/IP in Harmonie ueber das gleiche LAN- Interface auszufuehren. Obgleich diese Koexistenz machbar ist, geht sie doch haeufig zu Lasten der Systemzuverlaessigkeit.

Die Einfuehrung eines Protokollarbitrators war zwar hilfreich, um die Problematik der mehrfachen LAN-Schnittstellen zu loesen, das Hauptspeicherproblem existierte allerdings nach wie vor. Dagegen helfen jedoch zweierlei Techniken:

- Die Umwandlung des Protokoll-Stacks vom Basisspeicher TSR zum Windows-DLL, das im oberen, von Windows verwalteten Speicherbereich ausgefuehrt wird.

- Die Reduzierung der Anzahl von Protokoll-Stacks. Diese Techniken schliessen sich nicht gegenseitig aus. Im Gegenteil, je mehr man beide Moeglichkeiten ausreizt, desto einfacher wird die Netzkonfiguration und erhoeht sich die Systemstabilitaet.

Der IBM-PC-Support-Router war moeglicherweise das groesste TSR und somit das wohl wichtigste zur Umwandlung in ein Windows-DLL. Netsoft, ein unabhaengiger Software-Entwickler, war eines der ersten Unternehmen, das diesen Bedarf erkannte, und entwickelte den "NS/Router". NS/Router ist ein funktionaler Ersatz fuer den PC Support Router, er ist vollstaendig kompatibel mit dem Software- Interface von PC Support und kann diesen daher voellig transparent ersetzen. IBM folgte Netsoft mit einem DLL-basierenden Router mit der Vorstellung von "Client Access/400". CA/400 wurde gleichzeitig mit OS/400, Version 3, Release 1, vorgestellt und benoetigt diese Version. NS/Router arbeitet mit jeder Version ab Version 2, Release 2.

Die Umwandlung von TSRs in Windows-DLLs ist eine Technik, die zweite ist die Reduzierung der Anzahl der Protokoll-Stacks auf dem PC. Gateway-Hersteller erkannten sehr bald, dass sie ihren Produkten zu mehr Wert verhelfen, wenn sie das Speicherproblem loesen. Die wichtigsten sind hierbei der Microsoft-SNA-Server und Novells-Netware-SAA-Gateway. Das Hauptziel liegt hierbei in der Verlagerung von SNA vom PC auf das Gateway.

Netsoft hat in Partnerschaft mit Microsoft und Novell eine entsprechende Loesung fuer deren Gateways entwickelt. Der Net- softNS/Router benutzt nicht weiter SNA, um mit der AS/400 zu kommunizieren, sondern das IPS/SPX-Protokoll - das ja ohnehin schon auf den PCs vorhanden ist -, um mit dem Netware-SAA-Gateway zu kommunizieren.

TCP/IP verbindet die AS/400 mit dem Desktop

Das Gateway wiederum verwendet SNA fuer seine Verbindung zur AS/400. Hierdurch liess sich ein Protokoll vom PC entfernen, ohne dass die Funktionalitaet eingeschraenkt wurde. Wie bereits vorher erwaehnt, bietet der Microsoft-SNA-Server aehnliche Moeglichkeiten.

Im Bestreben, die Anzahl der Protokolle auf dem PC zu verringern, versucht man nun, TCP/IP zum De-facto-Standard als Transportprotokoll fuer alle Netzwerkdienste zu machen. Das Erreichen dieses Ziels wuerde die Anzahl der Protokolle auf ein einziges reduzieren, die Konfiguration von PC-Netzwerken drastisch vereinfachen und die Systemstabilitaet erhoehen.

Der Einsatz von TCP/IP als Transportprotokoll fuer traditionell Nicht-TCP/IP-Netzwerkdienste ist eine weitere neue Entwicklung in der Verbindung von PCs zur AS/400. Es gibt zwei Wege, dies zu verwirklichen: die Verwendung des Netsoft-NS/Router und von TCP/IP, um mit einem proprietaeren Gateway zu kommunizieren, oder die Verwendung von TCP/IP mit Einbindung von APPC ueber "IBM Anynet". Die Gateway-Version ist ueber Microsoft und Novell erhaeltlich. Beide Anbieter gestalten den Transport ihrer proprietaeren Protokolle ueber TCP/IP. Der NS/Router wurde erweitert, um diese Moeglichkeit zu nutzen. Fuer die Emulationsanwendung und, noch wichtiger, den Benutzer aendert sich nichts. Der NS/Router bietet weiterhin die gleichen Schnittstellen zur Bildschirm- und Druckeremulation. Anstatt eines proprietaeren Transportprotokolls wird jetzt ein offenes System, TCP/IP, verwendet. Vom Gateway zur AS/400 laeuft die Verbindung weiterhin ueber SNA. Diese Version hat den Vorteil, dass sie sich mit jeder Ausfuehrung von OS/400 einsetzen laesst.

IBM Client Access/400 verbindet den Router ohne Gateway mit der AS/400. Mit IBMs Anynet fuer Windows oeffnet der CA/400-Router eine TCP/IP-basierende Verbindung direkt zur AS/400 und uebertraegt gemultiplexte APPC-Sessions ueber diese Verbindung. Anynet ist auf der AS/400 erst seit OS/400-Version 3, Release 1, erhaeltlich, so dass die genannte Verbindungsart den Upgrade auf diese Version noetig macht.

"Aber", so sagen Sie jetzt vielleicht, "ich habe gehoert, dass ich mit TN5250 meinen PC ueber TCP/IP ohne SNA oder AS/400-Router mit der AS/400 verbinden kann. Stimmt das etwa nicht?" Doch, das ist richtig. PCs koennen direkte Verbindungen zu AS/400-Anwendungen herstellen, ohne SNA oder irgendeine Art von Gateway. Alles, was man benoetigt, sind TCP/IP und TN5250 auf dem PC sowie TCP/ IP auf der AS/400.

Keine Spezifikation fuer Native-SNA-Druckerdaten

Aber Vorsicht: Nicht alle Verbindungen sind gleich. Obschon es eine Spezifikation gibt, die beschreibt, wie man 5250- Terminaldaten ueber TCP/IP versendet - dem Request for Comment RFC 1205 -, gibt es keine solche Spezifikation fuer die Uebertragung von Native-SNA-Druckerdaten, selektiven Datentransfer per SQL Select Statement oder die Verwendung der Shared-Folder-Funktion. Zumindest im Moment bleiben diese erweiterten Funktionen eine Domaene der direkten PC-AS/400-Verbindung ueber SNA, Gateways wie MS-SNA-Server oder Novell-SAA-Gateway beziehungsweise Client Access/400 und Anynet.

*Chris Hopper ist Produkt-Manager fuer IBM Connectivity Applications bei Netmanage Inc.