Trigger und journal

[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.

[Fuerchau]

Ja, weil das trotzdem durch SQL gemacht wurde, siehe "Set Option".
Da du den Trigger ja debuggen kannst, kannst du den commit-Status des Jobs ja prüfen.
Wenn du z.B. über STRSQL einen Update machst, wird der Trigger ja auch aufgerufen.
Allerdings funktioniert das nur über eine 2. Sitzung per STRSRVJOB zur 1. Sitzung und dann per STRDBG, der auf dem Zieljob ausgeführt wird.
So teste ich immer erst mal die Trigger.

Bei STRSQL kann man den Commit-Status per F13 einstellen und so mit und ohne Commit testen.

[itec01]

Habe das Programm nun endlich fertig. Was ein Krampf mit den Parametern.
Nun habe ich folgendes Problem:
Ich mache einen strcmtctl *chg
call PGMxx
Result = A --> perfekt
endcmtctl
call PGMxx
bricht ab, weil das Objekt nicht aufgelöst werden kann
Aufl¦sung zu Objekt nicht m¦glich. Art und Subart X'0201', Berechtigung
X'0000'.

Das passiert auch, wenn ich es umgekehrt mache, d.h.
zuerst den Aufruf vom Programm
dann STRCMTCTL *CHG
dann Aufruf des Programmes
Inhalt aus dem Programm:
c callp RtvCmtData(w@Rcvva:
c w@RcvLe:
c 'CMTI0100':
c w@errorDta)

definiert wie folgt:

dRtvCmtData pr extpgm( 'QTNRCMTI' )
d w@Receiver like( w@rcvva )
d w@Laenge const like( w@Rcvle )
d w@Format 8 const
d w@Error like (w@ErrorDta)

An was kann das liegen?

[B.Hauser]

In welcher Aktivierungsgruppe läuft denn Dein PGMXXX?
Mit welchem Commitment Scope wird denn die Commitment Steuerung gestartet?
Sollte es *ACTGRPDFN sein, würde ich die Aktivierungsgruppe mit RCLACTGRP vor dem erneuten Aufruf schließen.
Sollte es allerdings die Default Activation Group sein .... dann hast du Pech gehabt, d.h. da hilft nur ein EndJob