Offene Dateien und deren wiederverwendung

[ILEMax]

Hallo Ihr Wissende.

Bisher habe ich gedacht, das ein Pgm, mehrfach gerufen, nicht mit LR verlassen, immer in der selben ACTGRP laufend, auch immer den selben zugriffspfad verwendet.
Das ist aber nicht so.
Wir haben in einem Ablauf Lesepgmme eingesetzt. Innerhalb dieses 'Ablaufes' werden ca 20 Dateiein gelesen, zum lesen wird aber immer ein Lesepgm gerufen. An machnchen Tagen hat der Job über 7000 offene Datenpfade.
Warum?
im Wrkactjob --> 14 sehe ich die Dateien alle zig mal offen, alle in der selben ACTGRP
Kann ich das 'irgendwie' anpassen das die offene Pfade wieder verwendet werden?
(zugriff zu 90 % RPGLE 10% SQLLE)

Danke
Der ILEMax

[ILEMax]

noch eine Ergänzung:
Die Dateien in der Anzeige ganz oben sind die, die verwendet werden. Bei den weiteren offenen Dateien ist die Relative Anz immer 0!

DateiA          LIB_a          DateiA             LGL       4781 I   N.
DateiA          LIB_a          DateiA             LGL          0 I   N.
DateiA          LIB_a          DateiA             LGL          0 I   N.
DateiA          LIB_a          DateiA             LGL          0 I   N.
DateiA          LIB_a          DateiA             LGL          0 I   N.

[Fuerchau]

Nun, wird auch immer der selbe SQL wieder verwendet?
Sobald du mit dynamischen SQL's umgehst und ggf. die Where-Klausel anpasst wird durchaus die Datei noch mal geöffnet, aber wie in der Anzeige ersichtlich trotzdem auf einer Datei gelesen.
Ggf. könnte dies auch mit dem Callstack zusammenhängen, da der Open auf jeder Ebene durchgeführt wird.
Beispiel:
PGMA => LeseProgrammA
PGMA => PGMB => LeseProgrammA

Experimentiere mal mit der CloseCursor-Option (*ENDMOD).
Der CloseCursor schließt nur den SQL-Zugriff aber beim 2. Mal nicht den ODP.

[andreaspr@aon.at]

Solche Phänomene habe ich auch schon erlebt.
Über die QAQQINI kannst du z.B. die max. Anzahl an offenen Zugriffspfaden einschränken.
Ansonsten hast du da nicht wirklich Chancen was daran zu ändern.

[ILEMax]

Da wo mit Sql gelesen wird, wird der Zugriff nur 1 mal dynamisch zusammen gebaut. Danach wird nur noch mit fetch next gelesen.
Lt einer Mitarbeiterin tritt das auch bei 100 % RPGLE abläufen auf.
Über 7000 offene Zugriffspfade und gerade mal bei 18 diese Pfade auch echte Zugriffe dahinter!
Macht das 'irgenwo/wann' probleme? Performance ...?

[BenderD]

Da wo mit Sql gelesen wird, wird der Zugriff nur 1 mal dynamisch zusammen gebaut. Danach wird nur noch mit fetch next gelesen.
Lt einer Mitarbeiterin tritt das auch bei 100 % RPGLE abläufen auf.
Über 7000 offene Zugriffspfade und gerade mal bei 18 diese Pfade auch echte Zugriffe dahinter!
Macht das 'irgenwo/wann' probleme? Performance ...?

... das ist entweder eine Sinnestäuschung (bist Du sicher was das Programm genau macht), oder ein veritabler Bug im DB2/400. Ein fetch next macht alles, nur keinen Zugriffspfad!

D*B

[Fuerchau]

Man beachte auch, dass die "echten" Zugriffe auch nur gefundene Sätze zählen.
Liefert ein Open keine Daten, ist auch der Zähler 0!
M.a.W.: von über 7000 Zugriffen haben nur 18 tatsächlich Daten geliefert.
Die anderen Zugriffe waren erfolglos. Und hier ist dann anzusetzen, warum der Pfad noch offen bleibt.

[ILEMax]

Warum geht Ihr davon aus, das SQL die Ursache ist.
Es tritt doch auch in 100 % RPGLE abläufen auf. Und da wird NUR mit setll, read, chain gelesen und nur von einem Lesepgm(Je Datei 1 Lesepgm). Das Lesepgm wird von verschiedenen Pgmmen gerufen, läuft aber immer in der selben ACTGRP. Die Anzeige der offenen Dateien zeigt z.B. das die PF MVVG1 in ACTGRP 17 mehr als 400 mal offen ist. Die LF MVVG100, MVVG101 und MVVG103 sind ebenfalls sehr sehr oft offen, ebenfalls in ACTGRP 17. Aber nur die 1. offene Datei (jeweils) hat zugriffe, alle anderen, Lt Anzeige, haben 0 zugriffe. Und ich frage mich WER die Datei öffnet. Im gesammten Ablauf hat nur das Jeweilige Lesepgm die Datei in der F-Karte, alle anderen haben die PF als EDS Extname(MVVG1)

[BenderD]

Warum geht Ihr davon aus, das SQL die Ursache ist.
Es tritt doch auch in 100 % RPGLE abläufen auf. Und da wird NUR mit setll, read, chain gelesen und nur von einem Lesepgm(Je Datei 1 Lesepgm). Das Lesepgm wird von verschiedenen Pgmmen gerufen, läuft aber immer in der selben ACTGRP. Die Anzeige der offenen Dateien zeigt z.B. das die PF MVVG1 in ACTGRP 17 mehr als 400 mal offen ist. Die LF MVVG100, MVVG101 und MVVG103 sind ebenfalls sehr sehr oft offen, ebenfalls in ACTGRP 17. Aber nur die 1. offene Datei (jeweils) hat zugriffe, alle anderen, Lt Anzeige, haben 0 zugriffe. Und ich frage mich WER die Datei öffnet. Im gesammten Ablauf hat nur das Jeweilige Lesepgm die Datei in der F-Karte, alle anderen haben die PF als EDS Extname(MVVG1)

... weil die Beschreibung nicht zu der Beobachtung passt.
- nur ein Leseprogramm öffnet die Dateien
- dieses Leseprogramm läuft immer in derselben ACTGRP
- das Programm hat kein SQL (das war in den Postings nicht klar formuliert)
- die Datei hat etliche (400) offene Datenpfade in einem Job
eins von denen ist falsch, oder Du solltest erst mal Deinen PTF Stand aktualisieren.

D*B

[ILEMax]

... weil die Beschreibung nicht zu der Beobachtung passt.

deswegen frag ich ja

- nur ein Leseprogramm öffnet die Dateien
- dieses Leseprogramm läuft immer in derselben ACTGRP
- das Programm hat kein SQL (das war in den Postings nicht klar formuliert)
- die Datei hat etliche (400) offene Datenpfade in einem Job

ja, ja, ja und ja!

eins von denen ist falsch, oder Du solltest erst mal Deinen PTF Stand aktualisieren.

Was heist eins von denen?
PTF Stand ist (lt. Kunde) aktuell (hier glaub ich das sogar)

[Fuerchau]

Da hilft dann nur, eine Trace-Funktion der betroffenen Routinen einzubauen und einen Eintrag zu loggen. Hilfreich in den Nicht-SQL-Programmen ist dabei, die Datei per USROPN zu definieren damit die impliziten Open zu reduzieren.

[BenderD]

... einfacher wäre, schlicht zu journalisieren - mit open close!!! - und erst mal auszuschließen:
- dass es andere Programme gibt, die die Datei verwenden
- dass der Ablauf ein anderer ist, als vermutet

D*B