Offene Dateien

[BenderD]

... bei *NEW passiert nix, da fliegt die ACTGRP weg und damit ist auch alles weg. OVRDBF ist in dieser Konstellation Bug anfällig, aber ohne Bug sollte es gehen.

Kernpunkt ist aber: normal stören diese (nachvollziehbar unnötigen) ODPs nicht - wenns zuviele werden, werden ältere abgeräumt, wenn jemand die Ressourcen anfordert, alle nicht aktiven

D*B

Da das ILE kein Serviceporpgramm ist (Aufruf aus OPM), wie ist dann die Einstellung der ACTGRP ?

Ich vermute mal, es steht auf *NEW, so dass mit jedem Call eine neue ACTGRP erstellt wird, durch LR=*OFF diese aber nicht geschlossen wird und somit die Dateien offen bleiben.
Irgendwann hat der Job dann allerdings keine Ressourcen mehr.

Da das Programm aber mit OVRDBF arbeitet besteht die Gefahr, dass ab dem 2. Aufruf nicht mit den richtigen Dateien gearbeitet wird, da diese ja nun nicht mehr geschlossen werden.
Dies gilt ggf. auch für offene ODP's der SQL-Statements.

Das Programm zu beschleunigen wird wohl nicht ganz so einfach werden.
Da hat es sich jemand ganz schön einfach gemacht.

[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