Aktivierungsgruppen verstanden?

[cid0m]

Servus mitprogrammierer!

ich wollte einmal sichergehen das ich das Prinzip der Aktivierungsgruppe richtig verstanden habe, dafür sollte hier ja der optimale Ort sein.

Aktivierungsgruppen sind Speicherbereiche wo Variablen initialisiert werden, das bedeutet innerhalb eines Speicherbereichs wird der nötige Speicher z.B. für eine INT Variable reserviert und bereitgestellt.

Es gibt die dfltactgrpg, wo alles reinläuft was nicht ausdrücklich anders angegeben wird.
Dann gibt es die actgrpg(*new), da wird bei Programmstart eine neue Aktivierungsgruppe erstellt, welche dann die im Programm benötigten Variablen reserviert und bereitstellt. Beim beenden des Programmes wird dieser Speicherpool dann wieder komplett freigegeben.

Bei der Aktivierungruppe(*caller) bekommt das aufgerufene Serviceprogramm den gleichen Speicherpool wie das Programm welche das Serviceprogramm aufgerufen hat.

dftacggrp sollte man nicht nutzen da dann alle Variablen aller Programme drin laufen und es anscheinend Probleme geben kann. Man sollte immer für Hauptprogramme die *new Aktiverungsgruppe nehmen und für Serviceprogramme dann die *caller.

Ist das so korrekt? Ich weis für euch erfahrenen Hasen ist das sicher alles ziemlich simpel, doch ich komme aus dem C#/ASP.net Bereich und bin ganz frisch in der RPG Welt und für mich ist vieles verwirrent, besonders weil ich in der RPG Reference keine Anhaltspunkte finde, da heißt es nur das gibt es und nutzte es quasi wie du willst.

Liebe Grüße aus Berlin

[Fuerchau]

Die Technik stimmt partiell, aber das Wesen der ACTGRP ist hier nicht verstanden.
Zwar gehen die Meinungen etwas auseinander aber du darfst verschiedene Begriffe nicht durcheinander bringen.
Der Speicher eines Programmes ist unabhängig von der ACTGRP. Hier gibt es statischen Speicher, der bestehen bleibt, wenn das Programm "aktiv" verlassen wird (*INLR=*OFF) und dynamischen Speicher der z.b. in Prozeduren beim Eintritt initialisiert wird und beim Return wieder freigegeben wird.
Mit Pointern kann man lustig quer beet arbeiten, man fällt aber ohne Konzept dann auf die Nase.

Die ACTGRP dient zur Verwaltung von weiteren Ressourcen.
Hier gehört ins besonders die Commit-Definition dazu, da man in einer Commitdefinition nur in einem Journal aufzeichnen kann und es Gründe geben kann, dies zu trennen (verschiedene Anwendungen).

Dei Laufzeit von RPG, ILERPG und CBLLE (COBOL) erlauben keine Rekursion von Hauptprogrammen, das sollte man vernünftig in Serviceprogrammen machen da diese rekursiv aufrufbar sind.
Um das zu umgehen wird gerne *NEW verwendet.
Da das aber etwas länger dauert (Millisekunden), sollte man dies nicht zu häufig in engen Zeitabständen machen, ansonsten ist das auch unkritisch.

Schwierig wird es dann, wenn man anfängt zu mischen.
OPM-Programme werden grundsätzlich in der DFTACTGRP ausgeführt und sind natürlich aus ILE ebensoo aufrufbar. Diese können dann ggf. nicht auf die richtigen Ressourcen zugreifen und reagieren gf. unerwartet.

Ich glaube so richtig verstanden wozu man dies effektiv nutzen kann hat das sowieso niemand.
In anderen Welten kommt man ohne so etwas aus da man dort objektorientiert arbeitet so dass Ressourcen gekapselt werden können.
Im Wesentlichen werden ACTGRP's nur benutzt um die fehlende Sprachenunterstützung zu umgehen.

[BenderD]

... C# ist nicht meine Heimatbaustelle, aber das ist ja ziemlich analog zu Java.
- DFTACTGRP ist OPM und das lässt man besser bleiben - Altlasten.
Fangen wir mal an mit *PGM und *SRVPGM:
- beides Klassen, *PGM mit Main, *SRVPGM ohne main.
- im Gegensatz zu C# und Java, hat RPG/COBOL keinen new Operator, die "Erzeugung", die man auf der AS/400 "Aktivierung" nennt, geschieht automatisch bei der ersten Verwendung.
- erzeugt werden Objekte pro ACTGRP
- ACTGRP *NEW sind Einmalobjekte, die abgeräumt werden, sobald man die zuerst aufgerufene Procdure (= Methode) verlässt.
- alle anderen ACTGRPs existieren, bis jemand das beendet - spätestens wenn der JOb endet, ist Schluss. Beendet wird mit CL Befehl RCLACTGRP (Vorsicht, hier waren Deppen am Werk - offene Transaktionen werden per default committed).

- Jetzt gibt es schon ein paar Schlussfolgerungen:
- ACTGRP *new sind ex und hopp Objekte
- named ACTGRP kann es nur 1 Objekt geben (sind also alle class Variablen faktisch static!!!=
- ACTGRP *CALLER kann es mehrere Objekte zur Laufzeit geben, ist aber kaum steuerbar.

Jetzt komen noch ein paar nette Fallstricke:
- mit embedded SQL darf man nicht connecten, das geht auch automatisch, also wieder nur einmal pro Objekt.
- Ebene des Connects ist die ACTGRP, alles, was in eine Transaktion gehört, muss also in derselben ACTGRP stattfinden.
- mit RCLACTGRP wird alles im Callstack drunter abgeräumt, alles was oben drüber war, geht bei der nächsten Verwendung schief (Pointerfehler).

Bevor man das wirklich verarbeitet und verinnerlicht hat (manche lernen's nie und spielen trotzdem damit rum!), sollte man sich auf ein paar wenige Dinge beschränken:
- SRVPGM *CALLER
- Programme ACTGRP(Programmname)
- kein OPM ILE mix
- kein OVRDBF und OVRPRTF (falls Du das nicht kennst, bleibe dabei!)

D*B

[cid0m]

Danke euch beiden, da lag ich ja noch ganz schön daneben....komplexer als ich dachte!
Ich halte mich dann erstmal einfach an die letzten 4 Punkte von D*B, damit fahre ich zu Anfang dann sicher am besten.

Nochmals Danke, gerade der Bezug von D*B zu Java hat mir doch noch gut geholfen.

[c1n1m0d]

Noch eine kurze Frage zum Thema OVRDBF und OVRPRTF.(hoffe OT geht klar)
Ich weiß das man diese am besten mit extfile angibt, so wird das jedenfalls bei uns teilweise gehandhabt, aber wieso ist das der Fall. Soweit ich das verstehen überschreibe ich ja mit diesen Befehlen quasi eine Referenz auf eine Datenbank auf eine andere, ist das so schlimm?

Ich hoffe das ist OK das ich den Thread kaper, cid0m scheint ja durch zu sein und so muss ich keinen eingen Thread aufmachen. Falls das nicht OK ist tut es mir leid, dann werde ich eine neue Anfrage aufmachen.

[BenderD]

... das hat gleich mehrere Nachteile, die man sich ersparen kann:
- Cross Referenztools werden genarrt
- der Parameter OVRSCOPE wirkt im default auf ACTGRP
- bei record level access (wovon man weg sollte!) gibt es da noch den Unfug OVRDBF mit SHARE(*YES)
- bei SQL funktioniert das alles wieder anders
Summa summarum ist das eine der Hauptfehlerquellen für seltsame Effekte, nach deren Ursache man dann lange sucht. Für Datenbank Objekte gibt es bessere Alternativen, bzw. ist das überflüssig (warum nenne ich das Hugo, wenn ich Otto meine) oder schädlich (überschreiben von Eigenschaften).
Für Druckersteuerung (OVRPRTF auf bestimmte OUTQ) etc. mag das ja noch angehen, aber auch da gibt es m.E. bessere Alternativen.

D*B

[Fuerchau]

OVR's sind tatsächlich ein Problem, zumal diese gerne in einem CLP statt CLLE gemacht werden. Durch den Default ACTGRP wird das dann in der DFTACTGRP statt in der eigenen durchgeführt.
SHARE(*YES) musste ich für eine Anwendung explizit per OVRDBF wieder auf SHARE(*NO) ändern. Die Anwendung macht den SHARE(*YES), weil die Programmierer die Übersicht verloren hatten wann eine Datei nur I oder eben auch mit U geöffnet wurde.
Die SHARE-Option wirkt tatsächlich nicht auf SQL.

Ein OVRDBF wirkt allerdings auch auf SQL!
Hier scheitert dann manche "Sicherheitssoftware", die über die REGINF sich in die SQL-Überwachung reinhängt um SQL's zu analysieren, dabei aber das "Umleiten" per OVRDBF oder "CREATE ALIAS" vergessen.
Möchte man sich den OVRDBF in SQL sparen, so sind hier die Möglichkeiten eher eingeschränkt.
Entweder man arbeitet mit ALIAS-Tabellen oder mit dynamischem SQL, wobei hier Parameter wieder komplizierter sind.
Da ist ILERPG flexibler, da ich den Datei- und sogar den Teildateinamen in einer Variablen definieren kann.

Was den Druckoutput angeht, so gibt es hier nur geringe Alternativen.
Der OVRPRTF hat sich da i.W. durchgesetzt, da in einer Anwendung hier sehr viele Möglichkeiten definiert werden können (Output-Management) die sich anders nicht lösen lassen.
Im Gegensatz zur DB gibt es auch einige Formulareinstellungen die man anders nicht dynamisieren kann.
Hier sollte man halt generell mit OVRSCOPE(*JOB) arbeiten, da eine PRTF doch sehr programmspezifisch ist, ist das im Sinne der ACTGRP's eher unkritisch.

[BenderD]

Möchte man sich den OVRDBF in SQL sparen, so sind hier die Möglichkeiten eher eingeschränkt.
Entweder man arbeitet mit ALIAS-Tabellen oder mit dynamischem SQL, wobei hier Parameter wieder komplizierter sind.
Da ist ILERPG flexibler, da ich den Datei- und sogar den Teildateinamen in einer Variablen definieren kann.

... wer das braucht, ist Teil des Problems!!! Eine Datenbank ist eine Datenbank und normalerweise wird das beim connect erledigt, an welche Datenbank man denn nun verbinden will. Beim embedded SQL darf man nun mal nicht connecten, da muss man das ganz zu Beginn erledigen (SET SCHEMA bei naming *SQL, bzw. Einstellung des LIBL, wenn man denn unbedingt nicht nach SQL Standard arbeiten will).
Braucht man connects zu mehreren Datenbanken, verwendet man entweder CLI im Server Mode, oder in der technisch einfacheren Variante verschiedene ACTGRPS.

D*B

[Fuerchau]

Ich dachte da auch weniger an verschiedene Datenbanken (RDB's) sondern doch an verschiedene Tabellennamen in derselben DB mit jedoch identischem Aufbau.
Dies kommt in Anwendungen durchaus vor und wird bei RLA eben mit OVRDBF gelöst.

[BenderD]

... wofür soll das gut sein? Aber wenns denn Spass macht, gibt es da ja dynamic SQL.

Dieter

[Robi]

Moin,
in Umgebungen in denen es klare Programmierregeln gibt, eine brauchbare Doku gemacht wird und das Einhalten der Regeln auch weitestgehend durch Software geprüft wird, ist das alles nicht so schlimm!

Wenn im Betrieb immer wieder verschiedene Entwickler mal ein Projekt realisieren und danach durch andere ausgetauscht werden, sollten solche Konstrukte vermieden werden.
Nur, wie bewerkstelligt man das, wenn jeder sein eigener Gott und nur für sein Thema verantwortlich ist?

Meiner Erfahrung nach gibt es für fast alles was möglich ist auch eine 'einigermaßen' sinnvolle Anwendung.
Und natürlich eine 'einigermaßen' sinnvolle Alternative.