ILERPG und embedded SQL

[TheDevil]

Hallo Brigitta.

Normalerweise beende ich "meine" ILE auch "nur" mit *inlr = *on. Allerdings wird in diesem
ILE ein anderes RPG aufgerufen was KEINENE *inlr hat (warum weiß der Geier). Somit sind
alle Dateien dieses aufgerufenen Programms in meiner Session noch offen. Somit ein objlck.
Somit auch kein clearen möglich (wir sind noch in der Entwicklung und da setzte "man" ja
öfter DB zurück).

Auch in andere PGM´s wird im "Hauptprogramm" dieses RCLRSC "gemacht".

Dies ist der Grund :-)

Gruß aus Flensburg
Ralf

[Fuerchau]

Dies funktioniert beim ILE auch wenn man folgendes in der H-Zeile beachtet:
DFTACTGRP(*NONE) ACTGRP(*CALLER)
Dann hat der RCLRSC in der OPM-Umgebung auch Wirkung auf die ILE-Programme da diese aus der *DFTACTGRP (Siehe DSPJOB) auch rausgeschmissen werden.

[TheDevil]

--- DANKSAGUNG ---

Hallo *all,

vielen Dank für die freundlichen und aufschlussreichen Infos / Kommentare.

Allen weiterhin gutes Gelingen.

Gruß
Ralf

[B.Hauser]

Dies funktioniert beim ILE auch wenn man folgendes in der H-Zeile beachtet:
DFTACTGRP(*NONE) ACTGRP(*CALLER)

Das sollte man tunlichst unterlassen.

ILE-Programme und noch schlimmer ILE-Service-Programme, die auf diese Art und Weise in der Default-Aktivierungsgruppe ausgeführt werden, können massive Probleme verursachen.

ILE-Objekte, die in der Default-Aktivierungsgruppe ausgeführt werden, werden beim RCLRSC NICHT aus dem Speicher entfernt. Lediglich die Dateien werden geschlossen. Es gibt jedoch keine Möglichkeit mehr in (Service-)Programmen festzustellen, ob die Datei geschlossen wurde oder nicht und erneutes Öffnen ist nicht mehr möglich. Ein erneuter Aufruf des Service-Programms führt zu einem harten Abbruch. Da hilft nur den Job zu beenden.

RPGIV Programme, die mit DFTACTGRP(*NO) erstellt werden, sind keine ILE-Programme und werden wie alte RPGIII Programme beim RCLRSC aus dem Speicher entfernt.

ILE-(Service-)Programme sollten immer in einer (benannten) Aktivierungsgruppe, notfalls auch in Aktivierungsgruppe *NEW ausgeführt werden. Das "äußere" Programm sollte mit einer benannten Aktivierungsgruppe (Notfalls QILE oder DUMMY oder was auch immer) erstellt werden.
Die aufgerufenen Programme können dann mit Aktivierungsgruppe *CALLER umgewandelt werden.

Über den Befehl RCLACTGRP kann die Aktivierungsgruppe und darin aktivierten Objekte, Zugriffswege etc. aus dem Speicher entfernt werden.

----------------------------------
FULL und PSEUDO-OPENS machen gerade bei komplexen Abfragen (auch bei optimalen Zugriffswegen!) sehr wohl einen Unterschied.
Ich habe durchaus Abfragen bei denen der Unterschied zwischen FULL und PSEUDO OPENs durch aus ein paar Sekunden beträgt.

Hier übrigens ein Zitat zum Thema CLOSQLCSR aus der SQL Database Performance and Query Optimization:
You can control whether the system keeps the ODPs open in the following ways:
- Use the CLOSQLCSR(*ENDJOB) or CLOSQLCSR(*ENDACTGRP) parameter

Birgitta

[TheDevil]

Hallo und puh ha ...

ich bin jetzt doch ein wenig verwirrt und stelle deshalb mal folgende Infos hier rein :
? CRTSQLRPGI ??OBJ(x/xxxx)
?*SRCFILE(xxxx/QRPGLESRC)
?*SRCMBR(xxx)
COMMIT(*NONE)
?*OBJTYPE(*PGM)
??REPLACE(*NO)

So wandel ich.

H DEBUG DECEDIT('0,') DATEDIT(*DMY.) option(*nodebugio)

Mehr hab ich nicht in den H Bestimmungen ...

Und hier das "Ende meines Programms" :

Movel 'RCLRSC' CMD1
Z-add 6 CMD2
Call 'QCMDEXC'
Parm CMD1
Parm CMD2

eval *INLR = *ON

OK or not OK ? :-)

Gruß,
Ralf

[Fuerchau]

Nicht OK.
Zur Laufzeit befindet sich dein Programm in der Aktivierungsgruppe QILE (Schau mal per DSPPGM).
Ein RCLRSC wirkt nur auf die *DFTACTGRP (OPM), den kannst du dir sparen, solange du keine OPM-Programme aufrufst.

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.

[TheDevil]

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

[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.