CPF4128

[itec01]

Hallo,
seit drei Tagen bricht ein Programm mit der Meldung
Error message CPF4128 appeared during OPEN for file BOWRKL01 ab. Andere Programme sperren aber die Datei nicht und wenn dann nur Satzweise.

Der Job bricht dabei ab, obwohl die PSSR Routine angegeben ist. Mittlerweile habe ich aber herausgefunden, dass bei dem Fehler keine PSSR Routine aufgerufen wird.

Auszug aus dem RPG:
FBOWRKL01 UF A E K DISK commit
F INFSR(*PSSR)

Bitte um Info.

Wer hatte das Problem schon?

Gruss

[Fuerchau]

Wenn die Datei nicht in einem Journal aufgezeichnet wird, kann "commit" nicht verwendet werden !

[Frank Hildebrandt]

Eine Fehlerquelle könnte die Datensicherung sein. Wenn Ihr keine Sicherung im aktiven Zustand macht, dann werden die Dateien bei der Sicherung gesperrt und ein Programm, welches dann aufgerufen wird und eine solche Datei braucht wird abbrechen.

[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