Offene Dateien

[BenderD]

...falsche Source meinte ich nicht, andere Erstellungsparameter (ist ja bei SQL Programmen nicht ganz trivial).
Bezüglich LR habe ich schneller geschrieben als gedacht, Programme wirkt LR unabhängig von ILE, SRVPGMs nicht.
Problem beim dynamic SQL ist immer, wenn der komplette String erst zur Laufzeit zusammen gebastelt wird, erkennt die Datenbank oft nicht, ob derselbe Zugriffspfad schon da war und dann läuft der Cache von benutzten ODPs hoch. Ich habe allerdings noch in keinem Fall deinen befürchteten Ressourcenfrass beobachten können, allerdings schon häufig diesen Effekt.
Resumee: Versuch macht kluch

D*B

@BenderD
Die Sourcen sind auf der Kiste, da es mal hier entwickelt wurde. Insofern glaub ich schon das ich die richtige Source habe.
Ein Kompile der unveränderten Basis kommt auch auf die selbe größe wie das 'Orginal'

Die Logik zu verändern ist nicht erlaubt. (Dann hätt ich das Prob. auch selber lösen können)

Ich befürchte (ohne es zu wissen) das die vielen offenen Dateien und der damit verbundenen Recourcen verbrauch bei 80 - 100 Usern die Kiste nachmittags quasi lahm legt.

@andreas
k.a. ob das Sinn macht
Die Dateien werden bei jedem Aufruf mit "DELETE from Datei" leer gemacht. (vor meiner Änderung : drop, crtdupobj UND delete)

Gruß
Robi

[Fuerchau]

Gerade weil es wohl so komplex ist hat man das Aufräumen vergessen, da *LR=*ON dies nun mal automatisch macht.

*CALLER funktioniert nicht zwischen OPM und ILE.
Bei *CALLER wird die Default-ILE-ACTGRP genommen.

Versuch es noch mit einer gezielt benannten ACTGRP:

h dftactgrp(*no) actgrp('MYILEGRP')

[Fuerchau]

Ein OPM hat keinen Einfluss auf die ACTGRP!
Ich weiß auch nicht, warum das rufende Programm mit *NEW immer eine neue ACTGRP erstellen sollte.

[Robi]

@BenderD
Die UW parameter stehen in der Source als Kommentar.
Die hab ich genau so verwendet. Wen der Entwickler 'sauber' gearbeitet hat, ist alles ok.
Soweit ich dich verstehe meinst du, es wäre nicht schädlich.
Hmm ich schätze das kann ich dem EDV-Leiter nicht verkaufen.
Na ich werd ihm einfach mal diesen Thead zeigen.

@Fuerchau
Benannte ACTGRP hab ich doch schon versucht!

@andreaspr
das rufende Programm ist opm, da gibt es keine ACTGRP

@Fuerchau und andreaspr
wenn man aus einem Menu heraus Programme ruft so ist es sinnvoll diese in *new laufen zu lassen. Wenn man jedoch, so wie wir, keine Start-Cl Programme für alles und jedes hat, so ist es besser wenn (fast) alle Programme mit *caller laufen und ein Weichen-PGM, das in *new läuft, schleift aus dem menü den Aufruf auf das eigendliche Pgm durch.
Das ist bekannt, und (zumindest bei uns) auch realisiert.
Auf die Philosophie der Kundenunmgebungen die selber entwickeln habe ich nur wenig Einfluß.

Weitere Ideen sind wilkommen
Gruß
Robi

[B.Hauser]

SQL ist so angelegt, dass versucht wird die ODPs so lange wie möglich offenzu halten, da die Optimierung (und das Erstellen der ODPs) eine zeitaufwändige Angelegenheit ist.

Jedes SQL-Statement erhält seinen eigenen ODP, d.h. wenn das gleiche SQL-Statement x-Mal codiert ist und x-Mal ausgeführt ist, wird x-Mal optimiert.

Soweit ich weiß ist die Anzahl der offenen Zugriffswege per Default auf 512 Jobs begrenzt. In der Abfrage-Optionsdatei QAQQINI gibt es soweit ich mich erinnern kann eine Option, mit der diese Anzahl beeinflusst werden kann.

Wie Dieter bin ich der Meinung, dass die offenen Dateien (ODPs) nicht das Problem sind.

... aber versuch doch mal testweise folgendes:

Entferne die Bibliothek mit den offenen Datein aus der Bibliotheksliste und füge sie wieder hinzu. Dadurch sollten die von SQL geöffneten Dateien (bzw. die ODPs) geschlossen werden. Mit dieser Aktion kannst Du austesten, ob das wirklich das Problem ist. Ich schätze ist das dynamische SQL nicht sauber, d.h. das gleche statement mehrfach zu verwenden (was auch bei dynamischem SQL geht), wird immer neu generiert und optimiert.

... was mich außerdem wundert ist, dass die Dateien bereits nach der 1. Ausführung aufbleiben. Dies kann man nur durch eine spezielle Einstellung erreichen. (und von seiten der IBM wird abgeraten dieses Feature zu aktivieren!)

Birgitta