In den folgenden Abschnitten werden die Regeln genannt, die für verteilte Dialoge über LU6.1 einzuhalten sind. Wenn Sie die im abschließenden Abschnitt genannte "Programmierempfehlungen" beachten, werden die genannten Regeln automatisch eingehalten.
Wirkung der PEND-Aufrufe und Einsatzregeln
Die PEND-Aufrufe in Auftraggeber- und Auftragnehmer-Vorgang steuern die verteilte Transaktion, d.h. sie entscheiden, wann der gemeinsame Sicherungspunkt der beiden Transaktionen gesetzt wird.
Welche PEND-Aufrufe ein Vorgang verwenden darf und welche Wirkung diese haben, ist abhängig von Vorgangs- und Transaktions-Status des Partner-Vorgangs.
In der folgenden Tabelle ist die Wirkung der PEND-Aufrufe im Auftragnehmer- und im Auftraggeber-Vorgang beschrieben sowie die Regeln, die für deren Einsatz gelten:
Variante | Wirkung/Einsatzregeln |
|---|---|
PEND KP
| Es wird kein Sicherungspunkt angefordert und kein Sicherungspunkt gesetzt. Der Vorgang bleibt im Transaktionsstatus "O" und im Vorgangsstatus "O". Eine offene DB-Transaktion bleibt offen. Im Auftraggeber-Vorgang wird das in KCRN angegebene Folge-Teilprogramm gestartet, sobald alle Ergebnisse von den Auftragnehmer-Vorgängen eingetroffen sind. Zulässig wenn das Teilprogramm eine Nachricht an das Terminal oder den Client (LTERM-Partner) sendet oder wenn die Nachricht an einen Partner-Vorgang gerichtet ist und dieser sich nicht im Transaktionsstatus "P" befindet. |
PEND RE | Es wird Transaktionsende (Sicherungspunkt) angefordert. Befinden sich alle Partner-Vorgänge bereits im Transaktionsstatus "P" (d.h. sie haben schon Transaktionsende angefordert), so wird von den beteiligten Vorgängen das Transaktionsende durchgeführt, d.h. es wird ein gemeinsamer Sicherungspunkt gesetzt. Befindet sich ein Partner-Vorgang nicht im Transaktionsstatus "P", so geht der lokale Vorgang in den Transaktionsstatus "P" und wartet, dass der Partner-Vorgang ebenfalls Transaktionsende anfordert. Im Auftraggeber-Vorgang wird das in KCRN angegebene Folge-Teilprogramm gestartet, sobald alle Ergebnisse von den Auftragnehmer-Vorgängen eingetroffen sind. Zulässig in folgenden beiden Fällen:
Wenn es mehrere Partner-Vorgänge mit offenen Transaktionen gibt ist PEND RE also verboten. |
PEND FI | Die Wirkung ist die gleiche wie beim PEND RE, nur dass gleichzeitig Vorgangsende angefordert wird. Der Vorgang wird beim nächsten Sicherungspunkt beendet. Zulässig, wenn kein Auftragnehmer-Vorgang mehr offen ist. D.h. alle Auftragnehmer müssen PEND FI abgesetzt haben, bevor der Auftraggeber PEND FI absetzen darf. |
PEND FC | Die Wirkung ist die gleiche wie beim PEND FI, nur dass nach Vorgangsende sofort der per Vorgangs-Kettung angeschlossene Folge-Vorgang gestartet wird. Zulässig nur in Auftraggeber-Vorgängen (in Auftragnehmern also grundsätzlich verboten) und nur dann, wenn kein Auftragnehmer-Vorgang mehr offen ist. D.h. alle Auftragnehmer müssen PEND FI abgesetzt haben, bevor der Auftraggeber PEND FC absetzen darf. |
PEND PR | kein Einfluss auf Transaktion. |
PEND SP | Die Transaktion wird geschlossen, d.h. ein Sicherungspunkt wird gesetzt und der Verarbeitungsschritt wird fortgesetzt. Zulässig, wenn es keinen Partner-Vorgang mit offener Transaktion gibt. |
PEND RS | Mit PEND RS werden alle an der verteilten Transaktion beteiligten Vorgänge auf den letzten Sicherungspunkt zurückgesetzt. Alle Vorgänge, die in der verteilten Transaktion entstanden sind, werden durch das Rücksetzen beendet. Vorgänge, die mindestens einen Sicherungspunkt erreicht haben, bleiben offen. |
Programmierregeln
Beim Programmieren verteilter Transaktionen sind eine Reihe von Regeln einzuhalten, deren Verletzung den Abbruch des betroffenen Vorgangs mit (internem) PEND ER und KCRCCC=87Z zur Folge hat.
Diese Regeln bestimmen:
wie Transaktionen und Vorgänge bei verteilter Verarbeitung beendet werden müssen und
an wen die Ausgabenachricht gesendet werden darf.
Das Beenden von Teilprogrammläufen, Transaktionen und Vorgängen wird wie gewohnt über die verschiedenen PEND-Varianten realisiert; wichtig sind dabei die PEND-Varianten KP, RE, SP, FI, FC und für die Fehlerbehandlung RS, ER und FR.
Bei den Varianten KP, RE und SP wird in KCRN das Folge-Teilprogramm angegeben, mit dem der lokale Vorgang fortgesetzt wird. Dieses Folge-Teilprogramm wird bei PEND KP/RE gestartet, sobald alle Ergebnisse von den Auftragnehmern eingetroffen sind, oder - falls die Nachricht an den Auftraggeber gerichtet war - sobald die nächste Nachricht vom Auftraggeber eintrifft. Bei PEND SP wird das Folge-Teilprogramm sofort gestartet.
Der Aufruf PGWT KP kann immer dann verwendet werden, wenn auch ein PEND KP erlaubt ist.
Für die korrekte Programmierung einer verteilten Transaktion gelten folgende Regeln:
Vorgangs-Regel: Ein Auftraggeber-Vorgang darf erst beendet werden, nachdem alle zugehörigen Auftragnehmer-Vorgänge (mit PEND FI) beendet wurden. PEND FC ist in Auftragnehmer-Vorgängen verboten.
Der Auftraggeber-Vorgang kann nach dem PEND FI des Auftragnehmer-Vorgangs den folgenden Verarbeitungsschritt mit PEND KP, RE, SP, FI oder FC beenden. Er darf keine Nachricht mehr an diesen Auftragnehmer-Vorgang senden.
Transaktionsregel (einstufig): Ein Auftraggeber- oder Auftragnehmer-Vorgang kann einen Verarbeitungsschritt wahlweise mit oder ohne Transaktionsende abschließen, wobei folgende Einschränkungen beachtet werden müssen:
Ein Auftraggeber-Vorgang darf kein Transaktionsende anfordern, wenn im Auftragnehmer-Vorgang die Transaktion offen ist und die Ausgabenachricht an den Client gerichtet ist.
Ein Vorgang muss Transaktionsende anfordern, wenn die Ausgabenachricht an einen Partner-Vorgang gerichtet ist, der Transaktionsende angefordert hat.
Bei mehrstufiger verteilter Transaktion, d.h. wenn ein Auftragnehmer-Vorgang selbst wieder Auftraggeber-Vorgang ist oder wenn ein Auftraggeber-Vorgang in einer Transaktion mehrere Auftragnehmer-Vorgänge adressiert, dann wird die Transaktionsregel wie folgt verallgemeinert:
Transaktionsregel (mehrstufig): Ein Vorgang kann einen Verarbeitungsschritt wahlweise mit oder ohne Transaktionsende abschließen, wobei folgende Einschränkungen beachtet werden müssen:
Ein Vorgang darf kein Transaktionsende anfordern, wenn es einen Partner-Vorgang mit offener Transaktion gibt und die Ausgabenachricht nicht an diesen Partner-Vorgang gerichtet ist. Wenn es mehrere Partner-Vorgänge mit offenen Transaktionen gibt, ist es somit grundsätzlich verboten Transaktionsende anzufordern.
Ein Vorgang muss Transaktionsende anfordern, wenn die Ausgabenachricht an einen Partner-Vorgang gerichtet ist, der Transaktionsende angefordert hat.
Hat ein Vorgang mehrere Partner-Vorgänge mit offener Transaktion, dann sind PEND RE, PEND FI und PEND SP grundsätzlich nicht erlaubt.
In welcher Situation welcher PEND-Aufruf zulässig ist, zeigen die Tabellen „Wirkung der PEND-Aufrufe und Einsatzregeln", „PEND-Varianten im Auftraggeber" und „PEND-Varianten im Auftragnehmer-Vorgang".
Befolgt man die nachfolgend beschriebene Bottom-Up-Strategie, dann werden die Programmierregeln automatisch eingehalten.
Programmierempfehlung: Bottom-Up-Strategie
Die Bottom-Up-Strategie besteht darin, dass verteilte Transaktionen immer von unten nach oben beendet werden, d.h.:
Ein Auftragnehmer-Vorgang fordert immer vor seinem Auftraggeber-Vorgang Transaktionsende an und sendet seine Ausgabenachricht an seinen Auftraggeber-Vorgang.
Ein Auftraggeber-Vorgang fordert erst Transaktionsende an, wenn alle seine Auftragnehmer-Vorgänge Transaktionsende angefordert haben. Die Ausgabenachricht geht wiederum an seinen eigenen Auftraggeber.
PEND-Varianten in Abhängigkeit vom Partner-Status
Beim PEND-Aufruf muss immer auf den Vorgangs-Status und den Transaktions-Status des Partner-Vorgangs geachtet werden. Diese Statusangaben gibt openUTM nach dem MGET-Aufruf in den Feldern KCVGST/kcpcv_state und KCTAST/kcpta_state zurück.
Bei den in folgenden Tabellen dargestellten Fällen werden keine neuen Regeln eingeführt, sie illustrieren lediglich die in den vorhergehenden Abschnitten genannten Regeln.
PEND-Varianten im Auftraggeber
Die Aufrufe PEND PA und PEND PR sind nicht berücksichtigt, da es bei ihnen keine Besonderheiten bei verteilter Verarbeitung gibt.
Partnerstatus | PEND-Varianten im Auftraggeber-Vorgang | ||
|---|---|---|---|
KCVGST/kcpcv_state | KCTAST/kcpta_state | erlaubte Varianten und deren Wirkung und Einschränkungen | |
"O" | "O" | KP: | Transaktionen im Auftraggeber- und Auftragnehmer-Vorgang bleiben offen - Normalfall. |
RE: | fordert Transaktionsende an. Nur erlaubt, wenn die Ausgabenachricht an diesen Auftragnehmer gerichtet ist und es keinen weiteren Partner mit offener Transaktion gibt. | ||
RS: | setzt Auftraggeber- und Auftragnehmer-Transaktion zurück auf den letzten Sicherungspunkt. Vorgänge, die in dieser Transaktion entstanden sind, werden beendet. | ||
ER/FR: | beendet Auftraggeber- und Auftragnehmer-Vorgang und setzt die verteilte Transaktion zurück. | ||
"O" | "P" | KP: | Nur erlaubt, wenn die Ausgabenachricht an einen anderen Partner-Vorgang oder an den Client gerichtet ist; die Transaktionen bleiben offen (nicht zu empfehlen wegen PTC-Zustand) |
RE: | Die verteilte Transaktion wird beendet. | ||
SP: | Die verteilte Transaktion wird beendet. | ||
RS: | setzt Auftraggeber- und Auftragnehmer-Transaktion zurück auf den letzten Sicherungspunkt. Vorgänge, die in dieser Transaktion entstanden sind, werden beendet. | ||
ER/FR: | beendet Auftraggeber- und Auftragnehmer-Vorgang und setzt die verteilte Transaktion zurück. | ||
"O" | "C" | KP: | Die Transaktion im Auftraggeber-Vorgang bleibt offen. |
RE: | Die Transaktion im Auftraggeber-Vorgang wird beendet, wenn die Ausgabe-Nachricht an den Client gerichtet ist, andernfalls geht der Vorgang in den Transaktionsstatus "P". | ||
SP: | Die Transaktion im Auftraggeber-Vorgang wird beendet. | ||
RS: | setzt die Auftraggeber-Transaktion zurück auf den letzten Sicherungspunkt. Vorgänge, die in dieser Transaktion entstanden sind, werden beendet. | ||
ER/FR: | beendet Auftraggeber- und Auftragnehmer-Vorgang und setzt die lokale Transaktion zurück. | ||
"C" | "P" | Die Ausgabenachricht muss an einen anderen Partner oder an den Client oder (bei PEND SP/FC) an ein Folge-Teilprogramm gehen! | |
KP: | nicht zu empfehlen, da der Auftragnehmer-Vorgang im Zustand PTC wartet. | ||
RE: | beendet die verteilte Transaktion und den Auftragnehmer-Vorgang | ||
SP: | wie bei RE | ||
FI: | beendet die verteilte Transaktion sowie Auftraggeber-und Auftragnehmer-Vorgang | ||
FC: | wie bei FI | ||
RS: | setzt Auftraggeber- und Auftragnehmer-Transaktion zurück auf den letzten Sicherungspunkt. Vorgänge, die in dieser Transaktion entstanden sind, werden beendet. | ||
ER/FR: | beendet Auftraggeber- und Auftragnehmer-Vorgang und setzt die verteilte Transaktion zurück. | ||
"C" | "C" | Die Ausgabenachricht muss an einen anderen Partner oder an den Client oder (bei PEND SP/FC) an ein Folge-Teilprogramm gehen! | |
KP: | Die Transaktion im Auftraggeber bleibt offen. | ||
RE: | Die Transaktion im Auftraggeber wird beendet | ||
SP: | Die Transaktion im Auftraggeber wird beendet | ||
FI: | Transaktion und Auftraggeber-Vorgang werden beendet. | ||
FC: | Transaktion und Auftraggeber-Vorgang werden beendet. | ||
RS: | setzt die Auftraggeber-Transaktion zurück auf den letzten Sicherungspunkt. | ||
ER/FR: | setzt die Transaktion im Auftraggeber-Vorgang zurück und beendet den Auftraggeber-Vorgang. Der Auftragnehmer-Vorgang ist bereits beendet. | ||
Die Kombinationen "KCVGST=O, KCTAST=C" und "KCVGST=C, KCTAST=C" können nicht auftreten, wenn die "Bottom-Up-Strategie" eingehalten wird.
PEND-Varianten im Auftragnehmer-Vorgang
Die Aufrufe PEND PA und PEND PR sind dabei nicht berücksichtigt, da es bei ihnen keine Besonderheiten bei verteilter Verarbeitung gibt. Die Variante PEND FC ist in Auftragnehmer-Vorgängen nicht erlaubt.
Partnerstatus | PEND-Varianten im Auftragnehmer-Vorgang | ||
|---|---|---|---|
KCVGST/kcpcv_state | KCTAST/kcpta_state | erlaubte Varianten und deren Wirkung und Einschränkungen | |
"O" | "O" | KP: | Die Transaktionen in Auftragnehmer- und Auftraggeber-Vorgang bleiben offen. |
RE: | Der Auftragnehmer-Vorgang geht in den Transaktionsstatus P. | ||
FI: | Der Auftragnehmer-Vorgang geht in den Transaktionsstatus P. Der Vorgang wird beim nächsten Sicherungspunkt (=Ende der verteilten Transaktion) beendet. | ||
RS: | setzt die verteilte Transaktion zurück auf den letzten Sicherungspunkt. Vorgänge, die in dieser Transaktion entstanden sind, werden beendet. | ||
ER/FR: | Die verteilte Transaktion wird zurückgesetzt; der Auftragnehmer-Vorgang wird beendet. | ||
"O" | "P" | RE: | Die verteilte Transaktion wird beendet. |
SP: | Die verteilte Transaktion wird beendet. | ||
FI: | Die verteilte Transaktion und der Auftragnehmer-Vorgang werden beendet. | ||
RS: | setzt die verteilte Transaktion zurück auf den letzten Sicherungspunkt. Vorgänge, die in dieser Transaktion entstanden sind, werden beendet. | ||
ER/FR: | Die verteilte Transaktion wird zurückgesetzt; der Auftragnehmer-Vorgang wird beendet. | ||
"O" | "C" | KP: | erlaubt |
RE: | Der Auftragnehmer-Vorgang geht in den Transaktionsstatus P. | ||
SP: | Der Auftragnehmer-Vorgang beendet eine lokale Transaktion | ||
FI: | Der Auftragnehmer-Vorgang geht in den Transaktionsstatus P. Der Vorgang wird beim nächsten Sicherungspunkt (=Ende der verteilten Transaktion) beendet. | ||
RS: | setzt die verteilte Transaktion zurück auf den letzten Sicherungspunkt. | ||
ER/FR: | Die verteilte Transaktion wird zurückgesetzt; der Auftragnehmer-Vorgang wird beendet. | ||
Wenn die Bottom-Up-Strategie eingehalten wird, dann kann nur die Kombination "O"/"O" auftreten, siehe "Bottom-Up-Strategie".
Vor einem PEND RS in einer Folge-Transaktion müssen Sie mit MPUT RM eine Rücksetznachricht schicken, sonst bricht openUTM den Auftragnehmer-Vorgang mit 83Z ab.