ILERPG und embedded SQL

[B.Hauser]

Hallo.

Vor dem "Ende" kommt ja noch, wie ich bereits geschrieben habt, ein CALL auf ein anderes PGM welches keine inlr = *on hat. Lasse ich das mit dem R... dann bleiben in der interaktiven Session die Dateien offen.
Gruß,
Ralf

Noch ein Grund die Programme in einer benannten Aktivierungsgruppe auszuführen.
Die benannte Aktivierungsgruppe kann dann jederzeit mit RCLACTGRP (NameAktGrp) beendet werden.

[TheDevil]

Hallo.
Habe das mit den Aktivierungsgruppen noch nie benutzt. Kann jemand mir das evtl. in kurzen
Worten beschreiben ...
Gruß,
Ralf

[Fuerchau]

Auch wenn Birgitta da anderer Meinung ist...
Nun, ich wandle ja mit DFTACTGRP(*NO) und ACTGRP(*CALLER).
Wird das Programm von OPM aufgerufen wird es in *DFTACTGRP ausgeführt.
Wird das Programm von ILE mit benannter oder *NEW aufgerufen läuft es halt da.
RCLRSC wirkt sich ausschließlich auf die *DFTACTGRP aus.
RCLACTGRP eben auf alle anderen.
Was die *INZSR angeht, so wird diese natürlich vom Zyklus aufgerufen allerdings merkt sich dieser sowas im statischen Speicher, ergo muss dieser initialisiert sein um INZSR erneut aufzurufen.
Das sind meine persönlichen Erfahrungen.

Die ACTGRP kann Birtgitta sicherlich perfekter erklären als ich.

[Robi]

Stell dir eine ACTGRP einfach wie eine 'gekapselte Laufzeitumgebung' vor.
Innerhalb einer ACT werden Recourcen gemeinsam verwendet, in anderen fängst du wieder von vorne an.
Ein OVR oder das Commit kann auf JOB oder ACT Ebene gemacht werden.

Pgmme werden entweder in
*dftactgrp, in
*caller (d.h. die ACTGRP des rufenden Pgms bestimmt die ACTGRP) in
*new (d.H. es wird IMMER eine neue Laufzeitumgebung gestartet = recht langsam!) oder mit
einem beliebigen Namen gebildet.

Du kannst damit einiges ermöglichen.
U.a. Ist, wenn man *new verwendet, Rekursion möglich (Hoffe du Weist was du tust!)

Robi

[andreaspr@aon.at]

Und nur so als Hinweis am Rande:
Wenn bei Native I/O *INLR = *ON angegeben wird, dann sollte dies immer als eines der ersten Operationen in einem Programm sein und nicht am Ende.
Wenn aus irgendeinen Grund nicht wie vorhergesehen beendet wird, bleiben die ODPs offen da die Zeile mit *INLR = *ON nicht durchgeführt wird.

[BenderD]

... da geht ja wieder mal alles durcheinander.
- SQL Ressourcen werden gecached, wo immer möglich und das ist auch (fast immer) gut so.
- SQL Ressourcen werden mit dem schließen der Connection (zumindest ejtzt noch) freigegeben.
- automatisch erstellte connections (lokale RPG/COBOL embedded SQL) werden bei OPM/pseudo ILE beim RCLRSC und bei true ILE beim RCLACTGRP geschlossen.
- CLOSSQLCSR ENDMOD garantiert weder einen Hard close, noch ist das im richtigen Leben Performance relevant
- offene SQL ODPs können beim ALCOBJ stören, aber dann per CONFLICT(*RQSRLS) beseitigt werden.

D*B

[Fuerchau]

"true ILE" ist mir nun doch neu.
Wenn ich ein ILE-Programm mit ACTGRP(*CALLER) vom OPM aufrufe ist es dann kein ILE?
Aber wenn ich es aus einer ACTGRP aufrufe dann auf einmal doch?
Wird das Programm neu kompiliert?

Was i.Ü. die Rekursion von Aufrufen angeht so ist das per NOMAIN (oder so) und Funktionen besser und effektiver zu lösen als mit ACTGRP(*NEW).
Das funktioniert nun sogar in COBOL.

[B.Hauser]

Was ich nicht verstehe, warum lest Ihr eigenlich nie die Dokumentation bzw. selbst wenn man Ausschnitte aus der Dokumentation bringt werden diese noch ignoriert!

Nochmal für alle zum Mitschreiben:

1. Alle Programme, die mit Default-Aktivierungsgruppe DFTACTGRP(*YES) umgewandelt wurden sind OPM-Programme und verhalten sie wie solche. Beim RCLRSC werden diese aus dem Speicher entfernt.

2. Alle Programme, die mit Default-Aktivierungsgruppe DFTACTGRP(*NO) umgewandelt wurden sind ILE-Programme. ILE-Programme können nur durch das Schließen der Aktivierungsgruppe (RCLACTGRP), in der sie aktiviert wurden, aus dem Speicher entfernt werden.
RCLRSC hat auf die (benannten/*New) Aktivierungsgruppen keinen Einfluss.

3. Werden Programmemit Default-Aktivierungsgruppe DFTACTGRP(*NO) und Aktivierungsgruppe *CALLER von einem OPM-Programm aufgerufen, laufen diese ILE-Programme in der Default-Aktivierungsgruppe.
Wie zuvor gesagt kann ein ILE-Programm nur durch Schließen der Aktivierungsgruppe aus dem Speicher entfernt werden. Die Default-Aktivierungsgruppen können nur durch Beenden des Jobs beendet werden.
RCLRSC wirkt nur auf die Default-Aktivierungsgruppen und bewirkt dabei, dass die mit Return beendeten Programme (unabhängig davon ob ILE oder OPM) beendet werden. Ebenso werden alle für native I/O geöffneten Dateien in OPM und ILE Objekten (also auch Service-Programme, die in der Default-Aktivierungsgruppe laufen) geschlossen.
Aber da ILE-(Service-)Programme nur durch das Beenden der Aktivierungsgruppe komplett aus dem Speicher entfernt werden können, werden zwar die Dateien geschlossen, die Objekte bleiben weiterhin im Speicher und der statisch reservierte Speicherbereich für Variablen bleibt erhalten. Beim erneuten Aufruf werden die Variablen neu initialisiert.
Dieses Verhalten mag vielleicht bei echten Programmen keine Probleme darstellen, bringt aber rieseige Probleme, wenn Service-Programme (mit F-Bestimmungen) in der Default-Aktivierungsgrupe ausgeführt werden und dann die Dateien durch RCLRSC geschlossen werden.

Aus Erfahrung, kann ich sagen, dass viele Firmen (z.T. auch weil sie FALSCH beraten wurden) spätestens dann, wenn sie anfangen wollen Service-Programme richtig einzusetzen massive Probleme bekommen.

Deshalb gilt eigentlich die Regel (und damit stehe ich nicht allein, da kann ich jede Menge bekannter Größen z.B. Barbara Morris, Jon Paris, Susan Gantner, Scott Klement, Charlie Guarino, Bob Cozzi etc. ins Rennen schicken):
ILE-(Service-)Programme sollten in einer benannten Aktivierungsgruppe ausgeführt werden.

Solange man noch nicht alles 100% im Griff hat, genügt es sich für eine Aktivierungsgruppe z.B. QILE oder irgende einen anderen Namen (z.B. Firma-Namen), durch den Probleme mit Programmen, von anderen Firmen, die Ihre ILE-Programme ebenfalls in der QILE ausführen, vermieden werden.
Wenn man dann (zumindest am Anfang) den Override Scope und den Commitment Scope auf *JOB setzt, ziehen auch die Overrides, die z.B. in OPM-Programmen gesetzt wurden korrekt. Nach- und nach sollte man dann die Overrides auf *CALLLVL umsetzen, d.h. der Override gilt nur für den aktuellen Callstack.

Seit Release 6.1 ist es auch so, dass Programme mit sogenannten Linearen Main-Prozeduren erstellt werden können. Schlüssel-Wort MAIN in den H-Bestimmungen, die im Zusammenhang mit dieser Prozedur genannte Prozedur wird direkt aufgerufen. Bei "normalen" Main-Prozeduren wird immer der RPG Zyklus integriert, der einen rekursiven Aufruf (innerhalb der gleichen Aktivierungsgruppe) verhindert.

Bei linearen Main-Prozeduren wird der RPG-Zyklus nicht integriert, deshalb kann z.B. auch keine *INZSR integriert werden. Da der Zyklus nicht integriert wurde, können auch Programme innerhalb der gleichen Aktivierungsgruppe rekursiv aufgerufen werden.

Birgitta

[BenderD]

Deshalb gilt eigentlich die Regel (und damit stehe ich nicht allein, da kann ich jede Menge bekannter Größen z.B. Barbara Morris, Jon Paris, Susan Gantner, Scott Klement, Charlie Guarino, Bob Cozzi etc. ins Rennen schicken):
ILE-(Service-)Programme sollten in einer benannten Aktivierungsgruppe ausgeführt werden.

Birgitta

... da fallen mir spontan die Millionen Fliegen ein...
Es stimmt ja alles, was Du über den Mix sagst und das der problematisch ist, deshalb muss man auch davon weg, aber das Rezept, das Du da anbietest, das würde ich keineswegs empfehlen (vielleicht hast Du Dich auch unklar ausgedrückt?).
Serviceprogramme sollten in ACTGRP *CALLER laufen, ansonsten lassen sie sich nicht Commit fähig machen und auch nicht deaktivieren (RCLACTGRP). Für die DFTACTGRP (in reality eine OPM compatible ILE Ablaufumgebung) kann das bedeuten, dass man sie über einen PGM wrapper aufruft (der dann eine benamte ACTGRP hat), oder dass man keine F Karten ablocht, oder dass man Dateien user controlled öffnet. Oder versucht Programmierung im wilden Mix zu entgehen, was für Nicht-Freelancer schwierig sein kann.

D*B

[Fuerchau]

Ich weiß ja gar nicht, warum Birgitta sich so aufregt.
Ich habe ja nichts falsches gesagt da ich mit DFTACTGRP(*NO) umwandle.
Allerdings ist bei DFTACTGRP(*YES) das Programm in der QILE-ACTGRP die ich sehr wohl per RCLACTGRP löschen kann. Warum soll das, auch wenn es in der Doku steht, nun kein ILE sein?
Ich kann auch in QILE beliebige Serviceprogramme und sonstige ILE-Programme und Funktionen laufen lassen. Man benötigt halt nur keinen eigenen Namen.

Und Birgitta bestätigt mich ja nur, dass RCLRSC auf die *DFTACTGRP wirkt und somit auch ILE-Programme, die ja per *CALLER genau auch hier laufen, ebenso aus dem Speicher gekillt werden.

[andreaspr@aon.at]

Ich glaube dass alle Standpunkte klar erklärt wurden und jeder Leser sich schlussendlich selbst entscheiden kann welche Richtung er einschlagen will.
Bzw. gibt es zu diesem Thema ja auch noch genug andere Beiträge in diesem Forum die ähnlich verlaufen sind.