Runsql aus CL-Programm funktioniert nicht mehr

[Fuerchau]

Um einen CLRPFM zu verhindern einfach "delete from file where myfield <> x'FF'"

Ggf. reicht auch schon ein "delete from file where 1=1", da alleine eine Where-Klausel eben das CLRPFM verhindert.

Und WRKOBJLCK zeigt ggf. erst mal keine Locks an, erst F6->Teildateien zeigt die Locks.

Ggf. liegt halt doch ein Bug vor, wenn der neue SQL-Optimizer erst mal CLRPFM versucht und nicht mehr die Locks vorher prüft.
Dies könnte auch ein Zeitproblem sein, da ja zwischen Prüfung und Lock setzen ein anderer wieder schneller sein könnte.

CLRPFM wird bei auch nicht bei Journalisierung durchgeführt, da ja sonst kein Rollback möglich wäre (bzw. späteres Wiederherstellen aus dem Journal).

[BenderD]

Ggf. liegt halt doch ein Bug vor, wenn der neue SQL-Optimizer erst mal CLRPFM versucht und nicht mehr die Locks vorher prüft.
Dies könnte auch ein Zeitproblem sein, da ja zwischen Prüfung und Lock setzen ein anderer wieder schneller sein könnte.

CLRPFM wird bei auch nicht bei Journalisierung durchgeführt, da ja sonst kein Rollback möglich wäre (bzw. späteres Wiederherstellen aus dem Journal).

Zeitproblem ist das keins, der Job holt sich seine Sperre einfach ohne wait und wenn das nicht geht, dann macht er halt einen satzweisen delete, wenn ers richtig macht.

Rollback würde selbst dann noch gehen, aber kein späteres backward Journal Recovery.

Dieter

[nico1964]

Also haben heute nochmals das ganze durchgespielt:
V5R4 aktuellster PTF-Stand

User steht auf einem Record in dem betroffenen File. Aufruf des CLPGM, wie am Anfang erwähnt. Programm läuft ohne Probleme durch.

V6R1 aktuellster PTF-Stand

User steht auf einem Record in dem betroffenen File. Aufruf des CLPGM, wie am Anfang erwähnt. Programm erhhält LCK und läuft nach einiger Zeit durch ohne Probleme durch.

Was uns zur Ansicht bringt, daß Hr. Fuerchau mit seiner 3. Antwort recht hat. Eigentlich nennen wir sowas verschlimmbessern.
LG