MCH3402 Get_Random_DB_Record

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

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

[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

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

[Fuerchau]

Genau richtig verstanden.
Vorteil: du musst nur 1 Programm anpassen und nicht alle.
Voraussetzung: Verabschiedung von OPM, also nur noch CLLE und ILERPG, da OPM immer in der DFTACTGRP läuft.
Mittels CVTRPGSRC kann man OPM's simple auf ILE umstellen ohne 1 Zeile Code zu verändern.
Nachteile: keine.

Wobei ACTGRP *NEW langfristig nur 1 Umgehungslösung ist, dir aber Zeit verschafft.

[harkne]

RPGs haben wir keine alten Programme mehr nur ILE.
Nur CLs gibts noch ne Menge CLP. Also CVT brauche ich nicht.
Vielen Dank für die Antwort.
Das Programm ist jetzt doch wieder abgestürzt mit dem selben Fehler, also doch ACTGRP(*NEW)
Ich hatte Hoffnung die Änderung in CLLE würde reichen :-)

[Fuerchau]

Warum macht ihr überhaupt einen RCLRSC?

[B.Hauser]

RPGs haben wir keine alten Programme mehr nur ILE.
Ich hatte Hoffnung die Änderung in CLLE würde reichen :-)

Nein reicht nicht! Das Programm darf nicht in der Default-Aktivierungsgruppe laufen, ... sonst ist es weiterhin SQL. Das CL in einer benannten Aktivierungsgruppe ausführen, dann sollte auch der Rest klappen.

... und noch was RCLRSC ist tödlich für ILE-Objekte. Wenn irgendetwas geschlossen werden soll muss man RCLACTGRP verwenden (wobei das hier diverse "Besser-Informierte" als Murks bezeichnen)

[Fuerchau]

Tja, so ist das wenn man mit Triggern arbeitet.
Trigger werden durch RCLACTGRP nicht rausgeschmissen aber Opens werden gekillt.
Beim nächsten Trigger-Aufruf stirbt dieser, da Opens nicht wiederholt werden.
Auch wenn man den Open-Status abfragt funktioniert das nicht, da die interne RPG-Runtimevariable eben nicht initialisiert wird.

Deswegen ist die Verwendung von RCLACTGRP eben mindestens bei der Verwendung von Triggern Murks.
Auch ansonsten kann ich Dieter da nur zustimmen, denn diesbezüglich habe ich genauso schlechte Erfahrungen damit, wie es auch dieser thread beweist.

Anstelle also RCLACTGRP zu verwenden, sollte man die Ursache herausfinden, warum man das für nötig erachtet und wie es zu beheben ist.

Dazu zwei Dinge:
- Zyklus braucht eigentlich heute keiner mehr, daher sollte man grundsätzlich eine Main-Prozedur verwenden.
- In der Main-Funktion sollte man alles in eine Monitor-Gruppe fassen und Fehler protokollieren um Abstürze zu verhindern.

Bei den alten OPM's reichte schin immer ein RCLRSC.