MCH3402 Get_Random_DB_Record

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

[BenderD]

Wenn irgendetwas geschlossen werden soll muss man RCLACTGRP verwenden

Wenn irgendwas geschlossen werden soll, dann schließt man es halt (Datei, offene commit definition, Speicher freigeben, bzw. im richtigen scope definieren, etc.)

RCLACTGRP kann Nebenwirkungen haben, die man nicht bekommt, wenn man die Finger davon lässt!!!

D*B

[B.Hauser]

RCLACTGRP kann Nebenwirkungen haben, die man nicht bekommt, wenn man die Finger davon lässt!!!

D*B

Da Du lieber Dieter immer so auf der optimalen Welt mit sauberen ILE-Konzepten, Datenbanken-Handling und 100% sauberem Aktivierungsgruppen-Design herumreitest ... sollte ein RCLACTGRP einer einzelnen Aktivierungsgruppe kein Problem sein!
... oder ist Dein Aktivierungsgruppen-Design vielleicht doch nicht so 100%.

Ach und falls Du es noch nie gemacht hast ... ich schon und zwar auf alle Arten.

Was man natürlich nicht machen sollte ist ein RCLACTGRP *ELIGIBLE (zumindest nicht in einer Echt-Umbegung) das kann wirklich ungeahnte Folgen haben.

[Fuerchau]

Nunja, ich für meinen Teil kann nur sagen, dass ich RCLACTGRP in aktiven Programmen noch nie benötigt habe.
Beim Debuggen und Abbrechen desselben kann das schon mal manuell erforderich sein.
Wenn dann immer noch Reste rum liegen oder unerwartete Probleme auftreten, hilft auch schon mal, einen neuen Job zu starten.
Danach hat man eine saubere Umgebung und kann neu starten.

Ein RCLACTGRP ist das selbe, wie wenn man einfach die Sicherung aus- und wieder einschaltet als wirklich jeden Lichtschalter einzeln zu betätigen, in der Hoffnung, dass nicht durch das Einschalten der Sicherung vielleicht doch noch irgendwo ein kleines Licht wieder angeht.

Wenn man für die Ursachenforschung keine Zeit hat, wählt man schon mal die pragmatische Lösung.
Vorschlag aus dem Menüsystem:

Call auf ein beliebiges Programm, danach einen TFRJOB ausführen. Die alte Umgebung wird gekillt und das Menüprogramm startet in der neuen Umgebung wieder sauber.
I.d.R. merkt ein User davon gar nichts.
Geschachtelte Menüs kann man auch mit TFRJOB verwalten.

[BenderD]

Ach und falls Du es noch nie gemacht hast ... ich schon und zwar auf alle Arten.

... davon bin ich überzeugt!

Es sei Dir verraten, ich habe sogar den verfemten RCLACTGRP *eligible gemacht, in Testsessions. Bis ich gemerkt habe, dass der mir einen commit untergejubelt hat und mir meine Testdaten verhunzt hat. Reines Glück, dass ich das nirgends in einen Programmablauf eingebaut hatte.

Wo wir doch gerade beim RCLACTGRP *ELIGIBLE sind: was macht der eigentlich und warum sollte man den nicht in einer Echtumgebung machen? Nun, dann will ich mir das mal selber beantworten: RCLACTGRP *ELIGIBLE knallt alle ACTGRPs, die das System für löschbar hält. Das heißt, man könnte den auch ersetzen durch RCLACTGRP xxx, RCLACTGRP yyy, RCLACTGRP zzz usw. Davon gehen einige gut und da kann einer dabei sein, der ungewollte Nebenwirkungen erzeugt. Sei dies (oBdA) RCLACTGRP BIRGITTA. Dann kriege ich doch dasselbe Problem auch mit RCLACTGRP BIRGITTA. Also lasse ich doch, als jemand, der vom richtigen programmieren keine Ahnung hat, das doch gleich ganz bleiben, weil brauchen tut man das nicht wirklich.

D*B