Offene Dateien

[Robi]

Moin BenderD

Das LR nur bei OPM wirkt kann ich mir nicht vorstellen!?
Das rufende Programm ist OPM, das gerufene ILE.
Und in dem ILE Pgm hab ich den LR entfernt.
Die Funktionalität ist geblieben.

Was störtr an den offenen Dateien?
Es geht um eine Art Callcenter, das ca 50 - 60 'Kunden' / Stunde handelt. mit 80 - 110 Personen

Bei einem Power User währen also nach einer Stunde mehr als 50 mal die gleichen Dateien auf. Ich finde schon das das 'sub-Optimal' ist.


noch ne Idee ?
Robi

[BenderD]

... vorstellen oder nicht vorstellen, das ist immer so eine Sache - LR wirkt definitiv nur bei OPM Programmen, war denn der Recompile identisch mit dem ursprünglichen???
Optimal oder Suboptimal muss messbar sein, die mehrfach offen bleibenden Dateien sollten nromalerweise von der Datenbank adäquat gehandelt werden (sprich der Cache ist begrenzt, das wächst nicht beliebig). Optimierung könnte hier schon im Programm anfangen, da müsste man aber mehr sehen, was da wie gemacht wird (Stichwort: prepared Statement)

D*B

PS: (Änderung) sorry nachgelesen, LR wirkt bei Programm unabhängig von ILE/OPM

Moin BenderD

Das LR nur bei OPM wirkt kann ich mir nicht vorstellen!?
Das rufende Programm ist OPM, das gerufene ILE.
Und in dem ILE Pgm hab ich den LR entfernt.
Die Funktionalität ist geblieben.

Was störtr an den offenen Dateien?
Es geht um eine Art Callcenter, das ca 50 - 60 'Kunden' / Stunde handelt. mit 80 - 110 Personen

Bei einem Power User währen also nach einer Stunde mehr als 50 mal die gleichen Dateien auf. Ich finde schon das das 'sub-Optimal' ist.


noch ne Idee ?
Robi

[Robi]

@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

[Robi]

@Fuerchau

einfach gemacht ...
ja, so sehen die Innereien des Pgm's auch aus.
Trotzdem ist das, was es macht ziemlich komplex und das Ergebnis gut.
Die ACTGRP steht auf *caller, (das ILE Pgm läuft also in *DFTACTGRP = OPM)
Ein Versuch mit einer festen ACTGRP hat nicht geholfen.

Insofern ist die Vermutung mit dem OVR und dem 'selbstverständlichen' offen bleiben der Dateien leider falsch

Robi

[andreaspr@aon.at]

was du auf jeden fall benötigst ist beim aufzurufenden pgm
ACTGRP = *CALLER
und beim rufenden pgm ACTGRP = *NEW

eventuell musst du beim OVRDBF die beiden attribute auch setzen?:
SHARE *YES
OPNSCOPE *ACTGRPDFN

ab da bin ich dann mit meinem latein am ende.

lg andreas

[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

[andreaspr@aon.at]

soviel ich weis wirkt sich das LR nur bei PEP(Programmeingangsprozedur)-pgms/modulen aus.
da ist es egal ob es ein OPM oder ILE ist.
anders gesagt: wenn du mit ein main-pgm, mit einem service-pgm (=ILE), welches viele module beinhaltet, dann wirkt sich das LR nur auf das main-pgm aus und nicht in den einzelnen modulen im service-pgm. in den sub-proceduren gibt es nur noch ein return.

@robi: da dein ILE-PGM ein PEP ist, wirkt sich dort auch das LR aus.

ich glaub, das problem liegt am dyn. sql. ist es für (dyn.) sql denn möglich (und sinnvoll) files vorher manuell zu öffnen und offen zu lassen?

[Fuerchau]

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.

[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