View Full Version : Aktivierungsgruppen
:confused:
Hallo,
hat jemand Literatur zum Thema Aktivierungsgruppen?
Danke.
Schorsch
Hallo Schorsch,
ILE Concepts
:confused:
Hallo,
hat jemand Literatur zum Thema Aktivierungsgruppen?
Danke.
Schorsch
Aber wieso Literatur? An dem Thema ist nicht viel dran, das meiste findet man, wenn man alle OS400 Commands sucht, die einen Parameter Activation Group haben:
RCLACTGRP =>
Eine AG ist eine Bereinigungseinheit.
STRCMTCTL =>
Eine AG hat einen eigenen Commit Scope (entspricht einer DB connection)
OVRxxx =>
Eine AG hat einen eigenen OVR Scope (sowas macht man nicht!)
CRTPGM, CRTSRVPGM =>
Eine Activationgroup ist eine Eigenschaft eines Programmes oder Service-Programms.
Bei den Parameterwerten sind die special Values interessant:
*NEW wird automatisch aktiviert und sofort wieder deaktiviert (sowas nimmt man nicht!)
*CALLER nimmt die AG des Aufrufers (nimmt man für SQL Programme, die nicht Commit steuern)
Default Activation Group kann lein ILE (sowas nimmt man nicht)
Bleibt als Essenz: man verwende benamte Activation Groups, am einfachsten ACTGRP = Programmname für jedes dynamisch aufgerufene Programm, soweit man keine anderen Anforderungen (COMMIT) hat.
mfg
Dieter Bender
Hallo,
wir setzen *NEW für rekursiv aufrufbare Programme ein. Gibt es dazu Alternativen oder ist es in dem Fall o.k.?
Gruß,
Martin
*NEW wird automatisch aktiviert und sofort wieder deaktiviert (sowas nimmt man nicht!)
Hi,
* new für rekursion is ok, nemen wir auch
Wir nehmen auserdem fast immer *caller,
Wir haben ein Pgm das immer vom Menü gerufen wird und als Durchreicher dient. Das läuft in *new. Ab dann alles in *caller, ausser Rekursionen und bestimmte 'Besonderheiten' die ovr's setzen oder gesetzte ovr's umgehen müssen.
(@Dieter: mann macht das, wenn' unbedingt nötig ist)
Angeblich ist *caller schneller als immer eine neue (mit namen des PGM's oder automatisch) aufmachen zu müssen. Achtung bei *caller ggf. verschiebst du bei lesevorgängen den Datei - Zeiger des rufenden Programmes
Gruß
Robi
Hallo Martin,
das sind gleich zwei Fragen
1. es gibt Alternativen, nämlich einfach eine Procedure rekursiv aufrufen.
2. Rekursion ist nur selten OK, meist gibt es Alternatven, die dasselbe leisten und weniger riskant sind. Mit Rekursion kann man in einem Loop eine AS400 sogar in die Knie zwingen, wenn man es clever anstellt.
mfg
Dieter Bender
holgerscherer
23-04-04, 15:12
Hallo Martin,
Mit Rekursion kann man in einem Loop eine AS400 sogar in die Knie zwingen, wenn man es clever anstellt.
Hallo Dieter,
das erste mal, dass ich Deinen (hervorragenden) Ausführungen widersprechen muss:
Für einen Loop, der die AS/400 in die Knie zwingt, muss man nicht zwingend clever sein ;-)
-h
Hallo Holger,
Hallo Dieter,
das erste mal, dass ich Deinen (hervorragenden) Ausführungen widersprechen muss:
Für einen Loop, der die AS/400 in die Knie zwingt, muss man nicht zwingend clever sein ;-)
-h
eigentlich wollte ich ja "blöd anstellt" schreiben, aber wer weiss wer sich dann angesprochen gefühlt hätte...
Dieter
Hallo Dieter,
Hallo Martin,
das sind gleich zwei Fragen
1. es gibt Alternativen, nämlich einfach eine Procedure rekursiv aufrufen.
2. Rekursion ist nur selten OK, meist gibt es Alternatven, die dasselbe leisten und weniger riskant sind. Mit Rekursion kann man in einem Loop eine AS400 sogar in die Knie zwingen, wenn man es clever anstellt.
mfg
Dieter Bender
wir haben ja nicht vor, die Fibonacci-Zahlen rekursiv zu berechnen. Es geht eher um Subfile-Dialoge, die über diverse Quersprünge mehrfach aufgerufen werden können. Es ist dann ohnehin auf jeder Rekursionsstufe eine Benutzerinteraktion erforderlich. Es müßte also jemand sehr fleißig arbeiten, bis der Rekursionsstack überläuft.
Was Rekursion im Allgemeinen angeht, so denke ich schon, dass es sehr viele Fälle gibt, wo sie sinnvoll anzuwenden ist. Beispiel: Operationen auf binären Suchbäumen. Allerdings stimme ich zu, daß diese Aufgaben in der täglichen Praxis der AS/400-Datenbankprogrammierung selten vorkommen.
Im übrigen sehe ich es so ähnlich wie Holger: auch bei nicht rekursiver Programmierung ist es nützlich, zu wissen was man tut.
Gruss,
Martin
@Martin
Auf die Gefahr mich heute nochmal unbeliebt zu machen:
Ich halte gerade das Subfile Beispiel für einen Fall, den man nicht mit Rekursion lösen sollte und zwar nicht wegen der Endlosloop Problematik, sondern wegen einer anderen Problematik, nennen wir die mal Phoenix_aus_der_Asche_Problem.
Wenn ich das Ganze richtig verstehe drückt jemand F4 um sagen wir mal in der Auftragsverwaltung einen Artikel auszuwählen, dann im Artikel wieder F4 um einen Lieferant auszuwählen dann wieder F4 ....
Das Problem, wenn man das mit Rekursion macht ist nun, wenn jetzt dieselbe Liste doppelt im Stack liegt, taucht irgendwann beim zumachen des Stacks ein alter Inhalt auf, den der Benutzer oberhalb eigentlcih überschrieben hatte...
Das strukturelle Problem wenn man dies mit Rekursion löst resultiert daraus, dass man mit Rekursion nur steuern kann, wann eine Ebene geöffnet wird und nicht, wann sie geschlossen werden soll (mit ACTGRP *new ist das genauso, Aktivierung kann man steuern, Deaktivierung nicht).
Korrekt angepackt müsste die verzweigende Logik flach sein und die einzelnen Listmodule in einen Daten und Subfileteil getrennt sein; der Datenteil müsste gegeben Falls dann dazu in der Lage sein sich mehr als eine Liste zu merken (einmal Kunde, einmal Liferant, einmal Artikel...) wenn dasselbe Subfile Programm für alle Listen verwendet werden soll.
mfg
Dieter Bender
Bei ILE-RPG ist das sogar noch so gemein, dass LR zwar das Modul (Hauptprogramm) aber nicht die Aktivierungsgruppe aufhebt !
Wenn also nicht ab und an mal ein RCLACTGRP durchgeführt wird, läuft irgendwann der Jobspeicher über (auch wenn er sehr groß ist).
Nur, bei *NEW ist der NAme der Gruppe ja nicht bekannt, also wählt man *ELIGIBLE und dies geht ggf. auf die Performance, da auch z.zt. inaktive Gruppe(n), die man eigentlich aktiv halten wollte, geschlossen werden !
Was passiert eigentlich, wenn man aus der Ebene x ein Programm mit *NEW aufruft (also Ebene x+1), dieses kehrt zurück (egal ob LR = *ON/*OFF) und Ebene X ruft das selbe Programm erneut auf ?
Anwender merken sich ja nicht immer, was sie sich gerade mit F4 angeschaut haben.