Probleme mt OPNQRYF

[Hawi]

Hallo zusammen, vielleicht kann mir wer mein aktuelles Problem erklären.

Mir ist bewusst, dass ich OPNQRYF gegen SQL tauschen könnte. Leider kann ich aber
nicht alle Programme immer sofort komplett umstellen, muss aber trotzdem betroffene
Programme ggf. compilieren.

In einem CL-Programm ist folgender Code


OVRDBF FILE(LOGL1) TOFILE(&LIB/LOGL5) SHARE(*YES)

OPNQRYF FILE((LOGL1)) OPTION(*INP *UPD) FORMAT(*FILE) +
QRYSLT(&QRYBED) KEYFLD(*FILE) OPNID(SPED3)

CALL MYRPG1
CLOSE SPED3


In MYRPG1 findet keine direkte Dateiverarbeitung statt. Diese erfolgt über ein *SRVPGM,
welches mit logischer Sicht LOGL5 arbeitet.

Hier hätte ich jetzt erwartet, dass Datei LOGL5 nach dem Statement OPEN nochmals geöffnet wird und die neue Instanz als Basis herangezogen wird (Filter wird ignoriert).
Die bisherige Programmversion hat den *SHARE, sowie den OPNQRYF aber berücksichtigt und die Datei LOHL05 nicht nochmals geöffnet und die gefilterten Datensätze verwendet.

Jetzt wurden am CL-Programm Änderungen vorgenommen (nicht auf den OPNQRYF bezogen) und das CL-Programm, sowie MYRPG1 neu compiliert.

Nach der Neuerstellung ignoriert das SRVPGM nun den *SHARE sowie den OPNQRYF und liefert
mir alle Datensätze.

Das CL-Programm wurde mit Aktivierungsgruppe *NEW, das MYRPG mit Aktivierungsgruppe *CALLER
umgewandelt. Dies gilt für die aktuelle und bishere Umwandlung.

Kann mir jemand diese Verhaltenweisen erklären?

Vielen Dank im voraus für die Antworten.

Michael

[Fuerchau]

OPNID(SPED3) !?
Der OPNQRYF öffnet eine Datei mit Namen SPED3.
Dein Programm muss also die selbe Datei, nämlich SPED3 öffnen. Tut sie das nicht, ist der OPNQRYF wirkungslos.

Reihenfolge:
OVRDBF ... TOFILE(XXXX) SHARE(*YES) OVRSCOPE(*JOB) <= ggf. erforderlich
OPNQRYF ... OPNID(XXXX)
CALL ... (OPEN XXXX)
CLOSE XXXX

[Hawi]

Hallo Fürchau,

da sagt mir aber die Übersicht der geöffneten Dateien etwas anderes.
Demzufolge ist LOGL05 schon geöffnet, die Verarbeitung erfolgt ja auch
weiterhin hierüber.

Nur die Filterung des OPNQRYF greift nicht mehr, obwohl weder der Bereich
des OPNQRYF angefasst, noch das SRVPGM hinsichtlichtlich Dateiverarbeitung
angepasst wurde.

Den OVRSCOPE werde ich allerdings noch mal ausprobieren, denn der fehlt
tatsächlich. Wobei ich hier eigentlich sicher bin, dass dies der Default-Wert
des OVRDBF ist.

[Fuerchau]

Der Default ist *ACTGRP.
Wenn die Datei bereits auf ist bevor der OVRDBF und OPNQRYF läuft, wirken diese natürlich nicht mehr.
Wichtig ist:
Welche Datei wird im Programm geöffnet?
Genau diese ist per OVRDBF auf SHARE und ggf. auf einen neuen Namen zu überschreiben.
Der OPNQRYF ist mit dieser ID dann zu öffnen.
Zu diesem Zeitpunkt darf das Serviceprogramm noch nicht zur Ausführung bzw. zum Open gekommen sein. Ist eine eigene ACTGRP für das Serviceprogramm definiert (statt *CALLER) ist beim OVR *JOB erforderlich.
Wenn das Serviceprogramm die Datei am Ende nicht schließt wirkt ein 2. OVR/OPNQRYF nicht mehr.
Das killen der ACTGRP mit RCLACTGRP kann u.U. zu Folgefehlern führen.