Mit der Ankündigung der Logical Unit 6.2 (LU 6.2) im Jahre 1982 durchbrach die IBM erstmals die bis dahin starren Strukturen von SNA. Nicht ohne Grund, wie Peter Koch* meint, denn die in die Jahre gekommene, hierarchisch orientierte Terminal-Host-Architektur konnte dem wachsenden Bedarf nach verteilten Anwendungen nicht mehr gerecht werden. Die Anforderungen, bedingt durch heterogene DV-Strukturen, waren anders geworden: Verschiedene Rechnersysteme mit unterschiedlichen Fähigkeiten sollten gemeinsam - unter bester Ausnutzung der Ressourcen - die ständig wachsenden DV-Aufgaben bewältigen.
Das Konzept von LU 6. 2 definiert eine Plattform, auf der diese Probleme in Angriff genommen werden können. LU 6.2 stellt hierfür die APPC-Schnittstelle zur Verfügung, die wie der Name schon sagt, innerhalb von SNA die Kommunikation von Programm zu Programm ermöglicht. Hierbei sind beide Programme gleichberechtigt, unabhängig von Hardware und Betriebssystem des Rechners, auf denen sie ablaufen. Aufgrund der Transparenz des APPC-Protokolls (APPC ist unabhängig von den ausgetauschten Dateninhalten definiert) läßt sich ein flexibler Zugriff auf entfernte Datenbestände realisieren. Aufgaben und Prozesse können dabei so verteilt werden, daß sie dorthin verlegt werden, wo sie am effektivsten ausgeführt werden können.
IBM-Software basiert zunehmend auf APPC
Diese Tatsache machten sich auch die Software-Entwickler von IBM zu Nutze, denn die APPC-Schnittstelle ist nicht nur auf allen gängigen IBM-Systemen implementiert, sondern mittlerweile basiert auch eine große Anzahl von Kommunikationsprodukten von Big Blue auf APPC. Neben dem Distributed Data Management (DDM) für verteilte Datenverwaltung sind hier unter anderem "Snads", "Dissos" sowie der PC-Support für die AS/400 zu nennen. Was IBMs Newcomer, die RS/6000 betrifft, wurden fast alle Kommunikationsprodukte über APPC realisiert, wenngleich natürlich auch die auf den 3270-Datenstrom basierenden Protokolle unterstützt werden.
Doch wie steht es um APPC? Sind die Ankündigungen aus dem Jahre 1982 ihren Ansprüchen gerecht geworden? Bevor nach Antworten anhand eines typischen APPC-Projekts gesucht wird, soll kurz auf die Grundlagen und Definitionen von LU 6.2 innerhalb von SNA eingegangen werden.
Innerhalb von SNA besteht jedes physische Netz aus Knoten (Nodes), die über Leitungen miteinander verbunden sind. Das logische Netz wiederum setzt sich aus PUs (Physical Units), SSCPs (System Services Control Points) und LUs (Logical Units) zusammen. Zwischen den einzelnen LUs bestehen logische Verbindungen (Sessions). Eine LU tauscht Informationen mit einer anderen LU über eine oder mehrere Sessions aus.
LU 6.2 ist ein bestimmter LU-Typ, über den ein Transaktionsprogramm mit verfügbaren Netz-Ressourcen verbunden werden kann. Die Zugriffsfunktionen auf diese Ressourcen und damit die Schnittstelle zum, SNA-Netzwerk wird innerhalb von LU 6.2 exakt beschrieben. Als "Advanced Program-to-Program-Comunications" werden Produkte bezeichnet, die eine Implementierung von LU 6.2 zur "Interprogramm-Kommunikation" darstellen. In LU 6.2 kommunizieren zwei Transaktionsprogramme über eine "Conversation", die von einem der beiden gleichberechtigten Partnerprogramme aufgebaut wird (peer-to-peer).
Die Conversation wird dabei einer Session eindeutig zugeordnet. Für den Ersteller des Transaktionsprogrammes ist dies jedoch nicht transparent. Der Zugriff auf die APPC-Sitzung erfolgt via "Mode Name", über den logisch auf die Verbindung zugegriffen werden kann, ohne daß der Programmierer Rücksicht auf physische Netzwerkcharakteristika nehmen muß.
LU 6.2-Verbindungen sind verbindungsorientiert (IP ist beispielsweise "Connectionless") und halbduplex (TCP ist beispielsweise vollduplex). Diese vermeintliche Einschränkung erweist sich jedoch in der Praxis als nicht relevant, da die zeitliche Abfolge der Kommunikation von der APPC-Schnittstelle geregelt wird und somit bei der Programmerstellung nicht berücksichtigt werden muß. Die Konversationen werden von einem aktiven Programm aufgebaut, alle anderen Protokolle (Datenaustausch, Attention, Error Notification und Verbindungsabbau) sind von symmetrisch.
Soweit ein grober Überblick über die Funktionalität der APPC-Schnittstelle. Natürlich ist klar, daß ein komplexes Thema wie die Definition von LU 6.2 an dieser Stelle nur im Überblick erklärt werden kann und mit Sicherheit noch Fragen offen läßt. Deutlicher wird die Problematik vielleicht anhand eines konkreten Projektes.
Bei der zentralen Verwaltung der Fina Deutschland GmbH Frankfurt, existierte folgende Ausgangssituation: In einem typischen SNA-Netz wird zentral ein unter MVS laufendes Host-System betrieben, angeschlossen sind sieben Außenstellen mit den Systemen AS/400 und /36. PCs kommen in dieser Konfiguration als individuelle Arbeitsplatzrechner zum Einsatz und finden gleichzeitig Verwendung als Terminals mit Host-Anbindung.
Alle konzernrelevaten Datenbestände befinden sich auf dem /370-Host. Hier werden auch alle von Kunden eingehenden Aufträge erfaßt, die dann in den dezentralen Auslieferungslagern mit Hilfe der AS/400- und /36-Systemme abgewickelt werden müssen. Zentral erfaßte Aufträge wurden vor Beginn des Projekts nachts per Filetransfer im Batch oder teilweise sogar über Papier zu den Außenstellen übemittelt.
Kritisch war diese Vorgehensweise natürlich insbesondere dann, wenn ein Kunde in Duisburg morgens einen Auftrag erteilte und die Ware nachmittags im Tanklager abholen wollte, der nächste Batch zur Datenübermittlung aber erst für die darauffolgende Nacht vorgesehen war. Nur mit viel Organisationstalent und gutem Willen der Mitarbeiter konnten Fälle dieser Art ohne Verärgerung des Kunden und Störung des betrieblichen Ablaufes abgearbeitet werden.
Anforderungskatalog sprach für den Einsatz von APPC
Aus dieser Konstellation ergaben sich folgende Forderungen:
- Anfallende Auftragsdaten müssen unternehmensweit ohne nennenswerte zeitliche Verzögerung abrufbar sein
- Meldungen über abgearbeitete sollen über den gleichen Weg in der Zentrale für die weitere Verarbeitung sofort zur Verfügung stehen
- Sämtliche Kommunikations- aktivitäten müssen ohne "Operator" ablaufen; die Kommunikation ist an die bestehenden kommerziellen Anwendungen zu koppeln.
- Aspekte der Daten- Übertragungssicherheit sind zu implementieren.
Unter Berücksichtigung des bestehenden SNA-Netzes und der Komplexität der Aufgabenstellung fiel die Entscheidung relativ leicht, das Projekt auf Basis von APPC zu realisieren.
Die Gründe hierfür lagen auf der Hand:
- Die bestehenden Leitungen (Token Ring, SDLC, X.25) und deren Definitionen können weiterverwendet werden
- Alle beteiligten Systeme unterstützen das APPC-Protokoll für eine Reihe von Programmiersprachen
- Differenzierte Zugriffskontrollen werden auf LU-Ebene und über die Berechtigung des Endanwenders realisiert
- Die Anwendungen sind systemunabhängig und können somit leicht portiert werden
- Mehrfache Quittungsebenen ermöglichen es, bei absoluter Datensicherheit eine optimale
Übertragungsgeschwindigkeit zu erreichen.
Unter Berücksichtigung dieser Aspekte konnte das Projekt die gesetzten Erwartungen voll erfüllen. Der Zeitversatz zwischen Auftragserfassung und -abarbeitung konnte dadurch eliminiert und der Service für den Kunden und die Abwicklung von Aufträgen konzernweit erheblich verbessert werden. Herr Friedemann, Leiter Informationsverarbeitung der Fina Deutschland GmbH, Frankfurt resümiert: "Nach Abschluß des Projektes kann festgestellt werden, daß die Entscheidung, APPC als Kommunikationsgrundlage zu wählen, die richtige war. Die erfolgreiche Umstellung der Auftragsabwicklung auf online Datenaustausch hat uns dazu veranlaßt, für weitere Teilbereiche des unternehmensweiten Netzes die Umstellung auf APPC zu planen."
Sicherlich birgt jedes APPC-Projekt eine Menge von komplexen Aufgabenstellungen in sich. Im Gegensatz zu den Terminal-Host-LU-Typen beinhaltet eine LU 6.2 Konfiguration wesentlich mehr Parameter. Die Abhängigkeit der Parameter untereinander ist erheblich höher und komplexer. Nicht zu unterschätzen ist auch der organisatorische Aufwand zur Anpassung der kommerziellen Anwendungen auf den beteiligten Rechnersystemen. Der Vorteil der Vermeidung von Datenredundanz und die optimale Nutzung der Ressourcen rechtfertigt in der Regel jedoch die Anstrengungen, die für die Realisierung eines APPC-Projekts unternommen werden müssen.
Nun existieren neben APPC noch eine Reihe weiterer Protokolldefinitionen, die die Realisierung verteilter Anwendungen unterstützen. Als wichtigstes ist hier wohl TCP/IP zu nennen, dessen Ursprung auf das Jahr 1971 zurückgeht, als es von der DARPA (Defense Advanced Projects Research Agency) innerhalb des US-amerikanischen DoD (Departement of Defense) für die Verbindung von technischen Rechnern im Forschungs- und und Entwicklungsbereich definiert wurde. Größere über TCP/IP verbundene Netze außerhalb des Pentagon wurden erstmals zu Beginn der 80er Jahre in Betrieb genommen.
Ein wichtiger Vorteil von TCP/IP ist mit Sicherheit der hohe Verbreitungsgrad, der sogar die IBM gezwungen hat, TCP/IP für die /370-Systeme zur Verfügung zu stellen. Einen weiteren Vorteil stellt die Tatsache dar, daß die Standarddienste von TCP/IP (Telnet, FTP etc.) auf einer Vielzahl von Rechnersystemen implementiert sind. Eine Schwierigkeit bei der Realisierung von verteilten Anwendungen in heterogenen Umgebungen auf Basis von TCP/IP ergibt sich jedoch daraus, daß TCP/IP nicht vollständig OSI-konform ist und die Protokollgrenzen nicht eindeutig definiert sind.
Diese Problematik ist bei APPC nicht gegeben. APPC ist OSI-konform, die Protokollgrenzen sind innerhalb des Schichtenmodells eindeutig definiert. Somit ist APPC universell portier- und einsetzbar. Durch die strenge Gliederung der Kommunikationsstruktur und klare Definition des Konversationsaufbaus ergibt sich neben höchster Übertragungssicherheit und Zugriffsschutz ein optimierter Durchsatz.
Diesen Tatsachen können sich auch IBMs Mitstreiter nicht verschließen. APPC-Interfaces werden de facto jedenfalls von allen bedeutenden Herstellern angeboten: angefangen bei Digital mit VMS/SNA über Siemens, Bull bis hin zu NCR. Nun mag man vielleicht einwenden, daß die APPC-Philosophie mit ihrer strengen Punkt-zu-Punkt-Architektur Nachteile bei der Realisierung von verteilten Strukturen innerhalb großer Netzwerke beinhaltet - insbesondere, wenn nicht bekannt ist, auf welchem Knoten des Netzes sich die gewünschten Daten befinden. In diesem Fall sind Routing-Verfahren, wie unter TCP/IP oder Decnet implementiert, erforderlich.
Dies hat man auch bei IBM erkannt und im vergangenen Jahr neben der bereits erwähnten Architektur für verteilte Datenhaltung DDM die Netzstruktur um APPN (Advanced Peer to Peer Networking) erweitert. Was in der AS/400- und /36-Welt schon lange bekannt war, wurde nun die strategische Grundlage für künftige Hochgeschwindigkeitsnetze. Ein APPN-Netz besteht aus Netzknoten und Endknoten, die wiederum in der Regel LU 6.2-Einheiten darstellen. APPN ist selbstlernend und selbstsuchend, das heißt bei der Konfiguration braucht nur noch die eigene Station definiert zu werden. Verwaltungssessions zwischen den Knoten tauschen Daten über Netzwerkeigenschaften aus. Auf dieser Basis werden Zugriffsrouten zum Zielsystem optimal berechnet und gesteuert.
Die Einführung von APPN mit seiner Routing-Fähigkeit beseitigt die bisher bestehende Einschränkung der ausschließlichen Punkt-zu-Punkt-Verbindung und schafft damit die Voraussetzung für die Übergänge zwischen unterschiedlichen Netzen. In diesem Zusammenhang ist sicherlich in Zukunft auch die Möglichkeit der Integration in X.400-Netze von Interesse. APPN stellt also in gewisser Weise die Fortsetzung von APPC dar. Es bleibt abzuwarten wie schnell entsprechende Implementierungen für weitere Systeme verfügbar sein werden.
Zusammengefaßt kann also festgestellt werden, daß APPC eine hervorragende Basis zur Realisierung verteilter Anwendungen insbesondere innerhalb von SNA-Netzen bietet. Die Möglichkeiten zur Integration auch von Nicht-IBM-Systemen wachsen dabei ständig. Von immer mehr erfolgreich abgeschlossenen Projekten profitiert letztlich auch die Erfahrung bei Softwarelieferanten und interner DV, so daß die im Moment noch recht komplexe Planung und Realisierung von APPC-Projekten in Zukunft wohl zu einem verbreiteten Standard werden dürfte.
Peter Koch ist Leiter SNA-Projekte bei der Data Engineering GmbH, Kaiserslautern