CPF4128

[ExAzubi]

Also das SQL nichts sperrt, will ich nicht ganz so unterschreiben.

Wer mal versucht auf einer PF ein CLRPFM zu machen, während man mit STRSQL sich die Dateien anzeigen lässt, wird feststellen, das die Teildatei sich nicht löschen lässt. (Gibt allerdings nur einen CPF3130).

Mir ist desweiteren auch in SQLRPGLE Programmen aufgefallen, das wenn man bei einem SELECT keinen "FOR READ ONLY" angibt, die Sätze tlw. gesperrt sind, und so nicht in einem Unterprogramm geupdatet werden können.

Vielleicht mal ein CL drumherum bauen, den CPF4128 abfangen und mit dem API QWCLOBJL (List Object Locks) die sperren mal anzeigen lassen.

[GEA]

Besten dank schon mal an euch beide für die bisherigen Hinweise. Das bei einem SQLRPGLE-Programm die Sätze gesperrt sind, wenn man den "for read only" nicht angibt mag schon sein, aber das verursacht dann nicht die allgemeine Objektsperre "CPF4128".
Da muss es doch noch einen anderen HIntergrund geben. Ich werde mal versuchen das Thema einzukreisen, in dem ich vor den Programmen, wo das bisher aufgetreten ist, einen WRKOBJLCK rein baue. Das Dumme ist nur, es ist nicht immer die gleiche Datei. Was also machen bei einem Programm mit 30 - 40 Dateien die eröffnet werden?

Mit besten Grüßen aus dem Frankenland
Peter

[ExAzubi]

Also ein WRKOBJLCK nur eine Asperin!
Es beseitigt vielleicht die Symptome und nicht die Ursache

Bau um das Programm ein CL und prüfe wer die Sperre setzt.

Was ich aus meinen recht kurzen Berufsleben kenne, ist das bei Hochverfügbarkeitlösungen die auf's Journaling setzen, die Journale an sich eine Sperre auf das Objekt setzen, bis dr Datenstand abgelichen ist. Vielleicht kann es auch dsa sein?!?!?

[Fuerchau]

Nun, da das Programm ja mit CPF stirbt, kann man das gezielt abfangen, die Nachricht per RCVMSG auslesen und dann den WRKOBJLCK absetzen.

Das SQL nicht sperrt habe ich nicht gesagt nur dass SQL nicht exclusiv sperrt wie es hier den Anschein hat.

Ein Select sperrt normalerweise nie die Daten ausgenommen 2 Varianten:

CommitControl mit Lesesperre (die Art fällt mir i.M. nicht ein) und einen expliziten

select ...
for update of

Ein "for read only" ist ohne obige Commitdefinition nur Dokumentation.

Ansonsten können beim Select keine Satzsperren auftreten, da wäre dann was falsch.