[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Dec 2004
    Beiträge
    203

    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

  2. #2
    Registriert seit
    Aug 2001
    Beiträge
    2.873
    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
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  3. #3
    Registriert seit
    Feb 2001
    Beiträge
    20.241
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  4. #4
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    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

  5. #5
    Registriert seit
    Dec 2004
    Beiträge
    203
    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

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.241
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Dec 2004
    Beiträge
    203
    --- DANKSAGUNG ---

    Hallo *all,

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

    Allen weiterhin gutes Gelingen.

    Gruß
    Ralf

  8. #8
    Registriert seit
    Aug 2001
    Beiträge
    2.873
    Zitat Zitat von Fuerchau Beitrag anzeigen
    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
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  9. #9
    Registriert seit
    Dec 2004
    Beiträge
    203
    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

  10. #10
    Registriert seit
    Feb 2001
    Beiträge
    20.241
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  11. #11
    Registriert seit
    Dec 2004
    Beiträge
    203
    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

  12. #12
    Registriert seit
    Aug 2001
    Beiträge
    2.873
    Zitat Zitat von Fuerchau Beitrag anzeigen
    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
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

Similar Threads

  1. Dynamisches embedded SQL
    By Tschabo in forum NEWSboard Programmierung
    Antworten: 10
    Letzter Beitrag: 11-03-21, 09:14
  2. MSG aus embedded SQL
    By malzusrex in forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 02-06-15, 11:26
  3. embedded sql substring
    By tarkusch in forum NEWSboard Programmierung
    Antworten: 7
    Letzter Beitrag: 29-06-14, 15:12
  4. EMBEDDED SQL in RPG
    By Ludger Muhmann in forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 30-07-02, 09:49
  5. Embedded SQL
    By Stefan_R in forum IBM i Hauptforum
    Antworten: 0
    Letzter Beitrag: 12-10-01, 09:47

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •