Musste die verteilte Transaktion zurückgesetzt werden, so wird beim Vorgangs-Wiederanlauf möglichst dasjenige Programm erneut gestartet, für welches beim Ende der letzten verteilten Transaktion eine Nachricht vorlag, bzw. für welches die nächste Eingabe vom Client bestimmt ist. Die Programmierregeln (siehe "Programmierregeln und Empfehlungen" für LU6.1, "Programmierregeln für Dialoge mit Functional Unit Commit" für OSI TP) stellen sicher, dass am Ende einer verteilten Transaktion genau eine Nachricht an den Client oder an ein Programm in einem Vorgang vorliegt.
Das Teilprogramm kann am Vorgangs-Kennzeichen im Feld KCKNZVG/ kccv_status im KB-Kopf erkennen, ob ein Vorgangs-Wiederanlauf stattgefunden hat: Nach einem Vorgangs-Wiederanlauf enthält dieses Feld den Wert "R".
Findet der Vorgangs-Wiederanlauf im Auftraggeber-Vorgang statt, dann erhält das Teilprogramm immer dann eine Statusinformation vom Auftragnehmer-Vorgang, wenn das Rücksetzen vom Auftragnehmer-Vorgang verursacht und dieser dadurch beendet wurde oder beendet wird. Eine solche Statusinformation wird mit MGET NT gelesen; sie ist eine Nachricht der Länge 0 und liefert in KCVGST/kcpcv_state und KCTAST/kcpta_state im KB-Rückgabebereich Vorgangs- und Transaktionsstatus des Auftragnehmer-Vorgangs (siehe "Programmierhilfen").
Beim Vorgangs-Wiederanlauf lassen sich nun 3 Fälle unterscheiden:
Beim letzten Sicherungspunkt lag eine Nachricht an den Client vor.
Das Folge-Teilprogramm im Auftraggeber-Vorgang kann nun mit MGET die neue Eingabe des Client lesen und erhält dabei als Statusinformation den Vorgangs-Status O und den Transaktions-Status C.
Wurde das Rücksetzen der Transaktion auf Grund eines Fehlers in einem Auftragnehmer-Vorgang verursacht und der Auftragnehmer-Vorgang dadurch beendet, so erhält man im Feld KCRPI die Vorgangs-ID desjenigen Vorgangs, der das Rücksetzen verursacht hat. Anschließend kann mit MGET NT und KCRN = Vorgangs-ID eine Statusinformation von diesem Vorgang gelesen werden.
Am letzten Sicherungspunkt liegt eine Nachricht von einem Auftragnehmer-Vorgang an einen Auftraggeber-Vorgang vor.
Das Folge-Teilprogramm im Auftraggeber-Vorgang kann die Nachricht nun wie üblich mit MGET lesen und erhält dabei den Vorgangs- und Transaktions-Status von diesem Auftragnehmer-Vorgang.
Wurde dieser Auftragnehmer-Vorgang durch einen Fehler zurückgesetzt und beendet, so erhält man nur eine entsprechende Statusinformation. Wurde das Rücksetzen von einem anderen Auftragnehmer-Vorgang verursacht, so erhält man als Statusinformation beim ersten MGET den Transaktionsstatus C. Anschließend können wie im Fall 1 noch eine oder mehrere Statusinformationen gelesen werden.
Kann die Nachricht vom Auftragnehmer nicht gesendet werden (siehe nächsten Abschnitt), so erhält der Auftraggeber lediglich eine Statusinformation vom Auftragnehmer-Vorgang.
Beim letzten Sicherungspunkt lag eine Nachricht von einem Auftraggeber-Vorgang an einen Auftragnehmer-Vorgang vor. Wenn möglich, wird dann das Folge-Teilprogramm im Auftragnehmer-Vorgang gestartet.
Kann das Folge-Teilprogramm nicht gestartet werden (z.B. weil die Anwendung beendet und innerhalb der generierten Wartezeit nicht wieder gestartet wurde oder weil sich der Vorgang mit PEND ER beendet hat), so wird das Folge-Teilprogramm im Auftraggeber-Vorgang gestartet und erhält eine Statusinformation.
Statusinformationen liegen von allen Auftragnehmer-Vorgängen vor, die das Rücksetzen der verteilten Transaktion verursacht haben und beendet wurden bzw. noch werden.
Wird nach einem Vorgangs-Wiederanlauf des Auftraggeber-Vorgangs wieder ein Auftragnehmer-Vorgang adressiert und tritt wieder ein Fehler auf, so kann der Auftraggeber-Vorgang mehrfach auf den gleichen Sicherungspunkt zurückgesetzt werden. Da die Statusinformationen vom vorhergehenden Rücksetzen erhalten bleiben, kann man eventuell mehrere Statusinformationen erhalten.
Liegen mehrere Statusinformationen vor, so erhält man jeweils beim MGET die Vorgangs-Identifikation eines nächsten Vorgangs mit Statusinformation. Statusinformationen von mehreren Auftragnehmer-Vorgängen müssen in der von openUTM vorgeschlagenen Reihenfolge (KCRPI) gelesen werden. Das Feld KCMF/kcfn versorgen Sie beim Lesen der Statusinformation mit Leerzeichen.
Ist ein entfernter Vorgang in der zurückgesetzten Transaktion durch APRO-Aufruf neu entstanden, so liegt von diesem möglicherweise eine Statusinformation vor, obwohl es auf dem Sicherungspunkt, auf dem neu aufgesetzt wird, diesen Vorgang eigentlich noch nicht gibt.
Keine Nachricht vom Auftragnehmer
Es gibt zwei Möglichkeiten, weshalb ein Auftragnehmer-Vorgang kein Ergebnis an den Auftraggeber-Vorgang senden kann.
der Auftragnehmer-Vorgang wurde aus einem der folgenden Gründe nicht gestartet:
es existiert keine logische Verbindung zur Anwendung des Auftragnehmers und innerhalb der generierten Wartezeit konnte keine Verbindung aufgebaut werden.
innerhalb der generierten Wartezeit konnte keine Session bzw. Association zur Anwendung des Auftragnehmers belegt werden.
der Auftrag wurde zur Anwendung des Auftragnehmers gesendet, aber der übermittelte Transaktionscode ist unbekannt oder gesperrt.
die Anwendung des Auftraggebers wird mit KDCSHUT W beendet.
Der Auftragnehmer-Vorgang wurde gestartet, aber bei der Bearbeitung des Auftragnehmer-Vorgangs traten Fehler auf oder der Kommunikationsweg wurde gestört. Deshalb wurde die Transaktion im Auftragnehmer-Vorgang zurückgesetzt und der Auftragnehmer-Vorgang wurde beendet. Außerdem wurde die Session/Association zum fehlerhaft beendeten Auftragnehmer-Vorgang freigegeben. Es können folgende Fehlersituationen auftreten:
innerhalb der generierten Wartezeit ist keine Antwort vom Auftragnehmer-Vorgang bei der Anwendung des Auftraggebers eingetroffen.
die Anwendung des Auftragnehmers wurde wegen eines gravierenden Fehlers abnormal beendet.
der Auftragnehmer-Vorgang hat sich mit PEND ER beendet oder wurde mit gravierendem Programmfehler beendet.