Trigger und journal

[itec01]

Hallo Zusammen,
kann ich im Trigger Programm auslesen, ob die Datei gerade unter STRCMTCTL commit/ rollback läuft?
In einer Datei soll der User reingeschrieben werden, der den Satz erzeugt hat. Um nun zu verhindern, dass ich alle Programme ändern muss, habe ich mir einen Insert Trigger auf die Datei gelegt und im Trigger Programm einen chain und update gemacht.
Liegt die Datei unter Commit muss auch das Trigger Programm unter commit laufen (F-Bestimungen). Mache ich einen Upddta ohne strcmtctl bricht das Trigger Programm folgerichtig ab. Wenn ich im Programm dies erkennen könnte, dann würde ich in den F-Bestimmungen den commit bedingen und wäre sicher für allle Eventualitäten.
Die Stelle 32 in der Trigger DS kann ich nicht nehmen, ebenso habe ich in der SDS auch nichts gefunden.
Danke.
Gruß Klaus

[B.Hauser]

Was für ein Trigger ist es?
SQL oder System-Trigger?
Bei einem System-Trigger ist das Commit Lock Level im Trigger Buffer auf Position 32 hinterlegt (0=*NONE, 1=*CHG, 2=*CS, 3=*ALL)
Trigger Buffer Secitions
In einem SQL Trigger sollte es möglich sein, über GET DIAGNOSTICS in den Statement Informationen über Schlüssel-Wort TRANCACTION_ACTIVE ob gerade unter Commitment gearbeitet wird oder nicht.
GET DIAGNOSTICS

[Fuerchau]

Der Commit-Status der F-Bestimmung ist nicht änderbar und gilt zur Compilezeit.
Entweder du machst das insgesamt unter SQL, also ohne F-Bestimmung, dann gilt die aktuelle Commit-Stufe oder du setzt das Programm in eine eigene ACTGRP und hast dann deine eigene Commit-Umgebung, die auch *NONE sein kann.

DFTACTGRP(*NO) ACTGRP(Programmname)

Aber Vorsicht: bei einem Update kannst du einen Deadlock innerhalb des Jobs erzeugen, wenn der Satz im Job durch eine andere ACTGRP gesperrt ist.
Vorteil: Man kann z.B. Protokollsätze erzeugen, die auch durch Rollback nicht mehr verschwinden.

[itec01]

Der Commit-Status der F-Bestimmung ist nicht änderbar und gilt zur Compilezeit.
Entweder du machst das insgesamt unter SQL, also ohne F-Bestimmung, dann gilt die aktuelle Commit-Stufe oder du setzt das Programm in eine eigene ACTGRP und hast dann deine eigene Commit-Umgebung, die auch *NONE sein kann.

DFTACTGRP(*NO) ACTGRP(Programmname)

Aber Vorsicht: bei einem Update kannst du einen Deadlock innerhalb des Jobs erzeugen, wenn der Satz im Job durch eine andere ACTGRP gesperrt ist.
Vorteil: Man kann z.B. Protokollsätze erzeugen, die auch durch Rollback nicht mehr verschwinden.

Doch das funktioniert mit dem commit nach Bedingung:
0025.00 fPmTrnL01 uf e K disk commit(W@Commit)
0026.00 f usropn
c if Tr#TTI = '0'
c eval W@Commit = '0'
c else
c eval W@Commit = '1'
c endif
Leider klappt die Abfrage nicht, weil in der Variable immer 1 steht, auch wenn ich keinen STRCMTCTL gemacht habe.

[itec01]

Was für ein Trigger ist es?
SQL oder System-Trigger?
Bei einem System-Trigger ist das Commit Lock Level im Trigger Buffer auf Position 32 hinterlegt (0=*NONE, 1=*CHG, 2=*CS, 3=*ALL)
Trigger Buffer Secitions
In einem SQL Trigger sollte es möglich sein, über GET DIAGNOSTICS in den Statement Informationen über Schlüssel-Wort TRANCACTION_ACTIVE ob gerade unter Commitment gearbeitet wird oder nicht.
GET DIAGNOSTICS

Es handelt sich um einen System Trigger. Ja, das commit lock level ist hinterlegt, aber es wird 1 CHG angezeigt, obwohl ich keinen STRCMTCTL gemacht habe.

[Fuerchau]

Ok, das mit der Variablen für Commit in der F-Bestimmung ist für mich neu;-).
Was den Transaktionsstatus angeht, so macht das 1. Programm in einer Aktiverungsgruppe, dass SQL verwendet, automatisch eine STRCMTCTL ohne das dies manuell erfolgen muss.
Beim der Umwandlung eines SQL-Programmes steht die Commit-Option "set option commit = xxx" per Default auf *CHG. Dies muss man explizit bei der Umwandlung angeben wenn man es anders haben will.
Jedoch führt dies immer zu Problemen, wenn auf einer höheren Ebene eines Call-Chains irgendwo ein Programm mit Commit aufgerufen wird. Ebenso passiert dies auch auf einer tieferen Ebene, wenn das Programm dort nicht mit *INLR verlassen wird, z.B. bei Service-Programmen.
Man merkt es auch nicht, wenn man Spiegelsysteme verwendet, die auf Journalen basieren und somit sowieseo jede Datei aufgezeichnet wird.
Nur dann wenn dann augf irgendeiner Ebene unerwartet ein Rollback gemacht wird oder die Anzahl Sperren im Job wachsen.

[itec01]

es ist halt old style:
wir haben im CL Programm einen STRCMTCTL *CHG und dann nach Logik im RPG den Commit / Rollback oder im CL Programm. Noch einmal bitte zu meiner Frage zurück: Ich möchte im TRG Programm erkennen, ob der Job unter STRCMTCTL läuft oder nicht. Wenn ich den STRCMTCTL mache und dann dspjob eingebe, dann sehe ich unter Auswahl 16 den Commit Cyclus. Kann man dies abfragen? In der SDS und der Job Datenstruktur habe ich nichts gefunden.

[Fuerchau]

Schau mal hier:
https://www.ibm.com/docs/en/i/7.2?to.../apis/jc4.html

"First, the Retrieve Commitment Information (QTNRCMTI) API is used by the high-level language (HLL) program to determine if commitment control is active within the activation group for the HLL program."

[itec01]

Schau mal hier:
https://www.ibm.com/docs/en/i/7.2?to.../apis/jc4.html

"First, the Retrieve Commitment Information (QTNRCMTI) API is used by the high-level language (HLL) program to determine if commitment control is active within the activation group for the HLL program."

Oh, super, vielen Dank. Das müsste passen.

[itec01]

Hat jemand zufällig einen Beispielcode für die API QTNRCMTI? Ich bekomme es einfach nicht hin mit den Parametern.

Required Parameter Group

Receiver variable

OUTPUT; CHAR(*) The receiver variable that is to receive the information requested. You can specify the size of the area smaller than the format requested as long as you specify the receiver variable length parameter correctly. As a result, the API returns only the data the area can hold.

Length of receiver variable

INPUT; BINARY(4) The length of the receiver variable. The length must be at least 8 bytes. If the variable is not long enough to hold the information, the data is truncated. If the length is larger than the size of the receiver variable, the results are not predictable.

Format name

INPUT; CHAR(8) The format name CMTI0100 is the only valid format name used by this API. For more information, see CMTI0100 Format.

Error code

I/O; CHAR(*) The structure in which to return error information. For the format of the structure, see Error code parameter

[Fuerchau]

Ist doch eigentlich alles erklärt;-).
Du definierst die Struktur des Formats CMTI0100, dass du als Receiver angibst.
Die Länge der DS übergibst du als INT(10), z.B. %SIZE(CMTI0100).
Der Formatname ist ja angegeben.
Die Errorstruktur hat folgenden Aufbau:
https://www.ibm.com/docs/en/i/7.2?to...or-code-format
Ich verwende da i.d.R.
dcl-ds ERRC0100 qualified inz;
Bytesprovided int(10) inz(%size(ERRC0100));
Bytesavailable int(10);
ExceptionID char(7);
Reserved char(1);
Exceptiondata char(512);
end-ds;

Wenn ein API einen Fehler auswirft, steht die MSGID nebst den Daten in dieser Struktur.
Den Datenaufbau findet man dann in der zugehörigen MSGF, i.d.R. ist das die QSYS, in den Feldbeschreibungen.

Übrigens:
Wenn du einen native trigger mit der Trigger-Bufferstruktur verwendest, steht der Commit-Level da bereits drin:
https://www.ibm.com/docs/en/i/7.3?to...uffer-sections

[itec01]

Übrigens:
Wenn du einen native trigger mit der Trigger-Bufferstruktur verwendest, steht der Commit-Level da bereits drin:
https://www.ibm.com/docs/en/i/7.3?to...uffer-sections

Leider nein, wenn ich keinen STRCMTL mache, dann steht trotzdem 1 = *CHG drin.