Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

09.03.1984 - 

TP-Zugriffsmethode auch für DÜ-Anwendungen über Datex-P einsetzbar:

XTAM läßt 8890 im Btx-Verbund arbeiten

MÜNCHEN - Als externer Rechner (ER) im Bildschirmtext-Verbund läßt sich jetzt die 8890 von Nixdorf einsetzen. Basis für diesen ER-Anschluß ist die TP-Zugriffsmethode XTAM (Extended Telecommunications Access Method). Sie ist eine über Btx hinaus einsetzbare Methode, die Datenfernverarbeitungsanwendungen mit der 8890 über Datex-P unterstützt. Klaus Weller, Projektleiter bei der Münchener Telenet, gibt einen XTAM-Überblick.

Beim Systementwurf von XTAM war es im Hinblick auf eine klare Trennung der verschiedenen Funktionsschichten und auf eine gute Wartbarkeit des Produktes naheliegend, für jede Kommunikations-Protokollschicht einen eigenen Prozeß zu definieren. Weitere eigenständige Prozesse in XTAM sind die Benutzerschnittstellensteuerung, die Bedienungsschnittstelle zur Operator-Konsole, das Sammeln von Statistikdaten und die Zeitüberwachungsroutine, die gleichzeitig mehrere Zeitüberwachungen für verschiedene Prozesse durchführt. Da XTAM als eine einzige NIDOS/VSE Task abläuft, war es erforderlich, die Verwaltung und Ablaufsteuerung der einzelnen Prozesse einem Partition Manager zu übertragen.

Inter-Prozeß-Kommunikation

Die XTAM-Prozesse kommunizieren untereinander über ein internes "Mailing System". Jeder Prozeß der einem anderen Prozeß ein Ereignis übermitteln möchte, fordert zu diesem Zweck zunächst einen Datenpuffer aus einem zentralen Pool an trägt die zu verarbeitenden Informationen ein und übermittelt sie anschließend - ähnlich wie beim Briefverkehr der Post - an den gewünschten Partnerprozeß. Den "Briefverkehr" in XTAM erledigt das GTPI (General Teleprocessing Interface). Der Briefumschlag trägt die Anschriften von Empfänger und Absender in Form von Prozeß-Identifikationen.

Automaten-Design

Im Umschlag befinden sich standardisierte Briefbögen, auf denen der Empfänger erfährt, was mit den übermittelten Daten und Steuerinformationen zu tun ist. Sollte ein Briefbogen nicht ausreichen, so kann ein Brief aus mehreren solcher Bögen in Form von geketteten Datenpuffern bestehen. Durch allgemeingültige Regeln für den Ablauf eines "Schriftwechsels" können beliebige XTAM-Prozesse miteinander kommunizieren. Die einzelnen Prozesse sind dadurch voneinander entkoppelt.

Der XTAM-Entwurf sieht vor, daß sämtliche Prozesse als endliche Automaten (Finite State Machines) arbeiten. Jeder Prozeß in XTAM besteht aus einer Hauptroutine und je nach Komplexität des Protokolls aus einer mehr oder weniger großen Zahl von Aktionsroutinen. Beim Eintreffen von Ereignissen ruft der Partition Manager die Hauptroutine des jeweiligen Prozesses auf. Diese Hauptroutine übernimmt daraufhin die Analyse und logische Prüfung der Ereignisse und delegiert anschließend die Verarbeitung an einen Automaten.

Die Logik dieses Automaten steht in einer Tabelle. Diese Tabelle beschreibt das komplette Protokoll in allen Zuständen und für alle Ereignisse: Zu jedem Zustands-Ereignis-Paar enthält sie eine definierte Folge von Aktionsroutinen und den jeweiligen Folgezustand, in den der Automat nach Abschluß der Aktionsroutinen wechselt.

Das interne "Mailing System" von XTAM erlaubt es, daß Benutzerprogramme sich je nach Kommunikationspartner wahlweise als "Link Service User", als "Network Service User" oder als "Transport Service User" bei der Zugriffsmethode anmelden können. Abhängig von dieser Anmeldung leitet die Benutzerschnittstellensteuerung die Übertragungswünsche der einzelnen Benutzer an die Funktionsschicht 2 oder 3 oder 4 weiter. Das heißt: Die höheren Protokollschichten des Nixdorf-8890-Bildschirmtext-Pakets nutzen als "Transport Service User" sämtliche XTAM-Dienste für die Funktionsschichten 4, 3 und 2. Andere Programme wiederum greifen unter Umgehung des EHKP4-Protokolls als "Network Service User" direkt auf die Funktionsschichten 3 und 2 zu. Das gilt beispielsweise für Dialog- und RJE-Programme, die mit einem passenden SNA-Protokollüberbau wie Datex-P mit IBM-Systemen kommunizieren.

Optimierte Datenstrukturen

Ein kaum zu unterschätzendes Problem in mehrschichtigen Kommunikationssystemen mit ISO-Architektur stellt das Kopieren von Daten zum Einfügen der Protokollheader dar. Bei einer ungeschickten Wahl der Datenstrukturen und der Pufferorganisation kann man relativ viel CPU-Zeit für unnütze Dinge wie das Hin- und Herschaufeln von Daten zwischen den verschiedenen Funktionsschichten "verbraten". In XTAM wird das Problem unmittelbar an der Benutzerschnittstelle gelöst: Im Verlaufe des ohnehin erforderlichen Kopiervorgangs über die Partitionsgrenze hinweg fragmentiert die Benutzerschnittstellensteuerung die Daten in einer Form, daß die einzelnen Funktionsschichten ihre Protokollheader direkt einfügen können, ohne daß ein weiteres Kopieren der Nutzdaten bis zum Erreichen der Kanalschnittstelle erforderlich ist.

Ebenso erreichen Empfangsdaten Benutzerschnittstelle in fragmentierter Form. Erst beim Kopieren in den Datenbereich des Benutzerprogramms reassembliert XTAM die einzelnen Datenblöcke in einen zusammenhängenden Nutzdatenpfuffer.

Viele gängige TP-Zugriffsmethoden sind nur mit Hilfe einer relativ aufwendigen Generierung an die jeweilige Systemkonfiguration anzupassen. Hierzu muß man eine Source mit Generierungsmakros erstellen, assemblieren, binden und in einer Bibliothek katalogisieren. Das Assemblieren und Binden ist in den meisten Fällen recht zeitaufwendig und kann 20 Minuten und länger dauern. Da ein Systemprogrammierer diesen Prozeß unter Umständen mehrfach wiederholen muß, ist eine TP-Generierung im allgemeinen deine langwierige und nervenaufreibende Angelegenheit. Anders bei XTAM: Um dem Anwender die Generierung zu erleichtern, existiert eine Initialisierungsroutine, die die Generierungsanweisungen aus einer Source-Datei liest. Anhand dieser Anweisungen erzeugt diese Routine in der Hochlaufphase alle für die gewünschte Konfiguration benötigten Tabellen und Pufferbereiche. Die XTAM-Initialisierung ist in weniger als 30 Sekunden abgeschlossen. Bei Bedarf kann sie auch ohne das Starten von XTAM ablaufen, um eine neu erstellte Generierung zu überprüfen. Nach Abschluß eines solchen "Probelaufs" erhält der Anwender eine Übersicht über den benötigten Speicherplatz, so daß sich komplizierte Speicherberechnungen erübrigen.

Speicherbedarf variiert stark

Der von XTAM benötigte Speicherplatz ist unterteilt in Programmund Tabellenspeicher. Der Programmspeicher belegt unabhängig von der individuellen Konfiguration 84 KB. Der für die Datenbereiche, Tabellen und Puffer benötigte Speicher hängt sehr stark vor der jeweiligen Konfiguration ab. Eine Durchschnittskonfiguration mit einem Datex-P-Anschluß und mehreren virtuellen Verbindungen, über die zwei Benutzerprogramme mit verschiedenen dezentralen Partnern kommunizieren, benötigt rund 50 KB Speicherplatz für die Steuertabellen und Datenpuffer. Damit liegt der gesamte Speicherbedarf für eine solche Konfiguration bei etwa 134 KB.