offene Datenpfade

[Robi]

Moin *all
habe hier beim KD einen Job, der bei der Anzahl der offenen Datenpfade **** anzeigt.
Es sind ca. 5 verschiedene Dateien offen aber 1000de mal. Und das, immer in der gleichen ACTGRP.
Auf den 1. Blick kann ich nix seltsames an dem Job entdecken, Journal/commitment läuft nicht.
Hat jemand ne Idee wo ich da ansetzen kann? Danke
Robi

[andreaspr@aon.at]

Hallo Robi,

Eventuell kann sowas bei einem PGM vorkommen wo in SQL mit Cursor gearbeitet wird, die aber nicht geschlossen werden:

Exec Sql Close c1;

Beim CRTSQLRPGI Command ist per Default CLOSQLCSR *ENDACTGRP.
Somit werden die Cursor erst beim Beenden der Aktivierungsgruppe geschlossen.

lg Andreas

[Robi]

Hi, danke
haben in dem Ablauf tatsächlich ein SQL Pgm, das mit
"Close Cursor *endmod" (Syntax ist anders)
als Statement arbeitet.
Das Pgm wird mit Return verlassen und später ggf erneut gerufen.
Dabei macht er jedesmal einen neuen Datenpfad.
Sind die Module den erst bei LR beendet? (*endactgrp ist ja noch eine Stufe später)
Robi

[Robi]

Bisheriger Teststand:
LR statt return hilft nicht.
Close Cursor, als 1. Statement im Pgm hilft beim 1. mal, ab dann geht nur der Cursor zu, der Datenpfad bleibt aber offen und wird nicht wiederverwendet.
Das Pgm hat auch eine Wert Ermittlung via
set :variable = (select ...)
Wie geht der Datenpfad wieder zu
Ein endactgrp würde den Abluf massiv verlangsamen

[BenderD]

... close Operationen sind (fast) immer lazy close Operationen, sprich: es wird nur ein Merker gesetzt und der Datenpfad bleibt offen, das gilt auch für CLOSSQLCSR ENDMOD/ENDACTGRP (was auch bedeutet, dass letztere Einstellung auf die Performance keine Auswirkung hat). Die einzige Operation, die sicher hart closed ist ein disconnect, der bei RCLACTGRP implizit erfolgt.
Normalerweise sollten diese ODPs nicht stören, tun sie es hier doch, liegt eher ein Software defect vor, den man reklamieren sollte.

D*B

[andreaspr@aon.at]

SQL ist sebst für die Offenen Datenpfade verantwortlich. Es gibt da leider (oder gott sei dank, je nach dem) nur sehr wenig Möglichkeiten von außen Einfluss zu nehmen.
Einer der Möglichkeiten z.B. sind folgende QAQQINI Einträge:
OPEN_CURSOR_CLOSE_COUNT
OPEN_CURSOR_THRESHOLD
Mit denen kann man steuern wie viele Cursor bestehen bleiben dürfen die den Status "pseude close" haben.

Normal sollte es aber keine negativen Auswirkungen haben.
Wenn du z.B. ein ALTER TABLE ausführen möchtest, schließt SQL diese ODPs automatisch um die Objektsperren aufzuheben.

[Robi]

Der Job läuft beim Kunden seit 3 oder 4 Monaten. (durchgehend!)
Nun hat er sich gemeldet, und über die Anzahl der offenen Dateipfade 'beklagt'.

Ich sag ihm also nun, das er sich darum nicht kümmern braucht und das das egal ist?
(auch aus performance Gründen?)

[BenderD]

... das hört sich wieder mal nach so einem HKGP Job, der alle x Minuten nachsieht, ob was auf dem Haufen liegt, da sollte man schonmal einen Blick darauf haben, ob der sukzessive zuwächst...

[Fuerchau]

Die Anzahl der ODP's im Job ist auch beschränkt (irgendwo zwischen 32K und 64K).
Mir stellt sich da eher die Frage, warum die ODP's nicht wiederverwendet werden können.

Normales Vorgehen:
1. OPEN CURSOR => OPEN ODP
1. CLOSE CUROR => CLOSE ODP
2. OPEN CURSOR => OPEN ODP
2. CLOSE => wenn 2. Open dem 1. Open entspricht, dann kein CLOSE ODP, ansonsten CLOSE ODP

Dies gilt besonders bei dynamischen SQL's mit variablen Statements, die sich eben von Aufruf zu Aufruf ändern.
Irgendwann wird wohl der Open fehlschlagen da die Ressourcen erschöpft sind und das Programm je nach Fehlerabfrage dann eher "Keine Daten" melden an Stelle eines Programmabbruchs.

Ein 2. Open Cursor ist nicht möglich, wenn der Cursor vorher nicht geschlossen ist.
Cursor lassen sich nun mal vom Namen nicht dynamisieren (außer bei CLI).

Hier gilt es eben zu prüfen:
Wird jedes Mal die selbe Openart verwendet?
Wenn ja kann es sich um einen Fehler im OS handeln.
Wenn nein, warum wird der selbe Open aber mindestens 2 Mal gemacht so dass der ODP erhalten bleibt?

Ansonsten:
Alle SQL-Einstellungen betreffen ausschließlich die Cursor und nicht die ODP's.
ODP's können nur explizit mit einem Beenden der ACTGRP oder RCLACTGRP geschlossen werden.

[andreaspr@aon.at]

Ich sag ihm also nun, das er sich darum nicht kümmern braucht und das das egal ist?
(auch aus performance Gründen?)

Du kannst Probieren die Einstellungen in der QAQQINI setzen die ich zuvor geposted habe.

[Fuerchau]

OPEN_CURSOR_CLOSE_COUNT
OPEN_CURSOR_THRESHOLD

Ein CURSOR ist kein ODP. Dies wird unabhängig verwaltet.
Normalerweise sollte der Cursor ja immer wieder geschlossen werden, da ja sonst kein neuer Open erfolgen kann. Obige Einstellungen bringen daher nichts.

[andreaspr@aon.at]

1. Natürlich ist ein CURSOR kein ODP, aber sie stehen in Verbindung!
2. Lies die Beschreibung, darin wirst du sehen dass diese Optionen jedoch sehr wohl einen Einfluss auf die ODPs haben können!
3. Es geht dabei auch nicht um ein "Exec Sql CLOSE C1;" sondern um Hard/Pseudo Close!