CPF4128

[Fuerchau]

Das kann man ja mittels WRKOBJLCK prüfen.
Ursache ist wohl eher das "commit" in der F-Bestimmung.
Wenn kein Journal vorhanden ist, schlägt der Open fehl.

[kuempi von stein]

Hello,

ob das so ist, sollte man ja dann schnell mit nem eingetippten UC testen können?
Und dann meinetwegen als erste Anweisung den open eben...

k.

[Frank Hildebrandt]

@FÜRCHAU

Wenn die Datei nicht im Journal aufgezeichnet wird, dann knallt das Programm mit einem CPF4328 und nicht mit einem
CPF4128. Der CPF4128 weist eindeutig auf Probleme mit Sperren hin.

[itec01]

Die Datei ist natürlich aufgezeichnet.
Es hat sich ja nichts geändert. Plötzlich kam der Fehler hoch.

Ein WRKOBJLCK brachte auch zuvor nichts. Es waren keine Sperren vorhanden.

[kuempi von stein]

...Ein WRKOBJLCK brachte auch zuvor nichts. Es waren keine Sperren vorhanden.

Irgendwoher muss der Fehler ja plötzlich kommen.
Meine Vermutung lag auch zuerst beim commit.
Der WRKOBJLCK wurde auch genau in dem Moment abgesetzt, da wo die Fehlermeldung hochkam?
Im Notfall mal das Programmobjekt umbenennen falls möglich und in ein CLP einwickeln, welches den ursprünglichen Namen hat. Und dann im CL eben nochmal auf Objektlock prüfen vor/nach call.

Ansonsten, wenns nix mit dem commit zu tun haben soll (kann ich mir gar nicht vorstellen) könnte es evtl. nochmal die gleiche file(BOWRKL01) in einer anderen LIB geben??
Soll ja alles schon passiert sein sowas...

k.

[itec01]

Ich verstehs ja selbst nicht.
Es ist auch nicht nachvollziehbar. Das Problem tritt absolut sporadisch auf.

Ich werde nun die Datei USRCTL öffnen und dann geziehlt den DUMP schreiben. Mal sehen was passiert.

Trotzdem Danke.

[kuempi von stein]

Hello,

ein DUMP wird nix bringen denke ich.
Die Fehlermeldung weist ja darauf hin, dass die File beim Open knallt.
Dann schon eher ein WRKACTJOB nach Liste oder sowas um mal zu sehen, was da stören könnte.
Ich vermute mal, das passiert immer zur gleichen Uhrzeit?
Falls ja, ist da irgendwo der Haken zum weitersuchen.

just my 2cents

[itec01]

Nein, auch nicht zur gleichen Uhrzeit.

Ich denke der DUMP könnte schon was bringen, weil normalerweise im DUMP drin steht wer die Sperre verursacht.

[Gerd/400]

Hallo,

das gleiche Problem habe ich heute bei einem Kunden. Ein Programm das am Ende der Nachtverarbeitung aufgerufen wird bricht mit CPF4128 ab. Die Datei wird zwar vorher gesichert aber vorab in einen SAVF und dieser dann auf Band.

Hattet ihr danach noch irgendwelche Erkenntnisse?

Gerd

[Fuerchau]

Die Sicherung sperrt die Objekte.
Bereits verwendetet Dateien können per SAVACT trotzdem gesichert werden.
Eine Datei, die aber zum Zeitpunkt des SAV frei war, wird komplett gesperrt, kann also nicht geöffnet werden.

Sporadisch dauert die Sicherung wohl dann doch etwas länger als gewünscht, so dass die Datei noch nicht frei ist.

Prüfen läßt sich das ggf. mit einem vorgeschalteten CLP, dass in einer Schleife einen OPNDBF / ALCOBJ versucht, und erst wenn dieser erfolgreich ist, das Programm startet.

CLOF / DLCOBJ nicht vergessen.

[Gerd/400]

Das ging aber fix......

Aber wie gesagt, die Sicherung der Datei bzw. der ganzen LIB ist ja beendet. Nach dem ersten SAV-Befehl wird in dem CL die 2. Sicherung aufgerufen. Danach passiert noch einiges und erst "Jahre später" wird das Programm gestartet das in die Grätsche geht.

Ich habe heute mal an der Dateiwartezeit gedreht, mal sehen was morgen passiert.

Gerd

[Fuerchau]

Die Dateiwartezeit ändert nichts an der Objektsperre.
Du solltest eher prüfen, wer denn die Sperre noch aufrecht erhält.