View Full Version : ILERPG und embedded SQL
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
Bei Serviceprogrammen mag das mit den Aktivierungsgruppen ja stimmen, bei normalen Programmen stimmt das so aber nicht.
Ich habe viele OPM-Programme per CVTRPGSRC in "ILE" überführt um bestimmte Vorteile zu nutzen (%builtin's, bessere Tabellen, mehr Speicher) ohne am Grundsatz der Programme was zu ändern.
Dies sind sicherlich keine Service-Programme und beenden sich häufig mit *INLR = *OFF.
Ob die Dinger nun aus dem Hauptspeicher entfernt werden oder nicht lässt sich nun mal nicht prüfen (da gabs früher mal Programme, ob es die heute noch gibt...), aber nach einen RCLRSC und erneutem Aufruf des Programmes wird die *INZSR wieder aufgerufen und alle Dateien wieder geöffnet.
Wir wollen jetzt keine Grundsatzdiskussion durchführen, aber ein Programm von RPGIII nach RPGIV zu konvertieren und im Anschluss daran zu kompilieren, macht daraus noch KEIN ILE Programm.
Auch wenn der ILE-Kompilier zur Umwandlung verwendet wird.
Programme, die direkt in der Default-Aktivierungsgruppe erstellt werden, sind OPM und keine ILE-Programme. Nur Programme, die mit DFTACTGRP(*NO) kompiliert sind, sind ILE-Programme.
ILE-Ojekte werden mit RCLRSC NICHT aus dem Speicher entfernt.
Ob *INZSR aufgerufen wird oder nicht hat mit "Entfernen aus dem Speicher" nichts zu tun, sondern mit dem RPG Cycle.
... und in dieser Hinsicht glaube ich, was zum einen in der Dokumentation steht und mir zum anderen Barabara Morris erzählt hat.
Hier übrigens ein Auszug aus den ILE-Konzepten:
Reclaim Resources Command for OPM Programs
The Reclaim Resources (RCLRSC) command may be used to close open files and free static storage for OPM programs that have returned without ending.
Reclaim Resources Command for ILE Programs
For programs that are created by the CRTBNDRPG and CRTBNDCL commands with
DFTACTGRP(*YES) specified, the RCLRSC command frees static storage just as it does for OPM programs.
For programs that are not created by the CRTBNDRPG or CRTBNDCL commands with
DFTACTGRP(*YES) specified, the RCLRSC command reinitializes any activations that have been created in a default activation group but does not free static storage.
Birgitta
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.
Hallo.
Habe das mit den Aktivierungsgruppen noch nie benutzt. Kann jemand mir das evtl. in kurzen
Worten beschreiben ...
Gruß,
Ralf
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.
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
15-02-16, 16:37
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.
... 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
"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.
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