Die Einbindung von SNA-Netzen in unterschiedliche Systemumgebungen ist nicht nur eine Frage der technischen Machbarkeit, sondern auch der Finanzierung und des Nutzens. Zwar ist es mit der Oeffnung der IBM-Welt und ihrer "Standards" teilweise leicht moeglich, technisch eine Kopplung an andere Welten zu realisieren. Ob und wann das allerdings sinnvoll ist, und warum "eine komplette Homogenisierung nicht moeglich oder nicht finanzierbar ist", beschreibt Eckhard Klockhaus.Seit der Vorstellung des Networking Blueprint von IBM im Maerz 1992 kommen sich IBM- und Non-IBM -Netze naeher. Neben einer Reihe von Produkten und Erweiterungen der IBM draengen immer mehr Anbieter mit Kommunikationskomponenten auf den Markt, um SNA-Netze in unterschiedlichen Systemumgebungen einzubinden. Mit dem Ende der hierarchischen Datenverarbeitung und dem Boom von dezentralen Systemen entwickelten sich bei vielen Anwendern zwei getrennte DV- Loesungen: die Grossrechnersysteme von IBM und die Arbeitsplatzrechner, Server oder Minis in eigenen Netzwerken. Terminalemulationen und Filetransfer koennen hierbei nur zeitlich begrenzt eine Rolle spielen, denn der Aufwand fuer Administration und Betreuung verdoppelt sich nahezu. Ferner ist auch mit zunehmenden Ueberschneidungen der Anwendungsgebiete dieser Zustand nicht laenger effizient. Die Begruendungen fuer die komplette und systemuebergreifende Vernetzung liefern die Anwender, die unterschiedliche Systeme bedienen muessen, erforderliche Entwicklungen von Applikationen fuer unterschiedliche Plattformen und ein nicht mehr oder nur in Teilen moegliches Netzwerkmanagement. Dazu kommen die Parallelhaltung gleicher Daten und die direkten Kosten durch eine systemabhaengige Infrastruktur und Peripherie. Nicht selten haben Grosskunden in der Vergangenheit sogar ihre Verkabelungssysteme parallel aufgebaut: SNA-Netze mit Token Ring-Verkabelung und Ethernet-Netze fuer PCs und Workstations. Bei SNA (System Network Architecture) handelt es sich nicht um eine Norm, sondern um einen Industriestandard, der 1974 von der IBM entwickelt wurde. SNA beschreibt eine umfangreiche Struktur von Funktionen, die sich im wesentlichen in drei Bereiche aufgliedert. Der erste Bereich umfasst die Architektur des Netzes, die durch ihre Einzelkomponenten bestimmt wird. Innerhalb von SNA werden diesen Komponenten entweder logische und/oder physische Funktionen zugeordnet, woraus sich die Architektur ableitet. Der zweite Bereich betrifft die Vereinbarungen, wie die Komponenten miteinander kommunizieren koennen. Diese Vereinbarungen oder Protokolle sind in SNA definiert. Als drittes umfasst SNA die Hard- und Softwareproduk- te, die gemaess den Protokollen und der Architektur ein Netz formen.Bei der Implementierung einzelner Netzwerke muss man allerdings mit mehr Problemen rechnen als bei den Medien fuer die Kommunikation. Die Tatsache, dass ein zwingender Zusammenhang zwischen eingesetzten Rechnern und der Netzwerkverkabelung bestand, gehoert als Verstoss gegen Investitionsschutz der Geschichte an. Auf diesem Layer des Schichtenmodells ist mit dem Einsatz von Mac-Layer-Bridges wie der 8209 von IBM fuer Zukunftsinvestitionen Abhilfe geschaffen. Darueber hinaus ist auch Ethernet nicht mehr ein Fremdwort der IBM-Philosophie. Auch wenn viele Kosten durch "K.o.-Kriterien" dieser Art zwischen System und Kabel in der Vergangenheit entstanden sind, soll der weitere Schwerpunkt dieses Beitrags auf den allgemeinen Moeglichkeiten und den damit verbundenen Themen liegen und nicht die historischen Missstaende aufzeigen. Eine aktuelle und genaue Analyse des Ausdrucks heterogener Netze und der Themengebiete von SAA/ SNA (System Application Architecture) zeigt, dass der Hard- und Softwarehersteller IBM nicht mehr und schon gar nicht nur im Grossrechnerbereich in einem direkten Zusammenhang zu SNA steht. Die kontraeren Architekturen zwischen Standards im LAN und SNA sowie zwischen Unix und SNA existieren nicht mehr. Es waere wohl uebertrieben und zu einfach dargestellt, wenn man behaupten wuerde, dass IBMs SNA selbst heterogen sei, aber die Einhaltung von SNA- konformen Standards wird zunehmend einfacher. Eine Trennung zwischen IBM und Non-SNA ist nicht mehr gegeben. Waehrend IBM sich in der Architektur inzwischen auch anderer Standards bemaechtigt hat, wurde es den anderen Herstellern leicht moeglich, den IBM- Definitionen zu entsprechen. Oftmals laesst sich hier die Frage nach dem Berg und dem Propheten stellen. Wenn in der Vergangenheit TCP/IP und darauf basierte Dienste als Non-SNA zu bezeichnen waren, entsprechen NFS (Network File System), Telnet und Sockets, um nur einige zu nennen, nicht mehr den der IBM unbekannten Themen. Dass die IBM im Zusammenhang mit SNA ueber Novells IPX (Internet Packet Exchange) und dem Apple File Protocol spricht, ist bezeichnend dafuer, dass Big Blue mehrfarbig wird. (Beim Oeffnen des blauen Kartons wird auch die Netware von IBM wieder rot.) Dennoch ist das Thema, die herkoemmlichen SNA-Rechner mit unterschiedlichen Komponenten zu vernetzen, nicht lapidar. Genauso heikel ist oftmals auch das Thema der IBM-Einbindung in SAA/SNA- Welten. Hat ein Unternehmen beispielsweise den Datenbestand auf dem Grossrechner als VSAM-Files (Virtual Storage Access Method) gespeichert, so ist es ein nahezu aussichtsloses Unterfangen, wenn hier die Offenheit von SNA zum Tragen kommen soll. Verstaendlich ist dann, dass die Einbindung von dezentralen Netzen im Detail zu scheitern droht. Wir werden spaeter Beispiele dafuer bringen, dass sich ein technischer Realisationsansatz finden laesst, aber dessen Durchfuehrung nur schwer moeglich ist.Einen anderen Gesichtspunkt fuer den tragbaren Aufwand der Verbindungen stellt die Frage der Administrierbarkeit dar. Zusammenfassend kann man das Fazit ziehen, dass zwar Bruecken zwischen SNA und Non-SNA bestehen, aber neben Sinn und Unsinn der Nutzung - abgesehen von der technischen Machbarkeit - auch die Aussicht auf eine effiziente Nutzung eine wichtige Rolle spielt. Betrachten wir zuerst die systemtechnischen Moeglichkeiten auf der Ebene des Transportprotokolls, zeigen sich die Welten wieder als Inseln. IBMs DLC (Data Link Control), Novell mit IPX und aus der Unix-Welt das TCP/IP (Transmission Control Protocol/Internet Protocol) lassen sich zwar problemlos gleichzeitig einsetzen, aber hier muss bereits zwischen Theorie und Praxis unterschieden werden. Ein DOS-Arbeitsplatzrechner kann aus Speichergruenden mit zum Teil nicht akzeptablen Kompromissen diese drei Transportprotokolle gleichzeitig laden. Genau hier stellt sich zum ersten Mal die Frage nach der Art der Vernetzung zwischen SNA und anderen Architekturen. In einer gewachsenen DV-Landschaft ist das Ziel einer kompletten Homogenisierung aller Kommunikationslayers nicht moeglich oder nicht finanzierbar. Die Loesung laesst sich nur derart realisieren, dass man einzelne Koexistenzen zu gemeinsamen Systemen integriert. Hierbei kann man ferner zwischen Ad-hoc- und Systemloesungen unterscheiden. Ad-hoc- Loesungen sind applikationsbezogene Gateways oder Bruecken fuer die Einbindung beziehungsweise Integration von SNA-basierten Komponenten in andere Umgebungen. Systemloesungen haben dagegen keinen direkten Zusammenhang zu einzelnen Applikationen, sondern greifen auf eine Transformierung einzelner Layer und Dienste zu. Waehrend zum Beispiel TCP/IP fuer den Grossrechner als Grundlage fuer die Kommunikation mit Unix-Komponenten als eine Systemloesung zu sehen ist, kann das applikationsbezogene Six2View von Phoenix als Ad-hoc-Loesung bezeichnet werden (das Produkt verbindet die Netzwerkmanagementsysteme NetView mit dem System Polycenter von Digital). Die Installation von gemeinsamen Nennern wie die Nutzung des gleichen Transportprotokolls ist also eine Systemloesung, eine auf den Schichten der Applikationen realisierte Komponente eine Ad-hoc-Loesung. Bei diesem Vergleich faellt auf, dass sich der Markt der Drittanbieter vornehmlich um die Ad-hoc-Systeme und IBM auf die Systemloesungen konzentriert. Negativ dargestellt, entwickeln Drittanbieter Loesungen zur Kommunikation mit aelteren und noch proprietaeren SNA-Komponenten, waehrend gleichzeitig IBM SNA oeffnet. Eine allgemeine Aussage darueber, welcher dieser beiden Wege die bessere Loesung darstellt, laesst sich nicht treffen, da sowohl die Wirtschaftlichkeit als auch die technischen Moeglichkeiten fallbezogen zu betrachten sind. Einen guten Vergleich liefert hier das Thema Datenbankkommunikation: Es gibt zirka 20 Anbieter unterschiedlicher Produkte, die den Zugriff auf DB/2-Daten aus PC- Netzwerken ermoeglichen. Einer davon ist IBM. Mit DRDA (Distributed Relational Database Architecture) kann DB/2 (ab Version 2.3) direkt ueber APPC (Advanced Program-to-Program Communication) mit PC-Netzwerken kommunizieren. Im Netzwerk ist eine Anbindung ueber LU 6.2 an den Grossrechner erforderlich, und die auf OS/2- basierenden DDCS/2 (Distribu-ted Database Connectivity Services) stellen die Gatewaykomponenten im LAN dar. Die Loesung ist hiermit pauschal geschaffen. Doch die naechste Problematik ergibt sich beim Zugriff der einzelnen Arbeitsplaetze auf das Gateway. IBMs "Standard" SQL-CPI (SQL Common Programming Interface) wird fast ausschliesslich von OS/2-Applikationen unterstuetzt. Hat der Anwender Windows auf den Arbeitsplaetzen installiert, so ist er mit ODBC (Open Database Connectivity) besser beraten. Applikationen von MS Word ueber Excel und Visual Basic bis zu Front-end Tools wie Power Builder unterstuetzen diese Schnittstelle. Mit anderen Gatewayprodukten wie dem Cross Access oder dem Access Server von Micro Decisionware (eine Sybase Company) laesst sich von jedem ODBC- Client auf DB/2-Daten zugreifen. Die Aussage nach dem "richtigen" System ist hier pauschal nicht moeglich, da fuer eine genaue Betrachtung die Gewichtung von Einzelkompromissen erforderlich ist. Datenbanken machen Systemsuche aufwendig Die ideale Situation, dass die bestehenden Systeme nicht veraendert werden muessen, bestimmt die Schwerpunkte fuer die Entscheidungskriterien massgeblich mit. Die Datenbank selbst, die Kommunikationselemente und die Anwenderumgebungen sollten mindestens migrationsfaehig sein. Ein System, bei dem die strukturelle Veraenderung einer Seite erforderlich ist, scheidet meist aus. Wenn es dann mit einer Anbindung von Clients an eine Datenquelle nicht getan ist, und verteilte Datenbanken oder allgemein andere Datenbanken eine Rolle spielen, wird die Suche nach dem einzusetzenden System aufwendig. Fest steht, dass eine herstellerunabhaengige Variante, die sich an Standards haelt, hier aus Kostengruenden nahezu nicht realisierbar ist. Der Zeitaufwand fuer die Systemumstellungen und Erweiterungen sowie der Applikationsentwicklung oder -portierung steigt ueberproportional zu der Anzahl der angeschlossenen Systeme. Eine verteilte Datenbank mit einem unternehmensweiten Datenmodell und unterschiedlichen Datenbanksystemen laesst sich heute wohl nur theoretisch entwickeln. Die Erstellung des Datenmodells und die erforderlichen Veraenderungen der Clients und ganz extrem die notwendige Portierung proprietaerer Applikationen ist aussichtslos. Somit ist die Einfuehrung von Client-Server-Systemen in heterogene Umgebungen mit SNA-Komponenten leichter ausfuehrbar als einfuehrbar. Die Flut an Standards von unterschiedlichen Gremien und Zusammenschluessen sowie die Verbreitung von herstellerabhaengigen Systemen mit eigenen Implementierungen erlauben eine Vielzahl derartiger Loesungen fuer den Zusammenschluss zwischen SNA und einem Fremdsystem. Auch hier laesst sich der heterogene Zustand in der Kommunikation von Datenbanksystemen aufzeigen. IBM, Microsoft, die SQL Access Group, sowie die meisten DV-Institutionen, um nur einige zu nennen, setzen eigene Standards. "Der" Standard fuer alle Systeme existiert jedoch nicht. Nicht nur IBM, sondern nahezu jeder Anbieter und Entwickler von Marktfuehrerprodukten schafft (besser schaffte) eigene Standards fuer die eigene Systemumgebung. Beachtlich ist, wie innovativ IBM seit einiger Zeit auch andere Systeme und Komponenten implementiert. Im selben Jahr, als der Blueprint vorgestellt wurde, naemlich 1992, wurde eine Reihe von Tools und Weiterentwicklungen angekuendigt, die es erlauben, parallele Traegersysteme zusammenzufassen. Allein die Situation, dass bis dato fuer die Realisierung von Terminalemulationen keine Moeglichkeit der gleichzeitigen Nutzung von 3270- und VT- Emulationen mit einem Transportprotokoll und einem Service Provider moeglich war, versperrte viele Integrationen. Diese Abhaengigkeit zwischen Service Provider und Transportprotokoll liess darueber hinaus in der Vergangenheit keine Nutzung bestimmter Ressourcen ueber Plattformen hinweg zu. Ein NFS-Client benoetigt TCP/IP und entsprechend auch eine TCP/IP-basierte Infrastruktur. Hinter dem Namen MPTN (Multi Protocol Transport Network) verbirgt sich, so IBM, die Loesung dieser Engpaesse bei heterogener Kommunikation. Realisierungen von dieser Architektur sind bereits fuer unterschiedliche Umgebungen verfuegbar. (Das IBM-Produkt fuer OS/2 heisst AnyNet.) IBMs Zauberwort der Architektur basiert auf zwei unterschiedlichen Einsatzmoeglichkeiten. Wenn der gemeinsame Nenner auf der Protokollebene einzelner Komponenten nicht verfuegbar ist, oder wenn keine Anpassungen einzelner Schichten realisiert werden koennen, ist das Ziel, eine Black Box dazwischen zu schaffen. Eine Konvertierung von Transportprotokoll und Service ist erforderlich. Alle Dienste, die an einen bestimmten Transport gebunden sind, stellen diese Anforderungen. Die Entwicklungen solcher Native Protokolle findet man auch verstaerkt in TCP/IP- und OSI-Umgebungen. Hier ist MPTN als Mechanismus zu betrachten, um dieses notwendige "Binding" auszuschliessen (siehe Grafik auf Seite 23). MPTN ermoeglicht es den Schichten, ueber dem Transportprotokoll auch ein anderes Protokoll zu nutzen als das, fuer welches es entwickelt wurde. Es sind beispielweise nahezu alle Unix- Datenbanken ueber Sockets und somit TCP/IP- abhaengig einsetzbar. Die erste der beiden Einsatzmoeglichkeiten stellt die Funktion als Access Node dar. Mit diesem Einsatz lassen sich die Schichten 4 und 5 des Referenzmodells mit einem definierten Uebergang einsetzen. Der Nutzen fuer den Netzbetreiber liegt dann in der Unabhaengigkeit zwischen Applikation und Protokoll. So kann beispielsweise in dieser Konstellation eine Applikation, die auf den APIs von CPI-C (Common Programming Interface) erstellt ist, mit einer Datenbank oder einer anderen Applikation ueber Sockets kommunizieren. Die zwei te Funktion ermoeglicht die Nutzung unterschiedlicher Dienste unabhaengig vom Netzwerk. So koennen ueber diese Transport-Gateways Applikationen ueber artfremde Netze verbunden werden. Fuer den Einsatz heisst das: Es kann eine APPC- Verbindung ueber ein TCP/IP-Internet realisiert werden, oder eine Sockets-Applikation ueber den SNA-Backbone kommunizieren. Der Ansatz, welche Moeglichkeiten sich hier im Bereich von APPN-Netzen (Advanced Peer-to-Peer-Networking) mit Network Nodes ergeben, wuerde diesen Beitrag sprengen, dennoch lohnt sich die Ueberlegung einer solchen Konfiguration fuer viele Bereiche.Die Motivationsgruende fuer eine Einbindung von PC-Netzen in IBM- Grossrechner liegen in zwei Hauptgruppen. Auf der einen Seite sind die Anforderungen der Anwender fuer unterschiedliche Loesungen die Ausgangsbasis, auf der anderen Seite stehen konkrete Planungen zu Themen wie Investitionsschutz, Migration und Re-Engineering im Vordergrund. Gleichermassen ist in beiden Faellen eine detaillierte Planung der Vorgehensweise erforderlich. Die herkoemmlichen Strukturen der Unternehmen mit getrennten Verantwortungsbereichen im Rechenzentrum, der Applikationsentwicklung und dem PC- Benutzerservice erschweren diese Planungen oft. Wenn die Integration unterschiedlicher Komponenten mit Downsizing verglichen wird und ein Konfliktpotential zwischen den Einzelbereichen entsteht, scheitert das Konzept. Die Tatsache, dass eine zentrale Informatik fuer solche Aufgaben erforderlich oder besser sinnvoll ist, wurde bei einigen Unternehmen bereits erkannt, doch ist auch hier oftmals eine Zwei-Gruppen-Situation erkennbar. Nicht die Kommunikation aus Sicht der technischen Machbarkeit, sondern die Mitarbeiterkommunikation stellt den Engpass fuer die unternehmensweite Vernetzung in heterogenen Bereichen dar. Erster Schritt aus dieser Sackgasse sollte die Gliederung der DV-Elemente und Aufgaben unabhaengig von Plattformen sein. Wenn in Unternehmen nicht mehr ausschliesslich die Spartenorganisation gefragt ist, und sich eine Prozessorientierung einstellen soll, ist von DV-Seite der erste Schritt in die gleiche Richtung zu tun. Nicht nur bei der Kommunikation der Protokolle und Dienste ist ein Umdenken der applikationsbezogenen Struktur erforderlich. Mit zunehmender Anforderung als Kommunikationsmittel zwischen Geschaeftsablaeufen steigt die Nachfrage nach der Kommunikation von DV-Inseln zu Prozesskommunikationen. Hier fordert die Portierbarkeit von Applikationen und Inseln zu konzeptionellen Loesungen eine technische und organisatorische Einfuehrung und Verantwortung. Die Tatsache, dass bei der technischen Planung die Systemkenntnisse von vielen Bereichen erforderlich ist, erschwert die Realisierung weiter. Im Klartext fallen Hausaufgaben an, die als Voraussetzung fuer ein brauchbares Ergebnis eine Zusammenarbeit unterschiedlicher Bereiche erfordern.