Von Richard Spreitzenbarth, Chefberater in der Geschäftsstelle Bildschirmtext der Danet GmbH, Darmstadt

Desigen hat bei Btx zwei Bedeutungen, zum einen, wie der Benutzer die Btx-Anwendung visuell sieht, und zum anderen das EDV-Design in der Anwendung. Der folgende Beitrag betrachtet einige Designgesichtspunkte für Btx-Anwendungen mit der IBM Btx-Software. Dabei wird besonders auf Performanceauswirkungen eingegangen.

Die Btx-Software nimmt Anfragen vom Btx-Terminal entgegen; leitet sie an das zugehörige Anwendungsprogramm weiter und sendet die vom Anwendungsprogramm bereitgestellten Informationen an das Btx-Terminal zurück.

Die Anwendungsprogramme bekommen die Kontrolle in einem Anwendungsexit (ASI); wo sie entscheiden können, ob die Anfrage zur Bearbeitung an eine Subsystemanwendung (IMS- oder CICS-Anwendung) weitergereicht werden soll (Abb. 1).

Subsystemanwendungen laufen, wenn sie ohne Benutzererweiterungen konzipiert sind, vollständig im Subsystem (IMS, CICS) ab. Das Anwendungs-Steuerungs-Programm in ASI dient nur zum Durchreichen der Nachricht vom/zum Subsystem.

Bei den für Btx-Anwendungen in Betracht zu ziehenden Designalternativen liegt wohl das größte Performancepotential in der Verringerung der Subsystembelastung.

Gründe für eine Entlastung des Subsystems sind neben individuellen Erfordernissen:

- die Antwortzeiten für den Btx-Teilnehmer zu verkürzen

- die Hochbelastung zu reduzieren

- Performance-Engpässe im Subsystem zu vermeiden.

Performance-Engpässe sind verstärkt zu befürchten, weil die Benutzerhäufigkeit durch das unplanbare Informationsbedürfnis des Btx-Teilnehmers gesteuert wird.

Die Subsystementlastung kann sich in verschiedenen Bereichen vollziehen; zwei wichtige Bereiche sind:

- Benutzerführung und

- verteilte Anwendungen

Bei einer richtigen Gestaltung der Benutzerführung werden im Zuge der Erhöhung der Bedienerfreundlichkeit meistens auch die Dialoge gestrafft. Die Straffung der Dialoge bedeutet gleichzeitig eine Verringerung der Subsystembelastung.

Dialoge lassen sich durch Vermeiden

- feldweiser Datensammlung und

- über Datensammlung simulierte Auswahlseiten

straffen, was weniger Datenübertragung und geringere Systembelastung zur Folge hat.

Verteilte Anwendungen sind eine neue Klasse von Anwendungen.

Sie vollziehen auf Anwendungsebene einen DB/DC-Split und belasten das Subsystem nur für die notwendigen DB-Zugriffe Die Entlastungen für das Subsystem zeigen sich im Wesentlichen in niedrigeren Transaktionsraten und geringem Ressourcenbedarf.

Verteilte Anwendungen sind Anwendungen, die nicht ausschließlich im Subsystem, sondern bei Anwendungsteilen oder Teilfunktionen in ASI, also von der Schnittstelle zum Subsystem, ablaufen.

Dieser Sachverhalt ist in einem Beispiel eines Fehlerdialoges über drei Schritte (Seiten) dargestellt. Die im Bildschirmbild (Seite) B1 fehlerhaft erfaßten Daten müssen in B2 und B3 korrigiert werden (Abb. 2).

Anwendungsfunktionen in der Anwendungsschnittstelle (ASI):

- Hier können alle Anwendungsdialoge ablaufen, welche keine IMS-DB-Zugriffe benötigen (zum Beispiel Formalprüfungen der Eingabefelder, Vorinitialisieren der Erfassungsmasken,

- Teile der Dialogsteuerung (zum Beispiel Transaktionsauswahl, Menüs, Sessionsgedächtnis)

- Dialogprotokollierung (Btx-Vorgangs-Protokollierung)

- L20/24-Routinen

Anwendungsfunktionen im Subsystem:

Hier müssen alle Funktionen durchgeführt werden, die aktuelle Datenbankdaten benötigen (Kontostandsabfrage etc.).

Performance-Engpässe im Subsystem können durch Auslagerung von Funktionen, welche keine Datenbankzugriffe benötigen (oder wo auf die Datenbankunterstützung verzichtet werden kann), vor der Schnittstelle zum Subsystem behoben werden (logischer Vorrechner in der Anwendungsschnittstelle-1).

Wächst das Transaktionsaufkommen so stark, daß dies zu Kapazitätsengpässen führt, so bietet ein physischer Vorrechner die Möglichkeit, den IMS-Host zu entlasten.

Die Verlagerung dessen, was bisher als logischer Btx-Vorrechner lief, auf einen physischen Vorrechner, ist auf der Softwareseite einfach durch SNA-Cross-Domain-Generierungsanweisungen zu lösen. Die Anwendungen bleiben davon unberührt. Der physische Vorrechner kann dabei zum Beispiel eine vorhandene Back- up Maschine oder eine beigestellte 43xx sein.

Eine konsequente Weiterführung dieses Weges ist das Übernehmen weiterer Anwendungen aus dem Host und das Installieren mehrerer, eventuell dezentraler Vorrechner.