-
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.
-
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
-
Zitat von Fuerchau
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.
-
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
-
Zitat von Fuerchau
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
Similar Threads
-
By Tschabo in forum NEWSboard Programmierung
Antworten: 10
Letzter Beitrag: 11-03-21, 09:14
-
By malzusrex in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 02-06-15, 11:26
-
By tarkusch in forum NEWSboard Programmierung
Antworten: 7
Letzter Beitrag: 29-06-14, 15:12
-
By Ludger Muhmann in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 30-07-02, 09:49
-
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
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks