Aktivierungsgruppen

[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

[Fuerchau]

Wie wars jedoch ehedem
mit OPM doch so bequem !

Wer erinnert sich noch daran, das Rekursiv-Aufrufe in RPG abgelehnt in COBOL jedoch zugelassen wurden ? Wobei in COBOL dann aber der PERFORM-Stack kaputt war !

@Dieter

was macht das System bei *NEW wenn ich *INLR aus lasse ?!
(hab keine Lust zu testen)

[BenderD]

Hallo Baldur,

das mit dem ILE ist nicht so unbequem, wenn man es sich leicht macht, siehe oben.
*INLR hat bei ACTGRP *NEW keinerlei Einfluss und ansonsten lässt man am Besten die Finger von *INLR, arbeitet mit benamten ACTGRP und macht dann eben einen RCLACTGRP, wenn man bereinigen will.
Ich glaube ich muss doch mal einen Artikel über Activation Groups schreiben und wie man sich mit ILE Probleme vom Hals hält, die keiner brauchen kann (aus meiner Kiste RPG für Java Programmierer).

mfg und schönes Wochenende für *ALL

Dieter Bender

Wie wars jedoch ehedem
mit OPM doch so bequem !

Wer erinnert sich noch daran, das Rekursiv-Aufrufe in RPG abgelehnt in COBOL jedoch zugelassen wurden ? Wobei in COBOL dann aber der PERFORM-Stack kaputt war !

@Dieter

was macht das System bei *NEW wenn ich *INLR aus lasse ?!
(hab keine Lust zu testen)