Die massive Ausweitung der Online-Transaktionsverarbeitung (OLTP) betrifft praktisch alle Bereiche der kommerziellen DV. Ohne den Transaction-Processing-Monitor (TP-Monitor) als Plattform für alle Dialogfunktionen geht zumindest im Großrechnerbereich nichts. Martin Hahn* schildert, welche Anforderungen erfüllt sein müssen, damit Sicherheit, Integrität, Aktualität und leichte Einsetzbarkeit sichergestellt sind.
Online-Systeme, besonders die mit dem imageträchtigen Zusatz "OLTP" (Online Transaction Processing) haben Konjunktur. Zwar muß es dafür nicht immer ein Mainframe sein, doch fallen typischerweise hier die höchsten Transaktionsvolumina an (30 000 und mehr Transaktionen pro Stunde müssen verkraftet werden). Hier wurden über die Jahre komplexe Terminal/PC-Mainframe-Verbünde aufgebaut, in denen mehrere hundert Benutzer mit wechselnden Anforderungen möglichst rund um die Uhr bedient werden wollten.
In modernen Online-Umgebungen, die auf Datenbanksystemen wie DB2 oder Adabas aufsetzen, spielen TP-Monitore heute eine wichtige Rolle. Die Gewährleistung des Dialogs auch in zeitkritischen Situationen ist die eine Hauptfunktion. Ebenso wichtig ist die Entlastung der Anwendungsentwicklung von umgebungsspezifischen Eigenschaften.
Es reicht nicht aus zu sagen, daß ein TP-Monitor die notwendigen Dialogfunktionen enthält, so daß diese nicht mehr im Anwendungssystem implementiert werden müßten. Der Monitor sollte neben den typischen TP-Funktionen unter anderem Services zum Aufbau von Netzwerken, interaktive Utilities für die Systemkontrolle und umfassende Sicherheitsfunktionen enthalten. So sollte er insbesondere von den Speicherschutzfunktionen der Hardware (Subsystem Storage Protection Feature) vollen Gebrauch machen. Jeder Benutzer kann durch die Zuweisung unterschiedlicher Storage Keys isoliert und von der Hardware kontrolliert werden.
Für ein Anwendungsprogramm ist es dann unmöglich, den Bereich anderer Anwendungen zu ändern oder interne Routinen beziehungsweise Kontrollblöcke des TP-Monitors zu überschreiben. Fehler wie etwa ein Tabellenüberlauf bei Cobol können andere Bereiche nicht tangieren. Funktionen wie Online-Workfiles, Online-Spooling, Unterstützung des Programm-Buffer-Pools und paralleler Aktivitäten oder die dynamische Aufzeichnung von Sessions sollten die Flexibilität der Anwendungen, seien sie in Cobol, PL/1, Assembler oder Natural geschrieben, deutlich erweitern.
Ein TP-Monitor sollte jedoch noch weit über das hinausgehen, was herkömmliche und marktübliche Angebote bieten. Dies betrifft vor allem die Frage, wie die einzelnen Schritte einer logischen Transaktion abgearbeitet werden. Zur Entlastung der Datenbank und des Anwendungsentwicklers, der sich ja eigentlich auf die reine Anwendungslogik konzentrieren sollte, muß eine konversationale Arbeitsweise erwartet werden können.
Der TP-Monitor hält die logischen DB-Transaktionen strikt getrennt von den physikalischen Bildschirmtransaktionen. Leider können heute die meisten TP-Monitore nur diejenigen Arbeitsschritte verwalten, die innerhalb einer einzigen Bildschirmkommunikation definiert werden. Komplexere zusammenhängende Aktivitäten müssen vom Benutzer gesteuert, Zwischenergebnisse in der Datenbank abgespeichert und wieder zurückgeladen werden.
Dies bringt einen enormen Overhead mit sich und zwingt den Entwickler, seine Programmstruktur den technischen Restriktionen anzupassen. Es bleibt zu hoffen, daß dieses schwere Manko der herkömmlichen pseudokonversationalen Arbeitsweise deutlicher in das Bewußtsein der DV-Verantwortliche rückt. Allgemein sollten Verfahren implementiert werden, in denen automatisch alle Arbeitsschritte, die in einer logischen Transaktion notwendig sind, auch über mehrere Terminal-I/Os hinweg verwaltet werden.
Eine weitere Herausforderung besteht darin, daß die Rechnerarchitektur der 90er Jahre durch Mehrprozessorsysteme geprägt ist. Daher sollte bei der Diskussion darauf geachtet werden, daß die in Frage kommenden TP-Monitore solche Systeme von ihrem Design her voll ausnutzen können. Wichtigstes Kriterium hierbei ist, daß der Monitor das Subtasking des Betriebssystems unterstützt, so daß in Mehrprozessor-Konfigurationen mehrere Tasks parallel ablaufen können.
Darüber hinaus müssen noch weitere Aspekte beachtet werden. So sorgen die bereits erwähnten Speicherschutzfunktionen zwar für Sicherheit, Stabilität und Integrität, erschweren aber andererseits die Kommunikation zwischen Programmen oder die gemeinsame Nutzung von Datenbereichen. Dieses Problem ist jedoch dadurch zu lösen, daß ein gemeinsamer Speicherbereich (Common Storage Facility) definiert wird. Hier werden Daten vorrätig gehalten, die laufend benötigt werden. Dadurch lassen sich Daten intern zwischen Programmen austauschen, ohne daß auf ein externes Medium zugegriffen werden muß. So läßt sich der I/O-Overhead weiter reduzieren.
Zu den zentralen Funktionen eines TP-Monitors zählt die automatische Steuerung von Terminal-Netzen bei weitgehender Entlastung der Benutzer. Dies verlangt insbesondere, daß sich das gesamte Netz als einheitliches System darstellt, welches nur ein einziges Mal definiert werden muß und mit minimalem Aufwand geändert werden kann.
Bei herkömmlichen TP-Monitoren müssen alle Komponenten (Terminaltyp und -modell etc.) sowohl in den TP-Tabellen als auch im VTAM (Virtual Terminal Access Method) beschrieben werden. Das bedeutet nicht nur doppelte Arbeit und eine schwerfällige zeitaufwendige Anpassung an neue Konstellationen, sondern auch redundante, möglicherweise divergierende Informationen und damit die Gefahr von Fehlern.
Es sollte daher nur noch eine einzige Instanz für die Beschreibung der Systemperipherie geben, und das sind die VTAM-Netzwerkdefinitionen. Alle für den TP-Monitor erforderlichen Definitionen werden dann beim Aufbau einer Session interpretiert und zur dynamischen Generierung der erforderlichen Kontrollblöcke verwendet.
Hier holt sich der TP-Monitor alle Informationen über die Geräteeigenschaften. Das gilt sowohl für Terminals als auch für Drucker. Soll das System erweitert werden, genügt es, den Namen der neuen Komponente einzugeben. Die Kontrollblockinformationen werden dann dynamisch aus VTAM generiert. Wird umgekehrt ein Terminal entfernt, so muß dies nur dem VTAM-Netzwerk mitgeteilt werden.
Die Fähigkeiten des Druckers voll nutzen
Die automatische Konfiguration für Terminals und Drucker sowie die dynamische Erweiterung von Pufferbereichen bilden die Grundlage für die permanente Verfügbarkeit eines TP-Monitors. Temporäre Spitzenbelastung und kurzfristig erforderliche Erweiterungen (mehr Benutzer) werden somit automatisch von dem System gehandhabt und erfordern keinerlei Neugenerierung durch den Systemverwalter.
Schließlich sollte der Markt der Drucker, insbesondere der Laserprinter, noch etwas genauer ins Auge gefaßt werden. Er zeichnet sich durch raschen Wandel und eine Vielzahl von Innovationen aus.
Die Systemsoftware muß den Benutzer daher in die Lage versetzen, die vielfältigen, individuellen Möglichkeiten dieser Geräte zu nutzen. Hierbei ist zu beachten, daß Anwendungen völlig portabel und damit frei von systemspezifischen Anweisungen bleiben.
Beim Ausdrucken zum Beispiel sollte es möglich sein, den Namen einer Nachbehandlungsroutine (Logical Output Driver) anzugeben, die im Moment des physikalischen Ausdrucks aktiviert wird. Diese kann das Layout des Ausdrucks beeinflussen und vom Druckertyp abhängige Umsetzungen wie zum Beispiel Escape-Sequenzen vornehmen.
Damit lassen sich beispielsweise in Texten Variablen definieren, die über den Driver beim Ausdruck an der entsprechenden Stelle die Einfügung spezieller Grafiken ermöglichen.
In einem Durchgang: Formblatt plus Inhalt
Ebenso können Formblätter definiert werden, die zusammen mit dem jeweils individuellen Inhalt in einem einzigen Arbeitsgang gedruckt werden. Bei Veränderungen des Formulars muß nur der Logical Output Driver angepaßt werden. Die Anwendung selbst bleibt unverändert.
Nur wenn TP-Monitore die hier aufgeführten Leistungsmerkmale erfüllen, werden sie den weiter steigenden Anforderungen an die Online-Verarbeitung gewachsen sein.
Sollte jedoch - um hier noch einmal zwei wesentliche Aspekte aufzugreifen - ihr Design nicht Mehrprozessor-Umgebungen angepaßt werden, oder sollten sie die logische Einheit "Transaktion" weiterhin auf pseudokonversationale Weise zerlegen, wird die Rede von effektivem OLTP ein munterer Dialog jenseits der Realität heutiger DV bleiben.
Der Dialog jedoch, um den es eigentlich gehen sollte, wird in Performance- und Administrationsschwierigkeiten hoffnungslos steckenbleiben.