Aktivierungsgruppen

[Schorsch]

Hallo,
hat jemand Literatur zum Thema Aktivierungsgruppen?

Danke.
Schorsch

[BenderD]

Hallo Schorsch,

ILE Concepts

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

[Martin]

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!)

[Robi]

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

[BenderD]

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]

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

[BenderD]

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

[Martin]

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

[BenderD]

@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

[Fuerchau]

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.

[Martin]

Hallo Dieter,

@Martin
Auf die Gefahr mich heute nochmal unbeliebt zu machen:

Wieso nochmal? Ist das heute denn schon passiert?

Ich dachte an Anwendungen wie die folgende: Die Stücklistenpositionen eines Artikels werden angezeigt. Einige Positionen sind Rohwaren, andere sind Zwischenprodukte. Mit z.B. Auswahl "S" zeigt man die Stücklistenpositionen eines Zwischenproduktes an und landet somit wieder in demselben Subfileprogramm aber anderen Daten.

Bei uns sind solche Subfiles generell nur anzeigende Dialoge, die keine Daten fortschreiben. Aber selbst wenn man auf diese Weise einen bereits zur Bearbeitung geladenen Datensatz ein zweites Mal öffnen möchte, ist das doch im Grunde dasselbe Problem, das man bei konkurrierendem Zugriff im Mehrbenutzerbetrieb ohnehin über geeignete Lockingmechanismen lösen muß.

Gruss,
Martin

[BenderD]

@Baldur,

ACTGRP *NEW wird bei Rückgabe der Steuerung eins hoch automatisch reclamed, da passiert also nix und *eligible kann nix löschen, was mit *NEW erstellt wurde (ist schon weg, oder noch im aktiven Callstack).
Heisst auch, dass bei erneuten Aufruf neu aktiviert wird.

@Martin,

In eurem Fall ist das reine Anzeige, die sich nix merkt, aber um den Preis, dass bei hin und herspringen zwischen den beiden Anzeigen immer wieder neu gelesen werden muss und man muss im Programm irgendwie verwalten, dass man sich nicht hochschraubt.

Sobald jemand zum Beispiel zweimal in denselben Satz mit ändern reinkäme wird es kraus. Die spätere Version wird gespeichert und wenn man jetzt mit F12 sukzessive raus geht, taucht die alte Version wieder auf.

Grundproblem von ILE ist, dass man (fast) nicht steuern kann dasselbe Modul mehr als einmal zu aktivieren; in Java z.B. würde man dasselbe Problem niemals rekursiv lösen wollen, weil man da exakt steuern kann, wieviele Objekte einer Klasse man gerade haben will.

mfg

Dieter Bender