PDA

View Full Version : Trigger und journal



Seiten : [1] 2 3 4

itec01
08-05-23, 15:51
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
08-05-23, 16:20
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 (https://www.ibm.com/docs/en/i/7.5?topic=programs-trigger-buffer-sections)
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 (https://www.ibm.com/docs/en/i/7.5?topic=statements-get-diagnostics)

Fuerchau
08-05-23, 20:46
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
09-05-23, 06:52
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
09-05-23, 07:29
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 (https://www.ibm.com/docs/en/i/7.5?topic=programs-trigger-buffer-sections)
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 (https://www.ibm.com/docs/en/i/7.5?topic=statements-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
09-05-23, 08:32
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
09-05-23, 09:06
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
09-05-23, 11:36
Schau mal hier:
https://www.ibm.com/docs/en/i/7.2?topic=ssw_ibm_i_72/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
09-05-23, 11:46
Schau mal hier:
https://www.ibm.com/docs/en/i/7.2?topic=ssw_ibm_i_72/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
10-05-23, 08:12
Hat jemand zufällig einen Beispielcode für die API QTNRCMTI? Ich bekomme es einfach nicht hin mit den Parametern.

Required Parameter Group <dl><dt>Receiver variable</dt><dd>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.
</dd><dt>Length of receiver variable</dt><dd>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.
</dd><dt>Format name</dt><dd>INPUT; CHAR(8) The format name CMTI0100 is the only valid format name used by this API. For more information, see CMTI0100 Format (https://www.ibm.com/docs/en/i/7.2?topic=ssw_ibm_i_72/apis/QTNRCMTI.html#HDRRTVCIF1).
</dd><dt>Error code</dt><dd>I/O; CHAR(*) The structure in which to return error information. For the format of the structure, see Error code parameter



(https://www.ibm.com/docs/en/ssw_ibm_i_72/apiref/error.htm#hdrerrcod)

</dd></dl>