MCH3402 Get_Random_DB_Record

[harkne]

Hallo zusammen,

ich werde jetzt mal etwas mehr ausholen und schreiben wie die Situation ist

Wir haben in unsere Datei PMTRNP einen INSERT BEFORE Trigger hinzugefügt. Der schreibt keine Dateien sondern ändert nur einen Feldwert ab
Diese Datei wird in vielen Programmen geschrieben.
Manchmal wurde die physische Datei ohne Keyfelder angegeben im Programm manchmal eine logische Datei mit Schlüsselfelder. In den Programmen ist sie aber immer mit output eröffnet.
Ich schreibe das deshalb, weil ich nicht weiß ob es mit der Problematik zusammenhängt.

Nun die Situation
Es gibt ein Menü (kein echtes AS/400 Menü sondern ein Programm). Aus diesem werden nun die einzelnen Programme aufgerufen.
Die einzelnen startenden Programm sind CLP (also nicht CLLE). Die machen einen STRCMTCTL und einen ENDCMTCTL und vor dem ENDCMTCTL ein RCLRSC. Das hatten wir rein gemacht weil wir Probleme mit offenen Commits hatten, obwohl ein ROLLBACK oder COMMIT immer aus geführt wurde. Die RPGs die aufgerufen werden sind RPGLEs und dort wird dann auch die PMTRNP geschrieben. Die RPGs sind immer mit DFTACTGRP(*NO) und ACTGRP(*CALLER) umgewandelt.

Wenn ich es im Internet richtig gelesen habe, kann das Problem sein, dass der RCLRSC zwar die Dateien schließt aber bei den ILE-Programmen nicht die vorhandenen Referenzen.

Da die User am Anfang keine Probleme haben, aber dann eben wegen einem nicht mehr vorhandenen Referenz abstürzen war meine Vermutung. Sie rufen Programm A auf, wenn sie das verlassen wird der RCLRSC aufgerufen, dann rufen sie Programm B auf (dort war kein Fehler). Dann haben sie wieder Programm A aufgerufen und wir bekommen den Absturz.

Jetzt habe ich das ganze mal untersucht.
Programm A (RPGLE) befindet sich aber auch in der DFTACTGRP obwohl es mit DFTACTGRP(*NO) umgewandelt ist. Ich nehme an es ist dem ACTGRP(*CALLER) geschuldet, da das OPM Program (aufrufendes CL) dort startet.

Ich bin mir ja noch nicht mal sicher ob es wirklich das Problem mit der Aktivierungsgruppe ist.

Kann mir jemand helfen?

Der Fehler tritt immer im Trigger Programm auf und immer mit Get_Random_Db_Record

Vielleicht als Anmerkung noch mit dazu, was mir jetzt auch beim Testen aufgefallen ist.

Also aufrufendes CL ist OPM und das aufgerufene Programm ist RPGLE mit dftactgrp(*no) und actgrp(*caller)
Der Call Stack
CLP --> läuft in *DFTACTGRP und Steuergrenze (Control Boundary) ist NO
RPGLE --> läuft in *DFTACTGRP und Steuergrenze ist YES

Jetzt habe ich aus CLP CLLE gemacht. Aber Standardaktivierungsgruppe ist immer noch ja
Beide laufen weiterhin in *DFTACTGRP aber die Steuergrenze YES hat jetzt das CLLE und seit ich die Programme so umgewandelt habe, haben wir mal bis jetzt keinen Absturz mehr. Tritt aber auch immer nur ein paar mal am Tag auf.

Wenn ich jetzt bei der Umwandlung des CLLE jetzt DFTACTGRP(*NO) angebe und ACTGRP(*CALLER) dann ist es das gleiche wie zuvor, da die Menüprogramme welches das CLLE aufrufen OPMs sind

Wandle ich aber das CLLE mit DFTACTGRP(*NO) um und ACTGRP(*NEW)
Dann bin ich ab meinem CLLE in der Activierungsgruppe *NEW und das CLLE hat die Steuergrenze YES.

Ich bin mir halt nicht sicher wie ich es verwenden sollte und ob es mit meinem Problem was zu tun hat.

Viele Grüße Harald

[B.Hauser]

Das Problem ist ganz klar, dass die RPGLE-Programme in der Default-Aktivierungsgruppe laufen.

In ILE-Programmen geöffnete Dateien bleiben solange geöffnet bis die Aktivierungsgruppe geschlossen wird. Bei der Default-Aktivierungsgruppe ist das eben erst beim Beenden des Jobs.
Wenn jetzt aber RCLRSC aufgerufen wird, werden alle in der Default-Aktivierungsgruppe geöffneten Dateien geschlossen. Bei nächsten Aufruf glaubt das RPGIV-Programm jedoch, dass die Dateien noch geöffnet sind und findet diese nicht. Da hilft auch keine Prüfung mit MONITOR oder %OPEN oder Erweiterung (E). Da bleibt nur den Job zu beenden nun neu zustarten.

Ich würde folgendes vorschlagen:
1. Commitment Control mit Commitment Scops *JOB starten (und bei Programme-Ende nicht schließen - warum auch?
2. Die RPGIV-Programme mit einer benannten Aktivierungsgruppe erstellen und dann auch prüfen, ob für das Programm auch tatsächlich diese Aktivierungsgruppe hinterlegt ist. Wenn aus den Programmen, die aus dem CLP aufgerufen wird weitere Programme aufgerufen werden, so können diese durchaus mit Aktivierungsgruppe *CALLER erstellt werden.
Besser wäre natürlich, wenn beim Erstellen explizit die Aktivierungsgruppe, in der die rufenden Programme laufen, anzugeben. Dadurch wird sichergestellt, dass keine ILE-Programme, die aus OPM aufgerufen werden in der *DFTACTGRP aufgerufen werden.
Dann sollte auch ein RCLRSC unproblematisch sein.
Wenn mit ILE gearbeitet wird und Aktivierungsgruppen geschlossen werden sollen, muss dies mit dem Befehl RCLACTGRP erfolgen.

... und dann noch einmal ausprobieren.

[Robi]

Bin auch sicher, das die DFTACTGRP das Problem ist
Unsere ACTGRP Lösung:
Alle Pgmme laufen in *caller
Aus dem Menüpgm wird (mittlerweile nur noch) 1 Pgm CLLE gerufen, das in *new läuft und das eigendlich zu rufende Pgm als Parameter empfängt. Im Falle eines möglichen / notwendigen Rekursiven Aufrufes eines Pgm' erfolgt der Aufruf wieder über das *new-CLLE.
Robi

[BenderD]

Ich würde folgendes vorschlagen:
1. Commitment Control mit Commitment Scops *JOB starten (und bei Programme-Ende nicht schließen - warum auch?
Dann sollte auch ein RCLRSC unproblematisch sein.
Wenn mit ILE gearbeitet wird und Aktivierungsgruppen geschlossen werden sollen, muss dies mit dem Befehl RCLACTGRP erfolgen.

... und dann noch einmal ausprobieren.

... von all dem genau würde ich die Finger lassen!!!
- commitscope *JOB verändert das Sperrverhalten
- RCLRSC im ILE/OPM Mix ist Murx
- RCLACTGRP mit commit is Murks (schau Dir mal die defaults an)!!!
- von rumprobiererei halte ich grundsätzlich nichts, stattdessen: zu Ende anylysieren und korrigieren.

D*B

[Fuerchau]

RCLRSC nimmt nicht die Programme aus der ACTGRP, Programme werden beim nächsten Aufruf nicht wieder initialisiert.
RCLACTGRP hat dabei dieselben Probleme.
Ein Trigger kann auch in einer eigenen ACTGRP laufen da er keinen Commeit/Rollback machen darf und kann. Da nur im Puffer vor dem Insert was geändert wird, und Allow Changes angegeben isr, kann diesbezüglich auch nichts passieren.
Arbeitet ein Programm mit SQL, ist ein STRCMTCTL/ENDCMTCTL grundsätzlich nicht erforderlich, wohl beim RLA.
RCLRSC erfolgt aus der aktuellen ACTGRP. Man kann keinen RCLRSC für eine andere ACTGRP durchführen.

Wie Dieter schon sagt, wenn ein Commit/Rollback fehlt, muss dieser gefunden werden, da es keine Selbstbehebung gibt außer Jobende.
Das Einzige was da noch hilft ist, den Job zu beenden, mit automatischen Rollback, und einen neuen Job z.B. mit TFRJOB zu starten.
Dazu müsste man allerdings prüfen, per API, ob überhaupt noch ein offener Commit vorhanden ist.

[B.Hauser]

... von all dem genau würde ich die Finger lassen!!!
- commitscope *JOB verändert das Sperrverhalten
- RCLRSC im ILE/OPM Mix ist Murx
- RCLACTGRP mit commit is Murks (schau Dir mal die defaults an)!!!
- von rumprobiererei halte ich grundsätzlich nichts, stattdessen: zu Ende anylysieren und korrigieren.

D*B

@1: es sieht für mich so aus, dass STRCMTCTL vor Aufruf (oder im CL-Programm erfolgt) genauso wie der ENDCMTCTL.
@3:Ich wüsste nicht, dass ich empfohlen habe in dieser Situation den RCLACTGRP zu verwenden (und schon gar nicht in Verbindung mit Commit)

Wenn Du schon auf die Defaults verweist ... die sind auch nicht immer das Gelbe vom Ei.
Außerdem solltes Du mal die Handbücher lesen:
Auszug aus Database Commitment Control (Release 7.5) - Commitment Definition Names:
Original Program Model (OPM) programs run in the default activation group, and by default use the *DFTACTGRP commitment definition. In a mixed OPM and ILE environment, jobs must use the job-level commitment definition if all committable changes made by all programs are to be committed or rolled back together.
...
An opened database file scoped to an activation group can be associated with either an activation-group-level or job-level commitment definition. An opened database file scoped to the job can be associated only with the job-level commitment definition. Therefore, any program, OPM or ILE, which opens a database file under commitment control scoped to the job needs to use the job-level commitment definition.

https://www.ibm.com/docs/en/i/7.5?to...mmitment-names

Außerdem geht hier mal wieder darum eine Lösung für ein aktuelles Problem zu finden.
... und nicht darum wie es theoretisch im optimalen Zustand auf der grünen Wiese laufen würde (nämlich ohne OPM)

[Robi]

Wir hatten, als wir mit ILE/OPM/ACTGRP angefangen haben, das Problem auch.
OHNE Commitment.

[BenderD]

@1: es sieht für mich so aus, dass STRCMTCTL vor Aufruf (oder im CL-Programm erfolgt) genauso wie der ENDCMTCTL.
@3:Ich wüsste nicht, dass ich empfohlen habe in dieser Situation den RCLACTGRP zu verwenden (und schon gar nicht in Verbindung mit Commit)

Wenn Du schon auf die Defaults verweist ... die sind auch nicht immer das Gelbe vom Ei.
Außerdem solltes Du mal die Handbücher lesen:
Auszug aus Database Commitment Control (Release 7.5) - Commitment Definition Names:
Original Program Model (OPM) programs run in the default activation group, and by default use the *DFTACTGRP commitment definition. In a mixed OPM and ILE environment, jobs must use the job-level commitment definition if all committable changes made by all programs are to be committed or rolled back together.
...
An opened database file scoped to an activation group can be associated with either an activation-group-level or job-level commitment definition. An opened database file scoped to the job can be associated only with the job-level commitment definition. Therefore, any program, OPM or ILE, which opens a database file under commitment control scoped to the job needs to use the job-level commitment definition.

https://www.ibm.com/docs/en/i/7.5?to...mmitment-names

Außerdem geht hier mal wieder darum eine Lösung für ein aktuelles Problem zu finden.
... und nicht darum wie es theoretisch im optimalen Zustand auf der grünen Wiese laufen würde (nämlich ohne OPM)

... lies doch bitte Deine eigenen Empfehlungen noch mal in Ruhe durch!
Was die Handbücher betrifft: Der Abschnitt mit dem Trigger ist hier irrelevant, falls die Beschreibung des OP zutrifft, dass im Triggerprogramm nichts geschrieben wird. (und selbst dann, gibt es noch eine andere Variante, die, zugegeben, mehr Komplexität beinhaltet).
Zustände wie der vorgefundene resultieren aus endlosen Basteleien, immer mit dem Argument es geht "darum eine Lösung für ein aktuelles Problem zu finden. ... und nicht darum wie es theoretisch im optimalen Zustand auf der grünen Wiese laufen würde" (O-Ton Birgitta)

Ich bleibe dabei: Man muss sorgfältig überlegen welches Problem man eigentlich lösen muss (saubere Diagnostik), dann muss man sorgfältig überlegen, wie es denn konzeptionell richtig wäre und dann, wie der nächste Schritt in diese Richtung aussieht. Das mag aktuell mehr Aufwand bedeuten, der aber langfristig überkompensiert wird.

D*B

[BenderD]

Wir hatten, als wir mit ILE/OPM/ACTGRP angefangen haben, das Problem auch.
OHNE Commitment.

... Ursache solcher Probleme ist meist der RCLACTGRP. Die Commit Problematik besteht darin, dass der ROLLBACK nicht sauber funktioniert.

D*B

[harkne]

Vielen Dank für die Antworten.
Aber das Problem ist nicht der Commit. Es funktioniert alles.
Das Problem ist der Trigger der die Referenz zu der Datei nicht mehr findet.
Und ich gehe davon aus, weil ich es so im Internet gefunden habe, dass das Problem der RCLRSC ist.
Und ich hatte gelesen dass die DFTACTGRP das Problem ist.
Allerdings hatten wir jetzt seit gestern keinen Fehler mehr. Ich habe nichts geändert, ausser dass ich aus dem CLP ein CLLE gemacht habe und er dadurch die Steuergrenze auf das CLLE gelegt hat im Call Stack.

Sollte der Fehler erneut auftreten, ist es sicherlich sinnvoll den Startprogrammen aus dem Menü raus ein ACTGRP(*NEW) zu geben.

[Fuerchau]

Das kann man auch per Wrapper machen, damit nicht jedes Programm neu erstellt werden muss.
Ein kleines CLLE/RPGLE mit ACTGRP *NEW reicht.
Hier kann der Vorteil genutzt werden, dass die Anzahl und der Typ der Aufrufparameter beliebig sein kann. M.a.W., ich kann 255 Parameter mit char(1) definieren, und jedes xxLE-Programm mit diesen Parametern aufrufen, da es nur ein Call By Reference ist und die Anzahl Parameter nicht geprüft wird. Also auch NULL-Pointer werden einfach durchgereicht.
Alle Commits werden geschlossen, alle Locks aufgehoben und alle Programme werden entfernt.
Ein RCLRSC/RCLACTGRP ist generell nicht mehr erforderlich, was vor allem Trigger stört.

[harkne]

@Fuerchau: Könntest du mir das etwas genauer erklären. Das habe ich nicht verstanden.
Du meinst ein Programm vorher aufrufen, dass mit *NEW erstellt wurde, diesem das Programm per Parameter mitgeben was aufgerufen werden soll und dann das eigentliche Programm aus diesem aufrufen?
Dann müsste ich das Menüprogramm anpassen, dass er nicht das eigentliche Programm aufruft sondern das neue Programm und diesem das Programm als Parameter mit geben.