Ein Asynchron-Vorgang beginnt mit einem Asynchron-Teilprogramm. Diesem Teilprogramm wurde bei der Generierung ein Transaktionscode mit TYPE=A (asynchronous) zugeordnet. Ein Asynchron-Teilprogramm unterscheidet sich von einem Dialog-Teilprogramm nicht nur durch den Typ des Transaktionscodes, sondern ist auch anders aufgebaut.
Aufbau eines Asynchron-Teilprogramms
Asynchron-Programme müssen weder eine Eingabenachricht lesen noch eine Ausgabenachricht erzeugen. Nach dem INIT kann im ersten Teilprogramm des ersten Verarbeitungsschritts ein FGET-Aufruf folgen, mit dem die Asynchron-Nachricht des Erzeugers des Hintergrund-Auftrags gelesen werden kann. Das kann sein:
eine vollständige Nachricht
oder eine Teilnachricht
oder eine leere Nachricht, falls der Auftrag nur aus einem TAC besteht (z.B. über eine Funktionstaste des Terminals erzeugt).
Danach können - mit Ausnahme von MGET - beliebige KDCS-Aufrufe folgen. Ein MGET-Aufruf ist jedoch in einem Folge-Teilprogramm oder Folge-Verarbeitungsschritt erlaubt.
Es ist nicht möglich, mit MPUT eine Antwort an den Kommunikationspartner, von dem die Asynchron-Nachricht gesendet wurde, zu senden. Da der Vorgang entkoppelt vom Partner abläuft, ist der Partner zum Zeitpunkt der Bearbeitung u.U. gar nicht mehr mit der Anwendung verbunden. Dem Partner kann jedoch mit FPUT oder DPUT eine Nachricht gesendet werden, die dann in die dem Partner zugeordnete Message Queue eingetragen wird. Ein MPUT-Aufruf ist nur erlaubt, wenn die Nachricht an ein Folge-Teilprogramm oder an einen Auftragnehmer-Vorgang gerichtet ist.
Letzter UTM-Aufruf in Ihrem Teilprogramm muss ein PEND sein, wie im Abschnitt „Programmrahmen" beschrieben. Ein Asynchron-Programm wird im Standardfall mit einem PEND FI-Aufruf beendet. Damit ist auch der Vorgang beendet. openUTM übermittelt evtl. zu sendende Nachrichten dem oder den Partnern.
Weitere PEND-Varianten sind möglich, z.B. PEND PA/PR/SP zur Teilprogrammkettung, und PEND KP und RE für verteilte Verarbeitung. Auch die Aufrufe PGWT KP, CM und PR können Sie in einem Asynchron-Teilprogramm nutzen, z.B. PGWT KP, wenn Sie bei verteilter Verarbeitung nur den Verarbeitungsschritt, nicht aber Teilprogramm und Transaktion beenden wollen.
Ein Asynchron-Vorgang kann in mehrere Teilprogrammläufe, und - bei verteilter Verarbeitung - auch in mehrere Verarbeitungsschritte gegliedert werden (siehe "Asynchron-Vorgang aus mehreren Teilprogrammen" bzw. "Asynchron-Vorgänge, die ihrerseits Aufträge absetzen").
Bild: Aufbau eines Asynchron-Teilprogramms
Kombiniertes Dialog- und Asynchron-Programm
Einem Teilprogramm können mehrere Transaktionscodes zugeordnet werden. Dabei ist es auch möglich, dem Teilprogramm sowohl einen Dialog-TAC als auch einen Asynchron-TAC zuzuordnen. Das Programm kann also im Dialog oder asynchron gestartet werden. openUTM zeigt dies nach Vorgangs-Start im Feld KCPRIND des KB-Kopfes an: "A" für asynchron, "D" für Dialog. Das Teilprogramm kann dieses Feld auswerten und entsprechend verzweigen.
Bild: Dialog- und Asynchron-Verarbeitung in einem Programm
Wird das im Bild dargestellte Programm mit TACD gestartet, wird nach dem PEND der FPUT ausgeführt, wodurch das gleiche Teilprogramm noch einmal gestartet wird, um einen unabhängigen 2. Vorgang zu bearbeiten. Für ein Dialog-Programm bedeutet die Auslagerung eines Asynchron-Vorgangs u.U. bessere Antwortzeiten für den Dialog mit dem Client.
Asynchron-Vorgang aus mehreren Teilprogrammen
Ein Asynchron-Vorgang kann in mehrere Teilprogramme und Transaktionen gegliedert sein. Das letzte Teilprogramm wird mit PEND FI abgeschlossen. In den vorhergehenden Teilprogrammen sind die PEND-Varianten SP oder PA/PR möglich.
PEND-Varianten, die einen Verarbeitungsschritt beenden, wie PEND KP oder PEND RE, sind innerhalb eines Asynchron-Vorgangs nur bei verteilter Verarbeitung möglich (vgl. das Bild auf der folgenden Seite).
Bild: Struktur eines in drei Teilprogramme gegliederten Asynchron-Vorgangs
Im dargestellten Beispiel wird von einem Terminal aus ein Hintergrund-Auftrag an einen Asynchron-Vorgang der eigenen Anwendung gestellt. Hierzu wird am Terminal der Transaktionscode dieses Vorgangs und ggf. eine Nachricht eingegeben. openUTM reiht den Auftrag automatisch in die entsprechende Queue ein und startet den Asynchron-Vorgang entkoppelt vom Auftraggeber, sobald die notwendigen Betriebsmittel zur Verfügung stehen. Das erste Teilprogramm liest die Daten mit FGET ein und schließt mit PEND SP. Es wird ein Sicherungspunkt gesetzt und das in KCRN angegebene Folge-Teilprogramm gestartet.
Das Programm TAC1 hat keinen MPUT an das Programm TAC2 übermittelt, Informationen können jedoch in den Vorgangs-spezifischen Speicherbereichen weitergereicht werden. Das Programm TAC2 wählt für die Weitergabe von Informationen an TAC3 einen MPUT-Aufruf und beendet sich mit PEND PA. Es wird also kein Sicherungspunkt gesetzt. Im Programm TAC3 wird der Vorgang mit PEND FI beendet.
Asynchron-Vorgänge, die ihrerseits Aufträge absetzen
Während eines Asynchron-Vorgangs können wiederum Asynchron-Aufträge erzeugt werden. Dies können Ausgabe-Aufträge oder weitere Hintergrund-Aufträge sein. Bei verteilter Verarbeitung können aus einem Asynchron-Vorgang auch Dialog-Aufträge an Partner-Anwendungen gestellt werden, d.h. der Asynchron-Vorgang kommuniziert mit fernen Dialog-Vorgängen.
Bild: Asynchron-Vorgänge, die ihrerseits Aufträge absetzen
Im ersten Teilprogramm des Asynchron-Vorgangs TAC 1 wird ein Auftrag an den Asynchron-Vorgang TAC2 abgesetzt. Hierzu muss beim FPUT im Feld KCRN der Transaktionscode TAC2 angegeben werden. Da das Teilprogramm mit einem Sicherungspunkt endet, wird der Auftrag bereits zum Ende des Teilprogramms in die entsprechende Queue eingereiht.
Auch im Vorgang TAC2 wird im ersten Teilprogramm ein Asynchron-Auftrag abgesetzt, ein Ausgabe-Auftrag an den Drucker. Beim FPUT muss hierfür das Feld KCRN mit dem LTERM-Namen des Druckers versorgt werden. Da das Teilprogramm nicht mit einem Sicherungspunkt endet, wird der Auftrag erst zum Vorgangsende (nächster Sicherungspunkt) in die Queue des LTERMs eingereiht.
Der Vorgang TAC 2 ist in zwei Verarbeitungsschritte gegliedert. Das erste Teilprogramm sendet mit MPUT eine Nachricht an einen fernen Dialog-Vorgang. Das zweite Teilprogramm wird gestartet, wenn die Antwort vom fernen Vorgang eintrifft. Diese wird mit MGET gelesen.
Auftrags-Komplexe
Zusammen mit dem eigentlichen Asynchron-Auftrag ("Basisauftrag") können bis zu zwei Quittungsaufträge formuliert werden, die an das positive bzw. negative Ergebnis der Auftragsdurchführung gebunden sind. Sie werden ausgeführt, wenn der Basisauftrag abgewickelt ist. Mit den Quittungsaufträgen hat der Auftraggeber die Möglichkeit, auf ein positives oder negatives Auftragsergebnis zu reagieren. Ein Quittungsauftrag, der nicht zur Wirkung kommt - z.B. der negative Quittungsauftrag bei einem positiven Ergebnis - verfällt. Basisauftrag und Quittungsaufträge werden zusammen als Auftrags-Komplex bezeichnet.
Die folgende Tabelle zeigt einige exemplarische Ereignisse bei der Asynchron-Verarbeitung und die Wirkung dieser Ereignisse auf die Quittungsaufträge.
Beginn und Ende eines Auftrags-Komplexes legt man jeweils mit einem eigenen KDCS-Aufruf fest, dem Aufruf MCOM BC (begin of complex) und MCOM EC (end of complex). Beim MCOM BC-Aufruf definieren Sie die Komplex-Identifikation (Komplex-Id), das Ziel des Asynchron-Auftrags sowie die TACs der Asynchron-Programme, welche die positive bzw. negative Quittung bearbeiten sollen. Alle im Komplex erzeugten Aufträge werden mit DPUT-Aufrufen beschrieben, wobei als Ziel die Komplex-ID angegeben werden muss.
Ein Auftrags-Komplex kann sowohl in Dialog- als auch in Asynchron-Programmen definiert werden.
Ist der Basisauftrag eines Auftrags-Komplexes an einen fernen Asynchron-Vorgang gerichtet, dann muss die Vorgangs-Id vor Beginn des Auftrags-Komplexes vergeben werden (per APRO AM). Bei MCOM BC gibt man in KCRN die Vorgangs-Id an; die Quittungsaufträge müssen von der lokalen Anwendung bearbeitet werden.
Ereignis | Wirkung auf Quittungsauftrag |
|---|---|
PEND FI im lokalen Asynchron-Vorgang | Start positiver Quittungsauftrag und Löschen negativer Quittungsauftrag |
erfolgreiche Übertragung bei Hintergrund-Auftrag an fernen Asynchron-Vorgang | |
positive Abdruckquittung vom Drucker oder von der Druckadministration | |
Verarbeitung einer Nachricht einer TAC-Queue und Abschluss der Transaktion | |
PEND ER/FR im lokalen Asynchron-Vorgang ohne Redelivery | Start negativer Quittungsauftrag und Löschen positiver Quittungsauftrag |
Fehler beim Aufbereiten der Ausgabenachricht durch VTSU-B auf BS2000-Systemen | |
Fehler bei Formatierung der Ausgabenachricht auf BS2000-Systemen | |
Verarbeitung einer Nachricht einer TAC-Queue und Rücksetzen der Transaktion ohne Redelivery | |
Zurückweisung des Auftrags bei Hintergrund-Auftrag an fernen Asynchron-Vorgang | |
Löschen eines Auftrags per Administration | |
Löschen des Ausgabeauftrags beim Verbindungsauf- oder Verbindungsabbau eines RESTART=NO Client. | |
PEND ER/FR im lokalen Asynchron-Vorgang mit Redelivery | ohne Wirkung, da der Basisauftrag noch erhalten bleibt |
negative Abdruckquittung vom Drucker oder Zeitüberschreitung beim Warten auf eine Quittung | |
Reihenfolge der Aufträge wird per Administration geändert | |
Wiederholung eines Druckauftrags | |
Verarbeitung einer Nachricht einer TAC-Queue und Rücksetzen der Transaktion mit Redelivery | |
Löschen eines Auftrags mit Quittungsaufträgen per Druckadministration | Quittungsaufträge werden gelöscht; Protokollierung auf SYSLOG |
KDCUPD übernimmt einen Auftrag nicht | Quittungsaufträge werden auch nicht übernommen (siehe KDCUPD-Protokoll) |
Das folgende Bild veranschaulicht einen Auftrags-Komplex am Beispiel eines Druckauftrags.
Bild: Auftrags-Komplex für einen Druckauftrag