Offene Dateien

[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