Trigger und journal

[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

[Fuerchau]

Wenn ich Trigger auf einer Tabelle habe, darf ich RCLACTGRP nicht verwenden.
Denn die ACTGRP wird aufgelöst, jedoch findet dann die Datenbank den Trigger nicht mehr, denn dieser Pointer auf das Programm wird wohl nur beim 1. Open generell gesetzt und irgnedwo im Job festgehalten.
Das war schon immer ein Problem, seit V2R1.

[itec01]

Guten Morgen Zusammen,
sorry für meine schlechte Erklärung. Es geht noch gar nicht um das Trigger Programm, sondern um das Programm welches prüft, ob STRCMTCTL aktiv ist oder nicht, sprich in dem Programm wird das API QTNRCMTI aufgerufen.
Irgendetwas stimmt nicht, eventuell auch falsch programmiert.
@Birgitta:Vergiss das mit STRCMTCTL. Der Fehler tritt auf, sobald ich das Programm 2x aufrufe, d.h. irgendetwas passiert durch den 1. Aufruf.
Wieso findet das Programm entweder das API nicht mehr oder im API irgendwelche aufgerufenen Programme?
Wo ich mir auch sehr unschlüssig bin ist in der Definition der DS:
Der Wert wird zwar ausgegeben, aber in anderen API's haben wir mit StartPos und Länge auch etwas gemacht.
So sieht es aktuell aus:

h DEBUG ACTGRP(*CALLER) DFTACTGRP(*NO) BNDDIR('*LIBL/SPE')
d ds
d w@lendta 1 4b 0
d w@strpos 5 8b 0
d w@splfx 9 12b 0
d w@rcvle1 13 16b 0
d w@filx 17 22
d w@rcvle 23 26b 0

d w@Rcvva ds
d w@bytrtn 1 4b 0
d w@bytval 5 8b 0
d w@cmtsts 9 9
d w@cmtstsAG 21 21

d w@ErrorDta ds
d w@bytrtne 1 4b 0
d w@bytvale 5 8b 0
d w@ExcepId 9 15
d w@ResChar 16 16
d w@ExcepDta 17 500

c callp RtvCmtData(w@Rcvva:
c w@RcvLe:
c 'CMTI0100':
c w@errorDta)

Die Var w@RCVLE ist mir auch nicht so ganz klar, habe dies aus meinem altem Programm übernommen.