RSET Transaktion zurücksetzen

Mit dem Aufruf RSET (reset transaction) können Sie Änderungen und Operationen der Transaktion rückgängig machen. Auch offene Datenbank-Transaktionen werden zurückgesetzt. Alle Ausgabe-Operationen seit dem letzten lokalen Sicherungspunkt werden verworfen. Die Kontrolle wird an das Teilprogramm zurückgegeben: Das Teilprogramm wird hinter dem RSET-Aufruf fortgesetzt. Anschließend sind weitere KDCS-Aufrufe (außer INIT) sowie Datenbank-Aufrufe möglich.

Mit dem RSET-Aufruf lässt sich auf Anwendungsfehler mit gezielten Aktionen reagieren. Sie können eine Transaktion zurücksetzen und gleichzeitig die Kontrolle im Anwendungsprogramm zurückerhalten.

Sinnvoll ist ein solches Vorgehen bei Fehlern, die keine Programmfehler sind (z.B. als Reaktion auf KDCS-Returncodes >= 40Z). Im Teilprogramm können Sie dann gezielt reagieren, z.B. durch:

• Senden einer Nachricht an den betreffenden Client oder an den Administrator (MPUT)

• Schreiben einer Logging-Information (LPUT)

• Senden eines Ausgabeauftrags, z.B. an einen Drucker (FPUT/DPUT)

Der RSET-Aufruf kann z.B. auch dann sinnvoll sein, wenn Datenbankzugriffe unerwartete Returncodes liefern (z.B. "Satz nicht vorhanden") und bereits UPDATE-Operationen gelaufen sind.

Versorgen des 1. Parameters (KDCS-Parameterbereich)

Für den RSET-Aufruf ist nur die Angabe des Operationscodes "RSET" im Feld KCOP notwendig.

Versorgen der Parameter
Feldname im KDCS-Parameterbereich	Inhalt
KCOP	"RSET"

KDCS-Aufruf
1. Parameter	2. Parameter
KDCS-Parameterbereich	—

C/C++-Makroaufruf
Makronamen	Parameter
KDCS_RSET	()

Rückgaben von openUTM
Feldname im KB-Rückgabebereich	Inhalt
KCRCCC	Returncode
KCRCDC	interner Returncode

In den KDCS-Parameterbereich tragen Sie für den RSET-Aufruf ein:

KCOP

im Feld KCOP den Operationscode RSET.

Andere Operanden des Parameterbereiches wertet openUTM nicht aus.

Beim KDCS-Aufruf geben Sie an:

1. Parameter

als 1. Parameter: Die Adresse des KDCS-Parameterbereichs.

Makronamen

Wie Sie Makroaufrufe für C/C++ nutzen, ist in Abschnitt „C/C++-Makroschnittstelle" ausführlich beschrieben.

openUTM gibt zurück:

KCRCCC

im Feld KCRCCC den KDCS-Returncode.

KCRCDC

im Feld KCRCDC den internen Returncode von openUTM (siehe openUTM-Handbuch „Meldungen, Test und Diagnose“).

KDCS-Returncodes im Feld KCRCCC beim RSET-Aufruf

Im Programm ist auswertbar:

000	Die Operation wurde ausgeführt.

Weitere Returncodes sind dem Dump zu entnehmen:

70Z	Die Operation kann vom System nicht ausgeführt werden (Generierungs- bzw. Systemfehler), siehe KCRCDC.
71Z	Es wurde noch kein INIT gegeben.

Eigenschaften des RSET-Aufrufs

• Alle bis zum RSET-Aufruf von dieser Transaktion belegten Betriebsmittel werden freigegeben.

• Alle Vorgangs-spezifischen Daten werden auf den letzten Sicherungspunkt zurückgesetzt, d.h. es stehen der KB-Programmbereich, alle LSSBs und GSSBs sowie TLS- und ULS-Blöcke mit ihren alten Inhalten wieder zur Verfügung.

• Daten im SPAB und in Programm-spezifischen Arbeitsspeicherbereichen bleiben unverändert.

• Eine offene DB-Transaktion wird zurückgesetzt.

• Jedes Rücksetzen einer DB-Transaktion hat die gleiche Wirkung wie ein RSET-Aufruf, führt also implizit zum Rücksetzen der UTM-Transaktion.

• Das Teilprogramm erhält die Kontrolle nach dem RSET-Aufruf zurück und setzt den Programmlauf mit der nächsten Anweisung fort, welche auf den RSET-Aufruf folgt. Im Teilprogramm können dann weitere KDCS-Aufrufe (mit Ausnahme von INIT) und DB-Aufrufe gegeben werden.

• Eine vor dem RSET-Aufruf gelesene Dialog-Eingabenachricht lässt sich anschließend nicht mehr lesen. Eine vor einem RSET-Aufruf noch nicht gelesene Dialog-Eingabenachricht lässt sich anschließend noch lesen.

• Mit FGET oder DGET gelesene Eingabe-Nachrichten lassen sich nach einem RSET wieder lesen. Bei DGET-Nachrichten jedoch nur dann, wenn die in der Generierung festgelegte maximale Anzahl erneuter Zustellungen ist noch nicht erreicht. Näheres siehe openUTM-Handbuch „Anwendungen generieren“, Operand REDELIVERY in der MAX-Anweisung.

  Ist die maximale Anzahl erneuter Zustellung erreicht, so wird die Nachricht gelöscht oder von UTM in der Dead Letter Queue gesichert (nur bei Nachrichten an eine TAC-Queue möglich), siehe openUTM-Handbuch „Anwendungen generieren“, Operand DEAD-LETTER-Q in der TAC-Anweisung.

Eigenschaften des RSET-Aufrufs bei verteilter Verarbeitung

Das Verhalten von openUTM nach einem RSET-Aufruf in einem Teilprogrammlauf, der zu einer verteilten Transaktion gehört, ist abhängig vom Generierungsparameter RSET der UTMD-Anweisung (siehe openUTM-Handbuch „Anwendungen generieren“):

• Ist RSET=LOCAL generiert, dann hat der RSET-Aufruf keine Auswirkungen auf die verteilte Transaktion.
  Dabei kann es zu Inkonsistenzen in den verteilten Datenbeständen kommen, wenn einige der an der verteilten Transaktion beteiligten lokalen Transaktionen vorgesetzt und andere zurückgesetzt werden. Bei dieser Generierung wird die globale Datenkonsistenz nicht mehr von den beteiligten Systemkomponenten garantiert, sondern liegt in der Verantwortung der Anwendungsteilprogramme. Diese müssen entscheiden, in welchen Situationen die verteilte Transaktion noch sinnvoll beendet werden kann und in welchen sie zurückgesetzt werden muss.

• Ist RSET=GLOBAL generiert, dann erzwingt openUTM, dass der Teilprogrammlauf mit einer PEND-Variante beendet wird, die zum Rücksetzen der verteilten Transaktion führt (siehe auch Abschnitt "PEND Beenden eines Teilprogramms").