CPF2817, CPF2993 OVRDBF 2 CL´2

[TheDevil]

Hallo.

Ich habe zu diesem Thema schon einiges hier im Forum gefunden. Nichts desto trotz hier eine weitere Variante bei der ein simpler CPYF in einem CL zu einem CPF2817 führt :

Im Spiel sind 2 CL´s.
Im ersten CL wird ein OVRDBF auf Datei1 gemacht.
Danach wird das 2. CL aufgerufen. Hier kommt dann irgendwann der CPYF Lib1/Datei1 Lib2/Datei1 *add und schlägt mit CPF2817 / CPF2993 auf obwohl vor dem CPYF ein DLTOVR *all vorliegt :-()

Soblad wir im ersten CL vor dem Call 2. CL den DLTOVR machen haben wir mit dem CPYF im 2. CL kein Problem.

Kann mir mal jemand sagen warum der DLTOVR im 2. CL vor dem CPYF den OVRDBF aus dem 1. CL nicht killt ???

Und warum kommt überhaupt die Fehlermeldung ? Warum verhindert ein OVRDBF aus einem übergeordneten CL dies ... Fragen über Fragen für die Gemeinde

Grüße von der dänischen Grenze.
Ralf

[B.Hauser]

Vermutlich hast Du den Override mit dem Default-Override-Scope (OVRSCOPE=*ACTGRP) gemacht und beide Programme laufen in unterschiedlichen Aktivierungsgruppen.

Werden mehrere Programme hintereinander aufgerufen und der Override soll für alle gelten, sollte im Override-Befehl der Override Scope auf *CALLLVL gesetzt werden. Dann gilt der Override für alle im Call-Stack folgenden Programme und Prozeduren.

Birgitta

[Robi]

Promte (= F4) mal die ovr und dltovr Befehle.
Und schau dir an, für welche actgrp die CL's gewandelt wurden.

Wenn der ovr mit * Job Läuft und der dltovr nicht ist das die Ursache.

Wenn beide CL's in der gleichen Actgrp laufen, kann es sein, das der dltovr nicht auf *actgrpdfn läuft.

Außerdem kann es sein, das im 2. Cl die Datei verwendet wird (call RpgPgm) und sie daher noch offen ist

Robi

[TheDevil]

Hallo.

Recht herzlichen Dank für die schnellen Antworten und Hinweise ...

Gruß aus dem hohen Norden
Ralf