CPF4128

[GEA]

Hallo,

ich weis, dieses Thema hatten wir schon mal gehabt, nur leider geht es nicht in diese Richtung von unserem Problem; deshalb muss ich dieses Thema nochmals aufgreifen.

So ab und zu kommt bei uns der (die/das) CPF4128 vor, ohne das eine Sicherung nebenbei läuft. Bei den Dateien die dabei durch ganz normale RPGLE-Programme eröffnet werden handelt es sich um DDS-beschriebene PF-DTA, die alle samt journalisiert werden (Backup-Lösung). Der CPF4128 kommt bei Programmen, die eigentlich ständig laufen, und somit müsste der Fehler eigentlich sehr häufig auftreten; tut er aber nicht, sondern nur so 2-3 mal im Monat, und dann immer zu unterschiedlichen Zeiten und auch mit unterschiedlichen Dateien (nicht immer die gleich, das wäre ja viel zu einfach ).

Meine Intension ist folgende: Wir setzen eine Vielzahl von Excel-Auswertungen ein, die per ODBC die Daten vom System-i abholen. Dabei handelt es sich um sehr komplexe SQL-Abfragen, welche schon teilweise 2-3 min brauchen, ehe sie Daten zur Verfügung stellen. Kann es deshalb sein, dass bis zu dem Zeitpunkt, wo SQL alle Zugriffspfad und Datensätze hat die zur Anzeige benötigt werden, die Dateien komplett gelockt werden, so dass der CPF4128 dadurch entsteht?
Wenn, dann wäre das mehr als

Ich hoffe, das ich mich halbwegs verständlich ausgedrückt habe.

Ich bin mal gespannt, was dazu alles Zutage tritt, denn nach über 25 Jahren auf der /38, AS/400, ... hat man auch so seine Erfahrungen gesammelt (ich und mein Chef).

Mit besten Grüßen aus dem Fränkischen...

[Fuerchau]

SQL sperrt nichts exclusiv, solange man keinen lock table macht.
Die Sperre muss woanders herkommen.

[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.