Nachdem die Anwender sich beim Thema PC-Host-Kopplungen in den letzten zwei Jahren hauptsächlich mit 3270-Emulationen und Datentransfer herumgeschlagen haben, macht sich jetzt langsam die Erkenntnis breit, daß an diese Variante der verteilten Datenverarbeitung höhere Anforderungen zu stellen sind: Wer mit seinen DDP-Konzepten mehr realisieren will als Emulationen und Datenkonvertierung der Host-Anwendung (und nach konsequenten Wirtschaftlichkeitsaspekten muß mehr realisiert werden), kommt nicht um die Probleme der verteilten Anwendungsprogramme (Programm-Kommunikation) sowie der verteilten Datenbanken herum. In diesen beiden EDV-Techniken liegen die eigentlichen Schlüssel für wirtschaftliche dezentrale Anwendungskonzepte. Das galt in der Vergangenheit für mittelgroße DDP-Systeme wie 8100, und das gilt heute für dezentrale PC-Systeme oder PC-LANS. Udo Kellerbach* schildert in diesem Beitrag die neuen Codes für verteilte Datenverarbeitung mit PCs.

Heutzutage sind die system- und anwendungstechnischen Schwierigkeiten bei PC-DDP-Konzepten nicht geringer als zu 8100-Zeiten: Galt es bisher, die DPPX-, DTMS- und DMS-Unverträglichkeiten zum Host zu überwinden, muß man sich heute mit DDM, ECF und SQL-Net herumschlagen. Besonders negativ machte sich bis heute das Fehlen eines geschlossenen IBM-DDP-Konzeptes mit den entsprechenden Software-Bausteinen bemerkbar. Auch nach der jüngsten SAA-Ankündigung bleiben mehr Fragen offen, als beantwortet werden. Wichtigste Elemente der "IBM-Absichtserklärung" SAA für PC-DDP-Konzepte scheinen noch zu sein.

- einheitliche grafische Benutzerschnittstelle und Menügestaltung mit einheitlicher Tastaturbelegung;

- die Verwendung der Sprache ANSI-Cobol 77;

- die Kommunikationsprotokolle 3270-Data-Stream, Document Content Architecture (DCS); die Anwendungsdienste SNA Distribution Services, Document Interchange Architecture (DIA); SNA Network Management Architecture und das Übertragungsprotokoll LU6.2;

- die Netzwerke Low Entry Network, X.25 und Token-Ring sowie das Übertragungsprotokoll Synchronous Data Link Control (SDLC).

Nachdem man das IBM-Ankündigungsfeuer von SAA und neuen PCs mit insgesamt gesehen eher geringer Substanz einigermaßen verdaut hat, gilt es, sich wieder auf seinen gesunden Menschenverstand und klar abgesicherte DDP-Erfahrungen aus der Vergangenheit zu besinnen. Bei aktuell laufenden DDP-Projekten sollte man sich daher nicht verunsichern lassen und die konkret vorhandenen wichtigen Softwareprodukte im Auge behalten: DDM als Datenzugriffsmethode, ECF als Koordinierungssoftware zwischen PC und Host, SQL/RRAS für verteilte relationale Datenbanken, ANSI-Cobol als Programmiersprache, 3270-Emulation als (Übergangs-)Tor zu bestehenden Host-Anwendungen, API (Application Program Interface) sowie APPC beziehungsweise LU6.2 als Programm-zu-Programm-Schnittstelle, DIA/DCA als Dokumentbeschreibungsvorschrift sowie Disoss und PC-Büro als Anwendungssoftware für Host und PC.

PC-DDP mit SQL/RRAS, DDM und ECF

Konkrete Softwareprodukte zur verteilten Datenhaltung bei IBM bezogen sich bisher fast ausschließlich auf Filetransfer oder Datenaustausch zwischen seinen -unterschiedlichen Systemen.

Wohin die DDP-Reise geht, zeigte eine kurze Meldung aus USA wesentlich deutlicher als das marketingorientierte Spektakel für das SAA-Konzept hierzulande: So kündigte IBM ein neues DB-Konzept sowie die zugrunde liegende Zugriffsmethode und Verbindungstools anläßlich der eher unbedeuteten "Interface 87" in Las Vegas an und nannte als Verfügbarkeitstermin 1989.

Das geplante DB-System "verteile" eine rationale Tabelle über mehrere relationale Einheiten, erläuterte Susan Borden, Mitarbeiterin der Information System Group des Telecommunications Marketing Center von Big Blue.

Diese Basiskomponenten sollen mit einer LU6.2-Implementierung für die Enhanced Connectivity Facility (ECF) ausgestattet werden; gegenwärtig liegt ihnen LU2.0 zugrunde. Ferner wurde die Datenzugriffsmethode Distributed Data Management (DDM) in ECF eingebunden. In der erweiterten Form bietet ECF Server- und Request-Funktionen für. PCs, /3X-Systeme sowie für Mainframes der 370-Serie.

Die auf der Abfragesprache SQL basierende relationale Datenbank wird in /3X-Rechner und PCs implementiert. Schließlich soll SQL zusätzlich noch die Unterstützung von DDM übernehmen.

Das Konzept verrät andeutungsweise bereits das bei der 9370-Ankündigung eher untergegangene Software-Feature RRAS: Das relationale Datenbank-Management-System SQL/Data System Rel. 3.5 wurde für VM/Sp. Rel. 5 durch die Funktion Remote Relational Access Support (RRAS)" erweitert.

RRAS erlaubt es jeder autorisierten Anwendung in einer virtuellen Maschine wie AS, QMF, IC/1, CSP etc. auf verteilte SQL/DS-Datenbanken zuzugreifen, die sich auf verschiedenen VM-Systemen befinden.

Das lokale SQL/Data System stellt eigenständig fest, daß sich die vom Benutzer angesprochene Datenbank nicht im gleichen System befindet und nimmt über APPC/VM, unter Benutzung von TSAF, Kontakt mit den entfernten SQL/Data Systems auf, findet den zuständigen Datenbankmanager und sendet den User-Request. Schließlich übernimmt es die Ergebnisse und präsentiert sie dem Endbenutzer wie lokale Datenbanken.

Für die Anwendungen ist dieser Service transparent. Ein Benutzer merkt außer einer gegebenenfalls verlängerten Antwortzeit, wegen notwendiger Ergebnisübertragungen, keinen Unterschied gegenüber der Benutzung einer lokalen SQL/DS-Datenbank.

Zugriff auf fremde Dateien erfolgt transparent

Basiszugriffsmethode für die verteilten Daten ist das sogenannte Distributed Data Management (DDM) - angekündigt als "eine neue Architektur" für den Datenaustausch zwischen unterschiedlichsten Systemen. Sie erlaubt Anwendungsprogrammen den Zugriff auf Dateien in fremden IBM-Rechnern wie /36, /38 sowie PCs. DDM ist so ausgelegt, daß es an das jeweilige Datenmanagementsystem unterschiedlicher Systeme angepaßt ist und der Zugriff auf die Dateien des fremden Systems vollkommen transparent für das Anwendungsprogramm erfolgt. Dies bedeutet, daß über DDM bestehende Anwendungen ohne Änderung der Zugriffsroutinen auf Dateien fremder Systeme zugreifen können. Die DDM-Architektur definiert vier Dateimodelle (sequentiell, direkt, Schlüssel und Alternativindex) und sieben Zugriffsmethoden, zum Beispiel über relative Adresse oder Zusatzschlüssel.

DDM enthält Befehle für das Datenmanagement, wie für das Neuanlegen von Dateien, das Löschen, Umbenennen, Laden und Entladen, Sperren und Entsperren. Die DDM-Architektur enthält eine Formalsprache für die Übertragung von Datensätzen zwischen Systemen. Für den Transport der Datensätze innerhalb eines Netzwerks definiert DDM die LU6.2-Schnittstelle.

ECF steuert die Verbindung zwischen Host und System

Erste Implementierungen de DDM-Architektur erfolgten für die IBM-Systeme /36 und /3 8 und CICS/VS sowie ganz aktuell auch für PCs.

Die ECF (Enhanced Connectivity Facilities) sind für die gesamte Verbindungssteuerung zwischen Großrechner und dezentralen Systemen zuständig.

ECF besteht aus zwei paarweise kommunizierenden Komponenten und zwar den Funktionen:

- Host-Servers auf dem Großsystem und den

- PC-Requesters auf dem PC.

ECF stellt zum Beispiel die Verbindung her zwischen PCs und Hostcomputern unter MVS/XA mit TSO/E oder VM/CMS und erlaubt dem Benutzer.

- die Datenbasis eines Großrechners zu nutzen (Host Data Access); die Dateiformate unter DB2, SQL/DS, extrahierte DL/1 -Daten, VSAM, CMS und sequentielle Dateien werden unterstützt.

- die Rechenleistung und Speicherkapazität eines leistungsfähigeren Rechners in Anspruch zu nehmen (Virtual Host Service). Diese Funktionen können mittels Bildschirmmenüs, Command Language oder Programierschnittstelle genutzt werden.

Die sogenannten Requesters und Servers enthalten die Funktionen Host-Daten-Anschluß (HAD) und Virtual File, Virtual Disk, Virtual Print; sie übernehmen die Konvertierung der unterschiedlichen Datenformate bei den PC-Anwendungen (DIF, Assistant Serie, Lotus Symphonie WRK-, 1-2-3 WKS-Formate, dBaseII/III SDF Delimited Formate, CSV Comma Separated Variables, Multiplan SYLK Format).

Die Requesters (auf dem PC) und die Servers (auf dem Host) setzen auf einem Service-Request-Programming-Interface (SRPI) auf, das im Router enthalten ist.

Die Router-Funktionen verknüpft die ebenfalls im Paar arbeitenden Requesters und Servers. Die SRPI-Schnittstelle ist in der Router-Funktion enthalten und erlaubt dem PC die Verknüpfung mit Host-Anwendungen (derzeit Protokolle unter MVS/XA oder VM/CMS) unabhängig von der Art der Übertragung beziehungsweise der Kommunikation.

3270 - und kein Ende

Die Router-Funktion ist unter MVS/XA in TSO/E ab Rel. 3 und VM/CMS ab Rel. 4 bereits ein schlossen. Auf der PC-Seite ist Router-Funktion im PC-3270-Emulationsprogramm ab V.3 eingeschlossen.

Der Host- und Terminalmarkt wie die benutzten Übertragungsprotokolle werden trotz intensiver Bemühungen internationaler Normungsinstitute nach wie vor geprägt durch IBM-Standards wie 3270 bei Terminals, SNA mit SDLC/ACF/NCP/VTAM bei den Netzprotokollen. Ein strategisches Hauptziel von IBM ist es nämlich, für den gesamten Bereich der Informations- und Kommunikationstechnik die Standards zu setzen. Aus diesem Gesichtspunkt ist auch die jüngste SAA-Ankündigung zu sehen.

Zum Beispiel 3270-Standard: Im Markt der Terminals gibt es faktisch die Ausrichtung auf TTY-Geräte und auf IBM-3270-Prozeduren. Der Bestand an 327X-kompatiblen Terminals soll sich in Deutschland auf zirka 350000 Stück belaufen. Seit IBM 1971 das System 3270 auf den Markt brachte, konnte sich diese Produktreihe als erfolgreichste Terminalfamilie in der DV-Welt behaupten, Branchenanalytiker geben die Anzahl der installierten Einheiten weltweit mit mehr als zwei Millionen an.

Erwarteten Experten für das 3270-Terminal eines Tages einen ähnlichen sang- und klanglosen Abgang wie von der Lochkarte, so wurden sie vom Markt und auch von IBM eines besseren belehrt: Die normierende und erhaltende Kraft besonders der milliardenschweren Anwendungsprogramme, die hinter den 3270-Terminals stehen, setzte sich bis heute gegen EDV-technologische und Preis/Leistungs-orientierte Verbesserungen im Terminalgeschäft erfolgreich durch. Auch IBM hat seit 1983 durch eine Reihe von 3270-orientierten Neuankündigungen im Terminalbereich sogar eine Art Renaissance dieses Terminaltyps unterstütz.

Weitere Konsequenz aus der 3270-Marktmacht: Emulationen ohne Ende - kein "Fremd-Terminaltyp, kein PC, kein TTY-Terminal und auch kein anderes IBM-System außerhalb der 370-Architektur kommen heute mehr ohne das absolute "Muß" der 3270-Emulation aus. Für IBM immerhin keine neue Situation, sich selbst eruieren zu müssen: Der Fluch der früheren Erfolge (siehe 7070, 1401 etc.) bleibt dem Branchenprimus immer treu.

Bezogen auf das Thema PC-DDP hat wohl inzwischen jeder DV-Planer und auch IBM erkannt, daß der Anschluß von PCs als reines 3270-Terminal über Koax-Emulationskarten eine recht teure und aufwendige Angelegenheit ist. Man halte sich einmal folgenden Unsinn vor Augen: IBM und andere kompatible Hersteller produzieren kostspielige Terminalsteuereinheiten mit Koax-Anschlüssen. Danach wird das Koax-Protokoll mit ebenso aufwendigen Mitteln, nämlich mit 3000 bis 4000 Mark teuren PC-Karten wieder auf den PC-Level gebracht. Diesen Aufwand kann sicher nur ein deutlicher Mehrnutzen gegenüber einem "dummen" 3270-Terminal rechtfertigen.

IBMs 3270-Emulations-Programme: Versions-Chaos

Die IBM-3270-Emulation wird im IBM PC auf der Basis des IBM-3278/ 79-Adapters beziehungsweise im IBM-3270-PC auf der Basis des Kommunikationsadapters und Koaxanschlusses an eine Steuereinheit IBM 3274 realisiert, und zwar im Zusammenwirken mit der Software-PC-3278/79-Emulation, PC-Netzwerk SNA-3270-Emulation V1.02 sowie den 3270-PC-Steuerprogrammen V1.2 und V2.1. Diese drei Produkte bilden bei IBM die 3270-Emulations-Familie.

Der PC kann viele der Funktionen der IBM-3278/79-Dialogstation emulieren und ist funktionsgleich oder funktionsähnlich mit manchen Funktionen des IBM-3270-PC-Steuerprogramms. Die Annäherung des normalen PCs an die Funktionen des IBM 3270 PC ist interessanterweise in mehreren Schritten vollzogen worden.

So wurden am 18. April 1986 die Version 1 und 2 der IBM-PC-3270-Emulationangekündigt, die die Emulation weiterer IBM-Geräte vorsieht, den Anschluß über Koaxialkabel an eine noch größere Palette von IBM-Produkten ermöglicht und auch Verbindungen unter anderem zum IBM-PC-Netzwerk und IBM-Token-Ring schafft. So werden mit der Version 2 Gateway-Funktionen im IBM-PC-Netzwerk und IBM-Token-Ring unterstützt, die es ermöglichen, von einem PC im Netzwerkauf einfache Weise zum Host Daten zu übertragen.

Diese Entwicklung wurde schon im Mai 1986 mit der IBM-3270-Emulation Version 3 fortgesetzt. Diese Version bietet nun weitere Funktionen, wie Koaxanschluß an IBM 3274, die im BSC mit dem Host verbunden ist, sowie 3725-Anschluß an den IBM-Token-Ring direkt ohne 3274.

Software-Voraussetzungen waren 1986 noch:

- Betriebssystem IBM PC DOS Version 2.1 oder höher für den IBM PC und PC XT beziehungsweise Version 3.1 oder höher für IBM PC, PC XT und PC AT.

- Für Dateiübertragung zwischen Host und PC muß im Host ein IBM oder äquivalentes 3270-PC-Datenübertragungsprogramm installiert sein: VM/SP - IBM Programm 5664-281, MVS/TSO - IBM Programm 5665-311, VSE/SP 2.1.1 oder 2.1.2 erfordert kein zusätzliches Programm, sowie SSX/VSE 1.4.1 erfordert ebenfalls kein zusätzliches Programm.

Bei der jüngsten Ankündigung des neuen /2-PC stellte IBM darüber hinaus des PC-3270-Emulationsprogramm in der Versionen 1.1 und 1.2 vor, das die Bildschirme 3278-2, 3279-2A/S2A darstellen kann. In der Version 3.0 soll dieses Programm mit mehr Funktionen die Flexibilität 3270-Emulation erhöhen.

DDP-Anwendungen werden mit APPC/API realisiert

Die Antworten der IBM auf Problem der verteilten Anwendungen sind auf SNA-Ebene das LU6.2 Protokoll, auf Datenstruktur-Ebene die Bürokommunikationsarchitekturen DIA (Document Content Architecture) und DCA (Document Content Architecture) sowie bei konkreten Anwendungen das Produkt Disoss (Distributed Office Support System). Bei der Verbindung von stehenden kundeneigenen Host-Anwendungen kommt noch die Funktion API (Application Program Interface) hinzu.

Für die Subsystem-Anbindung an den IBM-Host hatte IBM bereits 1982 die neue Kommunikationsform innerhalb SNA vorgestellt: Advanced Program-Program-Communication (APPC) beziehungsweise LU6.2. Dieser LU-TYP umfaßt sehr einfache bis komplexe Sessions-Typen. Aus Sicht von IBM stellt LU6.2 nicht nur einen Transportservice dar, sondern auch wesentliche Betriebssystemfunktionen für Anwenderprogramme. Ein LU.6-Netzwerk ist daher ein erster Schritt in Richtung auf ein verteiltes Betriebssystem. Neben den normalen Transportfunktionen, wie Verbindungsaufbau und -abbau, Senden/Empfangen sowie Segmentierung von Nachrichten, stehen zusätzlich zur Verfügung:

- Unterscheidung verschiedener Übertragungsarten wie SECURE, BULK, LOW DELAY;

- Unterstützung mehrerer Verbindungen unter Umständen verschiedener Anwendungsprogramme (parallel session);

- Resource-Allocation;

- Deadlock-Erkennung;

- Setzen von Synchronisationspunkten zum Steuern verteilter Transaktionen und zum Wiederaufbau nach Übertragungsfehlern oder Deadlock.

Die LU6.2-Funktionen stehen auf den IBM-Systemen in Form einer Schnittstelle für Anwendungsprogramme zur Verfügung. Für höhere Programmiersprachen existieren sprachspezifische Anpassungen dieser Schnittstelle. Die Anpassungen enthalten optionale Konversionen sprachspezifischer Datenstrukturen, ähnlich wie formatierte Ein-/Ausgabe. Es ist das strategische Ziel der IBM, zukünftige verteilte Anwendungen auf verschiedenen Systemen ausschließlich auf Basis von LU6.2 zu realisieren.

Im neuen IBM-Konzept erfolgt ein wesentlicher Teil des Informationsaustausches außerhalb des zentralen Rechners in Form von Dokumenten, wobei der Begriff Dokument sehr weit gefaßt wird. Ein Dokument kann Datentypen aller Art enthalten, wie Text, Grafik, Sprache oder Tabellen. IBM hat für alle diese Datentypen Regeln entwickelt, wie sie innerhalb eines Dokuments dargestellt werden müssen. Weiter existieren Regeln, wie die Datentypen gemischt oder geschachtelt werden können. Alle diese Regeln sind in der Document Content Architecture (DCA) zusammengefaßt.

Programm-Programm-Kommunikation wird über LUG. 2 abgewickelt

Der Dokumentenaustausch selbst, also die Art der Adressierung, Angaben zum Inhalt des Dokuments, Versandart etc., ist durch die Document Interchange Architecture (DIA) geregelt.

DIA setzt die Programm-Programm-Kommunikation über LU6.2 voraus. Es definiert oberhalb davon eine Reihe von Funktionsmengen (Fct Sets), die jeweils eine abgeschlossene Kategorie von Diensten überdecken. Die Fähigkeit der Vereinbarung einer oder mehrerer Funktionsmengen erlaubt verschiedenen Implementierungen von DIA, miteinander zu arbeiten, ohne alle Funktionen unterstützen zu müssen.

Dokumente in diesem Sinne sind zum Beispiel ein einfacher Text, ein Formular, ein Batchjob in Form von JCL-Statements, eine Datenbankfrage formuliert in SQL, oder ein Datenbankreport.

Auf dem Host selbst läuft dann schließlich Disoss. Eine wesentliche Eigenschaft von Disoss ist aber die Möglichkeit, virtuelle Benutzer zu definieren. Dokumente können an virtuelle Benutzer, also an Bearbeitungsinstanzen, geschickt werden. Diese bearbeiten das Dokument (zum Beispiel eine Datenbankabfrage) und erzeugen eine Antwort in Form eines Dokuments, das an den Auftraggeber zurückgeschickt wird.

Diese Bearbeitungsinstanzen sind normale Host-Applikationen, die über das sogenannte Application Program Interface (API) mit Disoss kommunizieren, aber keine Benutzerschnittstelle im üblichen Sinn mehr besitzen. Sie empfangen oder versenden nur noch standardisierte Dokumente im DCA-Format. Damit stellt im Konzept der IBM Disoss mit seiner API-Schnittstelle die Verbindung zwischen der externen Welt und den Applikationen auf dem zentralen Host her.

Auch Nicht-IBM-Rechner, die beispielsweise mit zentralen Host-Applikationen über Disoss kommunizieren wollen, müssen diese nach DCA strukturierten Dokumente bearbeiten können und sie nach den Regeln der DIA mit dem Host austauschen. Dies gilt auch, wenn vom Abteilungsrechner oder PC aus auf das zentrale Dokumentarchiv auf dem Host zugegriffen werden soll.