Immer mehr Unternehmen beziehen aktuelle Informationen von öffentlichen Anbietern. Während sich bei vielen Anwendungen ein Trend vom Großrechner zum PC abzeichnet, sind andere Dienste günstiger über die zentrale DV-Installation abzuwickeln. Das gilt, so Klaus Birkenbihl, Peter Wunderling und Thomas Pahl*, zunehmend auch für die Kommunikationsdienste.

Vor acht bis zehn Jahren waren Computer Mangelware, öffentliche Netze existierten nicht, große Datenbanken von allgemeinem Interesse waren noch nicht aufgebaut, und es gab keine öffentlichen elektronischen Mailbox-Systeme. Damals war der Benutzer zufrieden, wenn er seinem lokal angesiedelten Computersystem mittels des an diesem System installierten Bildschirms Fragen stellen konnte.

Heute fordern viele Computerbenutzer Zugriff auf fremde Informationssysteme, Austausch von Post und Dokumenten sowie Möglichkeiten zur Nutzung fremder Rechnersysteme. Oft steht aus diesem Grund neben dem lokal angeschlossenen Großrechnerbildschirm ein zweites Gerät, das mit Hilfe eines Modems oder eines Akustikkopplers und des Telefons Verbindung zu anderen Rechnern aufbauen kann.

Diese Lösung ist jedoch unsicher, teuer - wenn viele Anschlüsse benötigt werden - und funktional oft kaum ausreichend. Die Forderung ist klar: Vom Endgerät, sei es ein Großrechnerterminal oder eine an den Großrechner angeschlossene Workstation, muß sich jedes andere System, das den Zugang erlaubt, erreichen lassen.

Standards nur in bescheidenem Maße

Die Entwicklung der Datenverarbeitung zwang die Hersteller Mitte der 70er Jahre, Techniken zu entwickeln, die eine möglichst flexible Vernetzung ihrer Geräte erlaubt. Die daraus resultierenden herstellerspezifischen Festlegungen haben dazu geführt, daß herstellerunabhängige Standards und Normen sich nur in bescheidenem Maße entwickeln konnten. Solche Standards sind aber die Voraussetzung dafür, daß Computer verschiedener Hersteller kommunizieren können.

Hier Abhilfe zu schaffen, bemühen sich Institutionen wie die International Standards Organization (ISO) und das Comite Consultatif International Telegraphique et Telephonique (CCITT). Aus der Arbeit der ISO ist sicherlich das Sieben-Schichten-Modell für Telekommunikation (OSI) am bekanntesten, vom CCITT sind es die Empfehlungen der X- und V-Serie. Alle diese Bemühungen haben folgendes zum Ziel:

- eine einheitliche Terminologie für Telekommunikation aufzubauen,

- Telekommunikation vernünftig zu strukturieren und

- Schnittstellen zu definieren, über die Systeme unterschiedlicher Bauart miteinander kommunizieren können.

Die IBM hat für ihre Systeme eine Telekommunikations-Architektur festgelegt, die unter

dem Namen Systems Network Architecture (SNA) bekannt geworden ist. Diese Architektur erlaubt es DV-Systemen, die SNA entsprechen, miteinander zu kommunizieren.

Die Einführung dieser Architektur hatte auf die Umwelt den Effekt, daß viele Terminal-,

Kleinsystem- und in jüngerer Zeit auch Mikrocomputer-Hersteller ihre Geräte mit SNA-Schnittstellen ausrüsten. Auf diese Weise können die Geräte an SNA-Netze angeschlossen werden. Das Problem des wahlfreien und herstellerunabhängigen Dialogverbunds von einem zu einem anderen System wurde dadurch jedoch nicht gelöst.

Seit Anfang der 80er Jahre offeriert die Deutsche Bundespost (DBP) ein paketvermittelndes Netzwerk (Datex-P10 oder einfach Datex-P). Über diesen Dienst können Computer auf Basis der X.25-Empfehlung der CCITT miteinander kommunizieren. Auf das X.25-Protokoll, das die Ebenen 1 bis 3 des ISO-Schichtenmodells realisiert, müssen jedoch Protokolle aufgesetzt werden, die die höheren Schichten realisieren. Die Hersteller verwenden hierfür nach wie vor eigene Protokolle.

Da viele Terminals nicht direkt an X.25 angeschlossen werden können, bietet die Post - basierend auf Datex-P - einen speziellen Service an: Datex-P20 beziehungsweise Vorrichtungen für "Packet Assembly Disassembly (PAD)".

Diese PADs übersetzen ein einfaches asynchrones Protokoll (X.28), das die meisten Terminals und PCs beherrschen nach X.29 und umgekehrt. X.29 ist ein auf X.25 aufsetzendes Protokoll für zeilenorientierten Dialog.

Die Funktionen der PAD-Einrichtung sind in der Empfehlung X.3 der CCITT festgelegt. PADs können zum Beispiel über Modems oder Akustikkoppler und Telefon angewählt werden und stellen dann ihrerseits die Verbindung zu einem Datex-P-Anschluß her. Allerdings ist - wie bereits erwähnt - diese Form der Telekommunikation weder komfortabel noch sicher, oft sind die Fähigkeiten der angeschlossenen Geräte beschränkt, und die Geschwindigkeit ist ebenfalls mäßig.

Erschwerter Zugriff

auf weitere Systeme

SNA erlaubt - ebenso wie die Systeme der meisten anderen Hersteller - über X.29 von beliebigen Endgeräten aus den Zugriff auf ein SNA-Netz. Ist ein Terminal bereits mit einem System verbunden, so kann es Schwierigkeiten geben, über dieses System auf ein anderes zuzugreifen. Es bleibt also für SNA das Problem, von einem am Großrechner angeschlossenen SNA-Terminal aus ein X.29-Protokoll zu erzeugen und damit auf beliebige andere Systeme zuzugreifen.

Inzwischen gibt es Software, die das Herstellerprotokoll des Terminals nach X.29 und umgekehrt transformiert. Diese Software realisiert also für an den Host angeschlossene Terminals das, was der PAD für asynchrone Terminals leistet. Ein solcher Protokollumsetzer ist das Snapad-System der GMD, das für Benutzer von IBM-Großrechnersystemen am SNA-Terminal Verbindungen zu Systemen bereitstellt, die mit X.29 an ein öffentliches Netz angeschlossen sind.

In erster Näherung funktioniert das folgendermaßen: Man nimmt die via SNA-Protokoll (neben SNA kommt hierfür auch jedes andere Terminalprotokoll in Frage) an den Host geschickten Daten des Terminals und übergibt sie an die Kommunikationssoftware (analog zu X.28). Dort werden die Daten in X.29-Pakete verpackt und via Datex-P gesendet. Bei ankommenden Paketen verfährt man umgekehrt.

Dies geht bei den meisten Software-PADs, allerdings nur für solche SNA-Pakete, die sich

nach X.29 umsetzen lassen. Es gibt allerdings einige Gründe, warum dies nicht ganz so einfach ist, wie es hier beschrieben wurde. Dazu soll weiter unten etwas mehr gesagt werden.

Wenngleich die CCITT-Empfehlung X.3 beschreibt, wie X.28 nach X.29 umzusetzen ist, läßt sie doch dem Anbieter wie dem Benutzersystem eine Reihe von Freiheiten. Diese Freiräume werden durch die sogenannten PAD-Parameter ausgefüllt, die zum Beispiel steuern,

- wie Befehle an den PAD gegeben werden können,

- wann Daten weitergeleitet werden sollen,

- was mit Meldungen des PAD passieren soll und

- wie BREAK verarbeitet werden soll; außerdem sorgen sie für die

- Anpassung des Zeilenformats.

Die Parameter für Snapad können vom Benutzer per Kommando gesetzt werden. Allerdings wäre es bei häufig benutzten Verbindungen recht mühsam, jedesmal die Parameter neu zu definieren. Snapad sieht deshalb die Möglichkeit vor, diese Parameter verbindungsbezogen in Tabellen abzulegen und automatisch beim Aufbau einer Verbindung zu aktivieren. Die Tabellen können systemweit vom Rechenzentrum bereitgestellt oder aber vom Benutzer in privaten Dateien abgelegt werden.

In den Tabellen kann außer den PAD-Parametern noch wesentlich mehr Information untergebracht werden. Als wichtigstes wäre da die X.25-DTE-Adresse einer Verbindung zu nennen. Damit ist es möglich, eine Verbindung statt mit "call 45621040000" einfach mit "call telebox" aufzubauen. Und wenn es sich um eine - gut geschützte - private Tabelle handelt, kann man auch noch die Login-Sequenz von der Tabelle abrufen, um diese Sequenz nicht jedesmal am Bildschirm ablaufen lassen zu müssen.

Bei Verbindungsaufbau und -abbau lassen sich automatisch PAD-Kommandos ausführen, die ebenfalls in der Tabelle definiert sind. Solche Kommandos können selbstverständlich auch während der Sitzung am Bildschirm eingegeben werden.

Diese Kommandos dienen beispielweise dazu, Parameter abzufragen oder zu setzen, Verbindungen aufzulösen, PAD-Sitzungen zu beenden, den Status bestehender virtueller Verbindung auszugeben, das Terminalprofil abzufragen oder auszuwählen, ein Sitzungsprotokoll auf Drucker oder Datei auszugeben, Dateien vom eigenen Host als Eingabe an das Zielsystem zu senden etc. Auch die Belegung von Funktionstasten mit beliebigen Zeichenketten kann verbindungsspezifisch über die Tabellen erfolgen.

Natürlich soll sich eine Telekommunikations-Software gut in die Arbeitsumgebung des Be-

nutzers einpassen. Im Fall einer Großrechner-Anwendung gibt es aber viele solche Umgebungen. Allein unter MVS gibt es unter anderem TSO, ISPF, Session Manager, IMS und CICS. Snapad unterstützt heute nicht alle diese Benutzerschnittstellen, hat aber eine Architektur, die eine leichte Anpassung an neue Benutzerschnittstellen erlaubt.

Das Schlüsselwort hierzu heißt "Snapad-Programmschnittstelle" oder "X 29-Zugriffsmethode". Diese Schnittstelle stellt einem Programmierer alle wichtigen Kommunikations- funktionen als Unterprogramme zur Verfügung. Auf dieser Basis können neue Benutzerschnittstellen entwickelt werden. Mit Snapad werden derzeit Benutzerschnittstellen für MVS-TSO, VM/CMS, TSO-Session-Manager und ISPF unter TSO und CMS angeboten.

Es lassen sich ganze Sitzungen automatisch abwickeln, indem Verbindungsaufbau, Datenübertragung und Verbindungsabbau automatisiert werden. Die Benutzer können das Ergebnis solcher Sitzungen als elektronische Post, Dateien oder Druckausgaben erhalten.

Eine weitere Möglichkeit, die Programmschnittstelle zu nutzen, ist die Implementation genormter oder anbieterabhängiger höherer Protokolle. So hat das Softwarehaus Codework auf der Programmschnittstelle ein höheres Protokoll zur Nutzung des Quikcomm-Systems von General Electric Information Systems entwickelt.

Weites Feld für neue Entwicklungen

Die Programmschnittstelle bietet aber nicht nur X.29-Funktionen an, es stehen zusätzlich X.25-Funktionen zur Verfügung. Damit öffnet sich ein weites Feld für neue Entwicklungen. Die erste wurde mit Snapad Version 4 erstmals ausgeliefert. Es handelt sich um die Unterstützung des IBM-3270 Datenstroms.

Es ist also nicht mehr unbedingt notwendig, über eine Snapad-Verbindung im von X.29 vorgeschriebenen Zeilenmodus zu arbeiten. Ein IBM-3270-kompatibles Terminal oder eine entsprechende Emulation kann ebensogut im Bildschirmmodus arbeiten - falls man auf eine Anwendung zugreifen möchte, die es erfordert, darin zu arbeiten. Bildschirmkopien können in Dateien abgelegt werden.

Ein Beispiel soll dies verdeutlichen. Um in einem großen Rechenzentrum mehrere Bildschirme mit dem IBM-Informationsdienst DialIBM zu verbinden, war es bisher notwendig, eine teure X-Domain-Verbindung zu unterhalten oder jedem Terminal beziehungsweise PC ein eigenes Modem samt Telefon zu spendieren. Mit Snapad kann DialIBM einfach via Datex-P angewählt werden. Die einzigen Kosten, die jetzt noch anfallen, sind die Datex-P-Gebühren .

Soweit es die

Architektur zuläßt

Neben dem IBM-3270-Standard hat der von DEC geschaffene Standard "VT100" - auch als ANSI-Standard bekannt - weite Verbreitung für die Steuerung von Bildschirmen gefunden.

Snapad unterstützt auch diese Norm, soweit es die Architektur und der andersartige Übertragungsmodus der IBM-3270-Bildschirme zuläßt. Datenbank- und Computersysteme, die den VT100- Standard anbieten, können also im Bildschirmmodus genutzt werden.

Snapad benutzt nicht den "transparent PAD", den IBM ursprünglich für diese Zwecke offerierte. Im Gegensatz zu den meisten anderen am Markt befindlichen PAD-Emulationen verwendet Snapad die Technik, die die IBM für ihre eigene OSI-Software einsetzt: General Access to X.25 Transport Extension (Gate). Nur so war es möglich, Erweiterungen wie die Programmschnittstelle und den Transport des IBM 3270-Datenstroms zu realisieren. Auch der schnelle wahlfreie Verbindungsaufbau geht nur über diese Funktion.

Doch soll der Kunde keineswegs gezwungen werden, sich IBM-OSI-Software nur für Snapad zu beschaffen: In Rechenzentren, die IBMs OSI-Software (zumindest OSNS) installiert haben, nutzt Snapad die OSNS-Funktionen. Für RZs, die IBM-OSI-Software nicht installiert haben, gibt es hingegen kostenlos die Software Gmdctcp, die alle benötigten OSNS-Funktionen bereitstellt.

Für das Rechenzentrum, das einen solchen Dienst anbietet, ergibt sich eine Reihe von Vorteilen:

- Kostenerfassung über SMF unter Berücksichtigung von Tarifstrukturen,

- installationsbezogene Exitroutinen für Zugriffskontrolle auf Verbindungen,

- ein Muster für ein Abrechnungsprogramm, das den Bedürfnissen des Rechenzentrums einfach angepaßt werden kann sowie

- Steuerungs- und Kontrollmöglichkeiten für den Operator.