Transaktionsmonitore sind auf Großrechnern recht weit verbreitet. Realisiert werden damit, überwiegend für administrative Aufgaben, die unterschiedlichsten Anwendungen, wie etwa Buchungs-, Auskunfts-, Lagerhaltungssysteme, etc. Diese Anwendungen werden auf Rechnern mit CPU-Leistungen von zirka 1 Mops bis hin zu den leistungsstärksten Rechnern eingesetzt. Derzeit liegt die Leistung von Rechnern mit dem Betriebssystem Unix (1) bei etwa 1 bis 10 Mops. Solche Systeme werden daher immer häufiger als Filial- oder Abteilungsrechner mit Mainframe-ähnlichen Anwendungen eingesetzt. Somit entsteht die Anforderung nach einem Transaktionsmonitor auf Unix-Systemen.

Transaktionsanwendungen weisen einige typische Merkmale auf:

* Die Anwendungen werden von vielen Datenstationsbenutzern gemeinsam und gleichzeitig benutzt. Der Datenstationsbenutzer ist ein Sachbearbeiter im Unternehmen und in der Regel kein DV-Fachmann. Er kennt nur die Dialoge seiner Anwendung, die normalerweise über Bildschirmmasken beziehungsweise -formulare geführt werden. In der Anwendung ist eine fest vorgegebene Menge von Funktionen verfügbar, die vom Betreiber der Anwendung (Anwender) mit einem vorgegebenen Bestand von Programmen abgewickelt werden. Diese werden nicht von den Datenstationsbenutzern, sondern von den Programmierern des Anwenders (Anwendungsprogrammierer) erstellt und gewartet. Der Programmbestand ist in der Regel relativ stabil. Er ändert sich nur dann, wenn ein neues Verfahren eingeführt wird, für dessen Bedienung die Datenstationsbenutzer gesondert ausgebildet werden müssen.

* In den Anwendungsprogrammen soll nur die Abwicklung der Verfahren codiert sein, sie sollen keine Besonderheiten der Konfiguration beinhalten, in der sie ablaufen. Die Beschreibung der Anwendungskonfiguration wird statisch festgelegt (generiert) und im laufenden Betrieb durch administrative Maßnahmen den augenblicklichen Gegebenheiten dynamisch angepaßt.

Die Anwendungskonfiguration wird vom Anwendungsgenerierer festgelegt, der auch die einzelnen von den Programmierern erstellten Programme (Teilprogramme) zu einem Anwendungsprogramm zusammenfaßt.

Anforderungen an Transaktionssysteme

Die DV-technischen Betriebsmittel einer Anwendung (Datenbanken, Dateien, Prozesse, Speicherbereiche, Geräte, . . .) werden von allen Datenstationsbenutzern gemeinsam benutzt und sind deshalb nicht diesen, sondern der Anwendung zugeordnet. Der Datenstationsbenutzer hat an diesen Betriebsmitteln nur einen Anteil, er ist Teilhaber der Anwendung (Teilhaberanwendung).

Aufgrund des oben skizzierten Anwendungsbereichs werden an Transaktionssysteme eine Reihe von Anforderungen gestellt:

* Die Antwortzeiten an den Dialogstationen sollen kurz (Sekundenbereich) sein.

* Der Transaktionsmonitor soll unterschiedliche Dialogprofile gleich gut unterstützen.

* Da die meisten Transaktionsanwendungen für die Anwender extrem wichtige Daten bearbeiten, wäre der Verlust oder die Inkonsistenz von Daten von erheblichem Schaden. Deshalb soll der Transaktionsmonitor Transaktionen mit den ACID-Eigenschaften bilden können. Dabei steht ACID für A = Atomicitiy, C=Consistency, I=Isolation und D=Durability. Die vier Eigenschaften bedeuten

Atomicity: Die Veränderung aller in der Transaktion relevanten Daten ist atomar, das heißt, es werden entweder alle Änderungen gemeinsam oder keine einzige Änderung durchgeführt (auch "Alles-oder-Nichts-Regel" genannt).

Consistency: Der globale Datenbestand der Anwendung, den mehrere Teilhaber simultan bearbeiten, soll ständig in einem in sich logisch konsistenten Zustand sein.

Isolation: Die Veränderungen am globalen Datenbestand, die in einer noch nicht abgeschlossenen Transaktion vorgenommen werden, dürfen nur in diesen, nicht aber in anderen gleichzeitig existierenden Transaktionen sichtbar sein. Erst nach erfolgreichem Ende der Transaktion werden die von ihr vorgenommenen Veränderungen am globalen Datenbestand für andere Transaktionen sichtbar.

Durability: Die mit dem Ende einer Transaktion vorgenommenen Datenänderungen sind unwiderruflich und dauerhaft, ganz gleich, ob anschließend das System gestört wird (durch Hard- oder Softwarefehler).

* Die vom Transaktionsmonitor verwalteten Daten und die mit Hilfe eines DB-Systems verwalteten Datenbanken sollen eine gemeinsame Transaktion (DB/DC-Transaktion) mit den oben genannten ACID-Eigenschaften bilden.

* Die Bearbeitung eines Verfahrens (Verwaltungsvorgangs) durch den Sachbearbeiter besteht aus einem oder einer Folge von Dialogschritten, die eine oder mehrere Transaktionen bilden. Der Vorgang muß, wenn er einmal begonnen wurde, auch ordnungsgemäß zu Ende geführt werden. Treten in der Bearbeitung eines solchen Vorgangs Störungen auf (Systemabsturz, Verlust der Verbindung zwischen Dialogstation und Anwendung), so soll der Transaktionsmonitor den Vorgang wieder an der unterbrochenen Stelle fortsetzen, sobald sich der Sachbearbeiter erneut bei der Anwendung bekannt gemacht hat. Dazu muß der Transaktionsmonitor den Verarbeitungsstand des Vorgangs wiederherstellen (Vorgangswiederanlauf) und dem Datenstationsbenutzer den vor der Störung gezeigten Bildschirm anzeigen (Bildschirmwiederanlauf).

* Die Anwendung soll ständig (oft im 24-Stunden-Betrieb) und nach Totalausfällen sofort verfügbar sein (kurze Wiederanlaufzeiten). Teilausfälle wie Verbindungsverlust oder Fehler in Anwendungsprogrammen sollen in ihren Auswirkungen begrenzt bleiben. Fehlerhafte Programme sollen im Anwendungslauf ausgetauscht werden können.

* Die Programme sollen einfach programmierbar und von der Konfiguration unabhängig sein. Die Verwaltung der Betriebsmittel (wie Prozesse) soll vom Transaktionsmonitor vorgenommen werden. Der Dialog mit dem Datenstationsbenutzer wird über Bildschirmmasken geführt und soll leicht programmierbar sein.

Für Siemens wurden die Forderungen nach einem Transaktionsmonitor unter Sinix mit der Ankündigung der Sinix-Rechner MX300 und (insbesondere) MX500 größer. Es stellte sich die Frage, wie ein Monitor möglichst schnell und kostengünstig beschafft werden konnte. Es boten sich grundsätzlich drei Alternativen an: Einkauf von Fremdsoftware, Neuentwicklung oder Portierung des im BS2000 vorhandenen Monitors UTM.

Die erste Möglichkeit schied aus, da kein geeigneter Monitor am Markt verfügbar war.

Bei Neuentwicklung eines Monitors sind die Schnittstellen für die Programmierung, Generierung und Administration festzulegen. Für die Schnittstellen eines Transaktionsmonitors gibt es derzeit keine internationalen Normen, einzige Norm ist DIN 66265 (KDCS). Die weiteste Verbreitung haben derzeit die CICS- und IMS/DC-Schnittstellen, wobei die IMS/DC-Schnittstelle bezüglich Recovery und Restart unterbrochener Programmläufe Vorteile gegenüber der CICS-Schnittstelle bietet. Da die Schnittstelle von UTM im BS2000 als Untermenge DIN 66265 enthält und konzeptionell der IMS/DC-Schnittstelle entspricht, wäre bei einer Neukonzeption wohl wieder eine Schnittstelle entstanden, die der von UTM im BS2000 entspricht. So stellte sich die Frage, ob UTM aus dem BS2000 in das Sinix-System portiert werden kann.

Portierung von UTM aus dem BS2000

Damit eine Portierung überhaupt technisch möglich ist, mußten eine Reihe von Voraussetzungen erfüllt sein oder geschaffen werden:

* Das Taskkonzept von Anwendungen im BS2000 mußte auf ein gutes Prozeßkonzept für Anwendungen in Sinix abgebildet werden. Dabei war zu berücksichtigen, daß die MX500 mit einer beachtlichen Anzahl paralleler Prozessoren arbeitet, die möglichst optimal von einer Anwendung ausgelastet werden sollten.

* Die von UTM(BS2000) benötigten Betriebssystemfunktionen und die Dienste des Transportsystems mußten auf Sinix-System- beziehungsweise Bibliotheksfunktionen abgebildet oder im Rahmen des Portierungsprojekts nachgebildet werden.

* Im Monitor mußten die vom Betriebssystem abhängigen und die unabhängigen Teile separierbar sein, und die unabhängigen Teile müssen die überwiegende Codemenge enthalten, damit eine Portierung sinnvoll ist. Beide Voraussetzungen waren bereits mit UTM(BS2000) V3.0 erfüllt.

* Der vom Betriebssystem unabhängige Teil in UTM(BS2000) V3.0 ist bis auf wenige Ausnahmen in der Systemimplementierungssprache SPL4 (ähnlich PLI) codiert und konnte mit Hilfe eines speziell geschaffenen Werkzeugs (SPL4/C-Konverter) maschinell in C umgesetzt werden.

* Das in UTM(BS2000) integrierte Formatierungssystem FHS konnte nicht portiert werden, da es vollständig in Assembler codiert ist, und da die Sinix-Datenstationen mit anderen Datenströmen wie die Transdata-Terminals bedient werden. Anstelle von FHS wurde das Sinix-Formatierungssystem "Formant" verwendet, das um die Forderungen von UTM erweitert wurde. Der Anwendungsprogrammierer sieht so die identische Nachrichtenschnittstelle wie im BS2000 mit Transdata-Terminals. Außerdem wurde ein Baustein entwickelt, der eine FHS-Formatdefinition in eine FORMANT-Formatdefinition umsetzt.

Im Laufe des Entwicklungsvorhabens wurde so der Portierungsweg eröffnet, der dann erstmals für die Portierung von UTM V3.0 aus dem BS2000 nach Sinix benutzt wurde. Die funktionelle Weiterentwicklung des Monitors erfolgt weiterhin im BS2000, und jede neue UTM-Version wird dann über den Portierungsweg auf Sinix gebracht. Der von SPL4 nach C konvertierte C-Code dient lediglich als eine Art Metacode, der auch zur Fehlerdiagnose verwendet werden kann.

Systemeinbettung von UTM(Sinix)

Eine UTM(Sinix)-Anwendung ist ab Sinix V5.0 im att-universe ablauffähig, da die SYSTEM-V-Funktionen Shared-Memory-Segmente und Semaphore benutzt werden. Es besteht außerdem eine technische Kopplung zu FORMANT V2.1B. Das Prozeßkonzept für UTM(Sinix)-Anwendungen wird in der Abbildung skizziert.

Die Anwendung wird durch Erzeugen des Prozesses "utm-main" gestartet und eingerichtet. Utm-main erzeugt so viele Work-Prozesse der Anwendung, wie bei der Generierung beziehungsweise in den Startparametern für "utm-work" angegeben wurde. In den Work-Prozessen kommt das Anwendungsprogramm, bestehend aus den Anwendungsteilprogrammen zum Ablauf. Jeder Work-Prozeß kann jede Funktion der Anwendung ausfahren. In allen Work-Prozessen läuft das gleiche Anwendungsprogramm ab, das heißt, die Anwendung wird von einer Menge homogener Work-Prozesse bedient. Dadurch werden alle Teilprogramme der Anwendung automatisch sharable genutzt.

Für die Work-Prozesse existiert ein gemeinsamer Wartepunkt (realisiert mit Hilfe eines Semaphors), an dem ein Prozeß wartet, falls kein Auftrag für die Anwendung vorliegt.

Die Geräte (Dialogstationen, Drucker, später auch die Transportverbindungen) werden über die sogenannten externen Prozesse bedient. Dabei gibt es jeweils eine Gruppe homogener Prozesse für die Dialogstationen (Dialogterminalprozesse) und für die Drucker (Printer-Prozesse). Ein Dialogterminalprozeß wird entweder von der Dialogstation explizit gestartet oder über die Login-Shell nach erfolgreichem Anmelden an das Sinix-Betriebssystem. Der Dialogterminalprozeß stellt dann die Verbindung zur Anwendung her, wobei für die Prozeßkommunikation ein Shared-Memory-Segment zum Datenaustausch und Semaphore als Wartepunkte benutzt werden. Ein Dialogterminalprozeß nimmt einen Auftrag von der Dialogstation entgegen (zum Beispiel ein ausgefülltes Formular) und trägt ihn im Shared-Memory-Segment in eine Auftragswarteschlange ein. Falls ein Work-Prozeß auf Aufträge wartet, wird er vom Dialogterminalprozeß geweckt.

Nachdem der Dialogterminalprozeß den Auftrag im Shared-Memory-Segment hinterlegt hat, wartet er an seinem Wartepunkt auf die zugehörige Antwort. Ein Work-Prozeß, der den Auftrag entgegengenommen hat, analysiert und bearbeitet ihn vollständig. Die Auftragsbearbeitung wird mit einer Ergebnisnachricht (Antwort) an den auftraggebenden Dialogterminalprozeß beendet. Der Work-Prozeß hinterlegt die Antwort im Shared-Memory-Segment, weckt den wartenden Dialogterminalprozeß und nimmt (falls vorhanden) einen weiteren Auftrag aus der Auftragswarteschlange, anderenfalls setzt er sich selbst wieder wartend. Der vom Work-Prozeß geweckte Dialogterminalprozeß nimmt die für ihn vorgesehene Antwort aus dem Shared-Memory-Segment und gibt sie auf dem Bildschirm aus.

Ein Printer-Prozeß wird bei Bedarf von "utm-main" eingerichtet und wartet immer an seinem Wartepunkt auf freilaufende Nachrichten für die ihm zugeordnete Druckergruppe.

Das portierte Produkt bietet dem Anwender in Sinix nahezu die identischen Schnittstellen wie im BS2000 für die Generierung, Administration und Programmierung der Anwendung. Die Programmschnittstellen beschreiben neben einer Reihe von Funktionsaufrufen Konzepte für eine Programm- und Programmlaufverwaltung. Dem Programmierer stehen Funktionsaufrufe zur Verfügung für die Funktionskomplexe:

* Programmlaufverwaltung zur dynamischen Konfigurierung von Programmläufen,

* Transaktionssteuerung zur Sicherung und zum Rücksetzen transaktionsgesicherter Daten, die vom Monitor und von einem angeschlossenen Datenbanksystem verwaltet werden. Recovery- und Wiederanlauffunktionen werden vom Monitor übernommen, ohne daß der Programmierer dies zu berücksichtigen hat.

* Dialogsteuerung auf Basis einer virtuellen Terminalschnittstelle im formatierten beziehungsweise unformatierten Betrieb. Beim Wiederanlauf unterbrochener Dialoge wird vom Monitor ein Bildschirmwiederanlauf durchgeführt, so daß der Verarbeitungsstand der wiederaufgesetzten Programmläufe der Darstellung am Bildschirm entspricht.

* Transaktionsgesicherte Auftrags- und Nachrichtenverwaltung für Ausgaben auf Druckern oder zum Starten von Programmläufen, die batchähnlich vom Dialog entkoppelt ablaufen. Die Auftragsverwaltung erfolgt prioritäts- und zeitgesteuert mit relativen oder absoluten Zeitangaben.

* Transaktionsgesicherte Datenbereiche mit unterschiedlichen Eigentumsrechten und Lebensdauern.

* Transaktionsgesicherte Loggingfunktion für die Anwendungsprogramme.

Die erste Version des portierten Produkts hat noch einige funktionelle Einschränkungen gegenüber dem Produkt UTM(BS2000) Version 3.0, aus dem es abgeleitet wurde, die in den Folgeversionen von UTM(Sinix) beseitigt werden.

Ausblick auf künftige Entwicklungen

Die Folgeversion UTM(Sinix) V 1.1 hat als Schwerpunkt die Kommunikation mit anderen Anwendungen insbesondere über UTM-D. Zunächst soll die Kopplung zwischen Sinix-Anwendungen und BS2000-Anwendungen sowie die Kopplung von Sinix-Anwendungen untereinander realisiert werden. In einer weiteren Version sollen dann auch CICS- und IMS-Anwendungen einbezogen werden. Es können dann Sinix-Anwendungen mit Sinix-, BS2000-, CICS- oder IMS-Anwendungen transaktionsgesicherte Kommunikation betreiben.