View Full Version : MCH3402 Get_Random_DB_Record
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.
@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.
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.
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 :-)
Warum macht ihr überhaupt einen RCLRSC?
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)
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.
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
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.
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.