Waehrend zum einen die asynchrone Welt vorwiegend auf Grundlage von Ethernet-LANs vernetzt ist, findet die Kommunikation im IBM- Umfeld weitgehend innerhalb von SNA statt, wo mit Hilfe geeigneter Kontroller auch Token-Ring-LANs einbettet sind. Daraus ergibt sich zwangslaeufig eine mehrfache Inhouse-Verkabelung. Konsequenz dieser Dualitaet: Eine Redundanz an Equipment wie Druckern und Bildschirmen sowie eine transparente Verfuegbarkeit der Host-Daten von den Unix-Rechnern und -PCs ist aufgrund der stark unterschiedlichen Struktur beider Welten nicht gegeben.
Trotz der sprunghaften Entwicklung auf dem Workstation-Markt stehen der Abloesung alter IBM-Mainframes durch Unix-Systeme jedoch noch einige entscheidende Gruende entgegen:
- viele anwenderspezifische Programme, die bereits unter VM oder MVS vorhanden und nur mit groessten Aufwand portierbar sind;
- Datenbestaende, die in Form von Db2 und VSAM-Strukturen vorliegen;
- roboterisierte Backup-Moeglichkeiten mit dem nicht konvertierbaren Inventar unzaehliger Backup-Baender und -Cartridges sowie
- die bestehende Programminfrastruktur auf Grundlage transaktionsorientierter Dienstleistungen wie CICS.
Oekonomisch ist eine gemeinsame, transparente und intelligente Nutzung aller Ressourcen sowie heterogener Rechnersysteme gefordert. Dies betrifft die Hosts selbst, aber auch die Verkabelung, die angeschlossene Peripherie und die jeweils spezifischen Rechnerleistungen sowie die verfuegbaren Datenbestaende. Dabei sind redundante Komponenten aus Kostengruenden zu eliminieren.
Da die Vorteile moderner Workstations hinsichtlich Grafik sowie des Preis-Performance-Verhaeltnisses unbestritten sind, gilt es, unter Beibehaltung des /370-Mainframes beide Welten so weit wie moeglich funktional miteinander zu verschmelzen. Dieser Prozess - im Englischen mit dem Schlagwort "Smartsizing" bezeichnet - ist die entscheidende Aufgabenstellung im Zusammenhang mit einer dezentralisierten Nutzung von Grossrechner-Ressourcen.
Um dieses Ziel zu erreichen, werden heute im wesentlichen drei Wege beschritten. Dies sind zum einen die sogenannten "SNA-faehigen" Endgeraete wie PCS mit 3270-Karten fuer DOS und OS/2-Rechner mit entsprechender Software. Mit diesem Equipment koennen Sitzungen auf dem IBM-Host und ein eingeschraenkter Filetransfer ueber das Indfile-Protokoll realisiert werden.
Eine zweite Moeglichkeit besteht in der Umsetzung des SNA- Protokolls in andere Protokolle. Bekannte Erzeugnisse dieser Kategorie sind beispielsweise das DEC-SNA-Gateway, das SNA-Gateway von Novell sowie eine Reihe verschiedener SNA-Gateways auf TCP/IP- Basis. Ausschlaggebend ist dabei, dass diese Gateways oft auf dedizierten Rechnern implementiert sind mit dem Ergebnis, dass sie sich von der IBM-Seite her gesehen haeufig als Physical Unit (PUdarstellen, ueber die mehrere Logical Units (LUs) betrieben werden koennen. Von einem TCP/IP-LAN aus erscheint das Gateway dann wie ein IP-Knoten.
Als dritte Loesungsvariante kommt ein auf dem Host implementiertes Netzprotokoll in Betracht, beispielsweise TCP/IP unter MVS. Die Netzsoftware hat dabei ueber den IBM-Block-Multiplexerkanal Zugriff auf einen dedizierten LAN-Controller, der den Host mit dem Netz verbindet.
Strukturell ist die erste Loesung eine Fortsetzung des im Rahmen von SNA bekannten Master-Slave-Konzeptes. Das heisst, die SNA-Welt wird auf die PCs oder Workstations im LAN transferiert. Hierdurch sind die meisten SNA- oder VTAM-Kommunikationsmoeglichkeiten wie Bildschirmzugriff und APPC LU6.2 gegeben, jedoch keine Funktion im Sinne der gebraeuchlichen LAN-Protokolle.
Kriterien fuer die TCP/IP-Implementierung
Die Loesung mit Gateways ist, bezogen auf das OSI-Referenzmodell, eine Umsetzung auf der Applikationsebene. Im Klartext: Die Anbindung des IBM-(kompatiblen)-Mainframes an die anderen Rechnern im Netz, etwa in Form eines VAX-Clusters, wird durch die Gateway- Software vorgenommen mit dem Nebeneffekt, dass der Client-Server- Betrieb emuliert wird.
Implementiert man, wie in der dritten Loesungsvariante dargestellt, das Netzprotokoll auf dem Host, so wird das Betriebssystem VM beziehungsweise MVS selbst netzfaehig. Dominierend bei diesem Unterfangen ist TCP/IP, sowohl was die PCs, MACs, VAXen und Unix-Workstations als auch was den
/370-Rechner selbst betrifft.
Es gibt aber auch noch eine vierte, "radikale" Loesung: Das Host- Betriebssystem wird von VM/MVS auf Unix unter der
/370-Architektur umgestellt. Die Stichworte hierzu lauten UTS, das auf Amdahl-Rechnern verbreitet ist, sowie UXP/M, das als Unix- Derivat vor allem auf den SNI-Fujitsu-Vektorprozessoren an den deutschen Hochschul-Forschungseinrichtungen Einzug gehalten hat.
Von den vorgestellten sanften Loesungskonzepten ist die Integration von TCP/IP auf dem Host sicherlich die leistungsfaehigste Variante. Dies gilt nicht nur fuer die zur Verfuegung stehende Applikationsvielfalt, sondern auch fuer den zu erreichenden Datendurchsatz vom und zum LAN. Durch eine geeignete Netzsoftware wird zudem - im Gegensatz zu allen anderen Ansaetzen - auf dem Host eine dem ISO/OSI-Kommunikationsmodell adaequate TCP/IP-Implementierung vorgenommen. Prinzipiell ist hierbei ein vollstaendiger Client-Server-Betrieb moeglich; oft allerdings mit Betriebssystem-bedingten Einschraenkungen.
Eine Entscheidung zugunsten der TCP/IP-Implementierung sollte von folgenden sachlichen Vorueberlegungen gepraegt sein:
- Von welchen LANs aus soll via TCP/IP auf den Mainframe zugegriffen werden?
- Welches LAN soll der LAN-/370-Controller primaer unterstuetzen?
- Welche Dienstleistungen sollen auf dem Mainframe ueber TCP/IP verfuegbar sein?
- Auf welche Betriebs-Subsysteme soll der Netzwerkzugriff moeglich sein (VTAM, Netview, RSCS)?
- Soll der Mainframe auch als Fileserver dienen, indem beispielsweise allabendlich PC- und Workstation-Dateien auf dem Host gesichert werden?
- Oder sollen die Dasd-Datensaetze den PC- und Workstation- Anwendern permanent zur Verfuegung stehen (Stichwort NFS)?
- Besteht die Notwendigkeit, automatisierte Prozesse gegenseitig zu starten?
- Benoetigen die Benutzer an den 3270-Bildschirmen Full- screen-Zugriff auf VMS- oder Unix-Applikationen?
- Sind die angeschlossenen IBM- und Netzdrucker gemeinsam zu nutzen?
- Wird ein gemeinsames E-Mail-System angestrebt ?
Sowie ferner:
- Welche Transferleistungen muessen von der TCP/IP-Implementierung auf dem Host erbracht werden. Wie viele simultane Sitzungen und welche DUe-Raten sind zu realisieren?
- Bietet die TCP/IP-Implementierung Schutz vor unbefugtem Eindringen (unterstuetzt sie beispielsweise RACF)?
- Wieviel an Rechnerresourcen (CPU-Verbrauch, Kanalbelastung) erfordert das TCP/IP auf dem Host?
- Ist die TCP/IP-Netzsoftware vom Betriebssystem abhaengig (etwa beim Upgrade von XA auf ESA)?
- Inwieweit kann eine gemeinsame Netzueberwachung realisiert werden?
Obwohl die meisten dieser Fragen individuell geklaert werden muessen, lassen sich aus der Struktur einer TCP/IP-Implementierung auf dem Host bereits wichtige Schluesse ziehen. Eine der zentralen Schlussfolgerungen ist dabei, dass die SNA- Kommunikationsmoeglichkeiten (wie beispielsweise LU 6.2) auf den ueber das LAN und TCP/IP angekoppelten Rechnern nicht zur Verfuegung stehen. Vielmehr wird durch die TCP/IP- Netzsoftware dem IBM-(kompatiblen)- Rechner die "Fremdsprache" TCP beigebracht. Doch nicht nur der Host muss diese beherrschen, auch der System- und Netzadministrator muss neue Begriffe aufnehmen, etwa Telnet, FTP, SNMP, DNR, NFS, XDR, X.11 etc.
Von den beiden Betriebssystemen MVS und VM ist VM das juengere und kommunikationsfreundlichere. Das Konzept der virtuellen Maschinen wird dabei auf Grundlage des Control Programmes (CP) realisiert. CP verwaltet die Ressourcen und ist Traeger unterschiedlicher virtueller Maschinen, von denen vor allem die CMS-und VSE-Rechner in der taeglichen Praxis zum Einsatz kommen. Ferner stehen bestimmte Dienstleistungs-Rechner bereit, etwa VTAM und RSCS. Vorteil dieses Konzeptes ist, dass sich auch TCP/IP-Netzrechner ohne Probleme eingliedern lassen.
Diese Netz-VM beinhaltet den TCP/IP-Protokollstack, ist Multitasking-faehig und gewaehrleistet die Kommunikation vom und zum LAN-Controller sowie von und zu den benutzervirtuellen Rechnern (vgl. Abbildung 1).
Cross Memory Services fuer schnellen Datenaustausch
Das MVS-Betriebssystem erfordert hingegen die Anbindung der TCP/IP-Netzsoftware an das VTAM. Im SNA-Jargon ist auch TCP/IP ein Major-Node und wird in einem eigenen Task verwaltet. Ueber das Transportmedium ACF/VTAM kommuniziert TCP/IP mit den anderen VTAM- Applikationen, etwa TSO oder CICS. Bei der effektiven Uebertragung grosser Datenmengen stellen die innerhalb von MVS/XA und MVS/ESA bereitstehenden Cross Memory Services (XMS) wichtige Dienstfunktionen dar, die erheblich zur Beschleunigung des Datenaustausches zwischen den MVS-Tasks beitragen.
Abbildung 2 zeigt den schematischen Aufbau einer TCP/IP- Implementierung innerhalb des MVS-Betriebssystems. Dabei ist besonders die geschichtete, dem OSI-Referenzmodell sehr nahe kommende Struktur der TCP/IP-Software erkennbar: Die Kommunikation zum LAN-Controller wird vom Treiber XMTETH realisiert, der die Schnittstelle zur MAC-Ebene beinhaltet. Die IP- beziehungsweise TCP/UDP-Dienstleistungen (Ebenen 3 und 4) werden vom Subtask XMTETH wahrgenommen, der damit auch die Kontrolle der Sessions innehat. Der XMTTNS stellt auf der Applikationsebene den Telnet- Server dar, das Modul XMTALG ist der fuer das FTP-Protokoll benoetigte Auto-Logger. Das Interface zum SNMP-Management wird durch den XMT-SNMP realisiert.
Kommunikation ueber Socket-Schnittstellen
Die auf diese Weise erfolgte Implementierung der Netz-Tasks umfasst - wie dargestellt - lediglich die TCP/IP-Server. Die TCP/IP-Client-Applikationen - wie etwa in Abbildung 2 Telnet und FTP - sind als TSO- Module von den Anwender-Adressraeumen aus abrufbar. Die eigentliche Kommunikation wird dabei ueber die vorhandenen Socket- Schnittstellen zwischen dem Benutzer- und dem Netz-Adressraum auf Grundlage einer LU vom Typ 0 und 1 bewerkstelligt.
Alternativ koennen die TCP/IP-Clients auch als eigenstaendige VTAM- Applikationen mit separaten Adressraeumen implementiert werden, deren Dienstleistungen dann der MVS-Benutzer in Anspruch nehmen kann.
Die Einbettung des /370-Rechners mittels TCP/IP in ein PC- und Unix-Umfeld erfordert die Ueberbrueckung einiger wesentlicher Systemunterschiede, die im folgenden schlaglichtartig beleuchtet werden sollen. Bei allen Unterschieden zwischen der /370- und der asynchronen Welt stellen sich vor allem zwei Fragen:
- Welche Moeglichkeiten der dezentralen Nutzung von Mainframe- Ressourcen koennen ueberhaupt erzielt werden?
- Wie leistungsfaehig sind diese Loesungen?
Interaktiver Fullscreen-Betrieb
Eine der wichtigsten Forderungen lautet, sich auf dem /370-Rechner einloggen und dort lokale Applikationen ausfuehren zu koennen. Diese Vorgabe erfuellt das Telnet-Protokoll. Notwendig hierbei ist insbesondere der interaktive Fullscreen-Betrieb. Dies betrifft zunaechst das Arbeiten auf dem Host, da das generische Telnet-Protokoll hierzu nur dann in der Lage ist, wenn auf dem /370-Mainframe eine 3270-Emulation vorhanden ist. Andernfalls muessen die Telnet-Clients (Unix-Rechner oder PCs) dem /370-Host einen 3270-Datenstrom anbieten, was mit Hilfe des sogenannten TN3270 geschehen kann.
Der umgekehrte Weg, eine Telnet-Sitzung vom 3270-Bildschirm aus zu starten und beispielsweise einen Unix-Rechner zu adressieren, fuehrt im Regelfall lediglich in den Linemode-Betrieb. Viele Unix- Applikationen erfordern aber ein masken-
orientiertes Arbeiten, was wiederum nur im Fullscreen-Modus moeglich ist.
T100-Bildschirm auf einem 3270-Terminal
Unabhaengig davon ist jedoch auch die Fullscreen-Emulation - etwa eines VT100-Bildschirms auf einem 3270-Terminal - realisierbar, unter der Bedingung, dass eine zusaetzliche ASCII-Terminal-Emulation eingesetzt wird. Diese ist aus technischen Gruenden nicht so komfortabel wie die 3270-Emulation, gestattet aber immerhin die Nutzung des Unix-vi-Editors oder des DEC/VMS-EDT.
In der Praxis hat sich gezeigt, dass die ueber TCP/IP gesteuerten Bildschirme beziehungsweise die hierdurch vorhandenen logischen Sitzungen meist schneller bedient werden koennen als Terminals, die ueber lokale Cluster-Kontroller angeschlossen sind. Da auch die Anzahl der simultanen Sitzungen im Prinzip lediglich durch das Betriebssystem beschraenkt ist, ist auch der Zugang auf den Host ueber das Telnet-Protokoll eine leistungsfaehige Verbindung. Einschraenkungen existieren jedoch bei Grafiken, da Telnet unter Verwendung der genannten Emulatoren lediglich einen Textmodus gestattet.
In der Vergangenheit wurde der Daten- beziehungsweise Filetransfer zwischen den Dasd- und Unix-Systemen mit Hilfe des File-Transfer-Protokolls (FTP) synonym gesetzt, das einen vollstaendigen Client-Server-Betrieb zulaesst. FTP-Sessions koennen beispielsweise aus einer TSO-Sitzung gestartet werden, oder es kann von einer Unix-Umgebung aus eine FTP-Session auf dem Host geoeffnet werden. Ist dieser Vorgang eingeleitet, laesst das FTP- Protokoll die Uebertragung binaerer und Text-Files zu - mit einer vollstaendigen EBCDIC - beziehungsweise ASCII-Umwandlung.
Auf diese Weise koennen unter VM beliebige CMS-Files, unter MVS sequentielle Files beziehungsweise Members von PO-Datensaetzen oder auch ganze PO-Dateien zwischen den FTP-Partnern transferiert werden. Interessant ist dabei vor allem die Moeglichkeit, unter MVS FTP ueber JES zu starten. Aus diesem Grund eignet sich das FTP- Protokoll auch fuer automatisierte Backups der Workstation-Daten auf dem /370-Host. Die entscheidende Leistungsgroesse ist hierbei die Datenuebertragungsrate. Im Normalfall stellt die Belastung des Host-Rechners die massgebende Begrenzung fuer die Transferrate dar, die in guenstigen Faellen bei Ethernet-Topologien zwischen 500 und 800 Kbit/s liegt.
Die in heutigen DV-Strukturen zunehmend erforderliche enge Einbindung des IBM-(kompatiblen)Rechners in das Unix-Umfeld wird durch die Implementierung des Network File Protokolls NFS ermoeglicht. Da NFS eine Unix-aehnliche File-Struktur voraussetzt, steht zunaechst die Frage des NFS-Server-Betriebs fuer den /370-Host im Vordergrund. Die NFS-Server-Dienste unter VM und MVS bedeuten, dass einerseits komplette CMS-Mini-Disks, andererseits aber auch PO-Dateien als lokale Unix-Verzeichnisse gemountet werden koennen.
Entsprechend dem FTP-Protokoll unterstuetzt auch NFS einen binaeren und Text-File-Modus. Einerseits ist somit die Moeglichkeit gegeben, den /370-Host als Fileserver in die Unix-Umgebung einzubeziehen, andererseits hat der Unix-Anwender die Moeglichkeit, beispielsweise die Members in einer PO-Datei ohne Kenntnis der MVS-Struktur zu bearbeiten und zu editieren. Die Transparenz geht dabei sogar soweit, dass beispielsweise die auf einer gemounteten CMS-Mini-Disk abgelegten Unix-Dateien - sofern mit den richtigen Unix- Dateivariablen versehen - lokal ausfuehrbar sind, ohne dass auf die Tatsache Ruecksicht genommen werden muss , dass sie unter VM residieren. Als Advanced Program-to-Program Communication (APPC) stehen in der TCP/IP-Welt mehrere aus dem Unix-Bereich kommende Protokolle zur Verfuegung. Diese sind die Remote Procedure Calls (RPC), die Remote Execution (Rexec) und die Remote Shell (RSH). Fuer RSH gibt es unter VM/MVS kein Aequivalent; als direktes Programm-Interface koennen weiterhin die IPC-Sockets eingesetzt werden. Neben Standardanwendungen wie etwa NFS, die auf RPC basieren, erfordert die Integration der sogenannten R-Kommandos die Verfuegbarkeit eines C-Compilers unter VM/MVS.
Dadurch ist es moeglich, Programme zu entwickeln, die nach der Einbindung der R-Funktionen sowohl auf dem /370-Mainframe als auch unter Unix lauffaehig sind.
"C" hat viele Dialekte
Der Entwickler muss sich also mit dem Sachverhalt auseinandersetzen, dass C durchaus keine universelle Sprache ist, sondern viele Dialekte hat. Fuer den /370-Host stehen verschiedene C-Compiler bereit, darunter der fuer Entwicklungszwecke oft benutzte SAS/C-Compiler. Will man unter MVS/VM andere Programmiersprachen verwenden, etwa Pascal oder Fortran, ist man entweder auf komplizierte Externals angewiesen, oder aber man benutzt beispielsweise die in der Knet-TCP/IP-Software vorliegenden K-Routinen, die in /370-Assembler abgefasst sind und deren Aufruf somit in jede "hoehere" Programmiersprache eingebettet werden kann.
Es ist zu erwarten, dass die Entwickler der TCP/IP-Software fuer IBM-(kompatible)-Mainframes die Einbindung des /370-Hosts in das bereits vorliegende heterogene Umfeld durch eine immer groesser werdende Vielfalt an Kommunikationsprotokollen erweitern werden. Bei diesem Unterfangen spielt das darunterliegende Netz nur eine untergeordnete Rolle.
Unabhaengig davon, ob Ethernet, Token Ring, FDDI, Ultranet oder andere exotische Topologien die vorhandene Struktur praegen, die Verfuegbarkeit von TCP/IP und somit auch der Mainframe-Ressourcen kann entweder direkt ueber eine entsprechende Schnittstelle des LAN- beziehungsweise /370-Controllers oder ueber geeignete Bruecken oder Router gewaehrleistet werden.
Der geforderten Dezentralisierung steht daher nur noch die logische Integration des Mainframes mit Hilfe von TCP/IP entgegen.
Neben den bereits diskutierten Applikationsmoeglichkeiten gibt es Ansaetze und zum Teil auch schon verfuegbare Produkte, um den Schulterschluss immer enger werden zu lassen. Hierzu zaehlt unter anderem die Einbeziehung des Mainframes in ein universelles Netz- Management-System auf der Basis von SNMP, das sich mittlerweile als Standard-Industrieloesung abzeichnet.
Ferner gibt es neue Ansaetze bei den OSI-Protokollen. In diesem Zusammenhang stehen jedoch weniger die ISO-Vorschlaege wie X.400 und X.500 im Vordergrund, sondern vielmehr die von der Open Software Foundation getragenen Entwicklungen wie OSF-DCE und OSF- DME, deren Inhalt verteilte Prozessarchitekturen sowie Management- Systeme sind.
Ziel dieser Bemuehungen ist es letztlich, ueber das Netz - sowohl auf FDDI- als auch TCP/IP-Basis - von der Session- bis zur Applikationsebene die Staerken der verschiedenen Rechner- und Betriebssystem-Typen durch ein Interprozess-Kommunikations- Protokoll zu koppeln.
Die Ausstattung eines /370-Hosts mit einem Client-Server- orientierten TCP/IP ist also aus besagten Gruenden eine funktionale und sinnvolle Investition zur dezentralen Nutzung seiner Ressourcen. Denn nicht der Host steht heute im Mittelpunkt, sondern das Netzwerk. Wie weit der Anwender dessen Potential ausschoepft, entscheidet mit ueber den Unternehmenserfolg.
* Dr. Erwin Hoffmann ist Leiter Software Support bei der Fibronics Kommunikationssysteme GmbH, Dietzenbach.
Abb. 1: TCP/IP in einem VM-Umfeld. Quelle: Fibronics
Abb. 2: TCP/IP im MVS-Umfeld. Quelle: Fibronics