View Full Version : ILERPG und embedded SQL
Hallo Forum,
ich habe in einem ILE RPG zwei SQL "laufen". Rufe ich diese
über den Screen auf und gucke mir nach Beendigung meine offenen
Dateien (Auswahl 14) an so "sehe" ich die Dateien die der/die Sql´s
in Zugriff hatten noch als offen ???
Ist das korrekt so ? Oder gibt es einen Umwandlungsparameter der auch
nach dem *LR und sogar vorhandenem RLCSRC in dem RPG auch diese
Dateien "schliesst" ?
Im voraus schon mal Danke für die Infos / Anregungen und allen eine
erfolgreiche Woche.
Gruß
Ralf
Das ist korrekt so!
*LR betrifft nur Dateien, die in den F-Bestimmungen definiert sind.
RCLRSC in Verbindung mit ILE-Programmen kann extrem problematisch werden.
Wenn dann muss die Aktivierungsgruppe mit *RCLACTGRP geschlossen werden.
SQL versucht die ODPs (und damit die Dateien) zur Wiederverwendung offen zu halten.
Die einzige Möglichkeit (und die sollte man nicht verwenden) ist die Compile-Option CLOSQLCSR auf *ENDMOD zu stellen.
Dann werden die ODPs nach dem Verlassen des Moduls gelöscht und damit sind auch die Dateien geschlossen.
... aber beim erneuten Aufruf ist ein FULL OPEN, eine volle Optimierung und Neuaufbau des ODPs erforderlich, was zeitaufwändig ist.
Birgitta
Bzgl. des Fullopens würde ich mir da keine Gedanken machen da dieser eher im Millisekundenbereich liegt. Gravierender sind da häufig fehlende Indizes oder unglückliche SQL-Formulierungen als dass der Open zur nachteiligen Performance beiträgt.
Der CLOSQLCSR hat auch keine Auswirkungen auf die ODP's!
Er dient nur dazu, einen SQL-Cursor auch zuschließen wenn man es selber mal vergessen hat.
andreaspr@aon.at
15-02-16, 11:20
Wie Birgitta schon sagte ist das alles normal.
Wenn du mit SQL arbeitest übernimmt die DB die Verwaltung der ODPs für dich. Im gegensatz zu Native I/O von "früher".
Wenn du z.B. ein ALTER TABLE oder CHGPF machst, schließt die DB automatisch die offenen ODPs (natürlich nur wenn die dazugehörigen Cursor auch alle geschlossen sind) um die Tabelle für die Operation freizugeben.
lg Andreas
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
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.
--- DANKSAGUNG ---
Hallo *all,
vielen Dank für die freundlichen und aufschlussreichen Infos / Kommentare.
Allen weiterhin gutes Gelingen.
Gruß
Ralf
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
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
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.