satz nach sqlupdate noch gesperrt

[Robi]

Moin,

ich hab hier ein ILERPGPgm das mit SQL einen Satz liest, in diesem dann 2 Werte Updatet (auch sql) und ein (uraltes) Verarbeitungspgm ruft.
Diese Verarbeitungspgm kann nun den eben upgedateten Satz nicht lesen.

Commit steht auf *none

     Satz 751795 in Teildatei myLogicalFile ist bereits für diesen Job gesperrt.
     E/A-Fehler CPF5032 in maLogicalFile erkannt (C G S D F).

eval sql_stm = select x, y from datei where ... for update
DECLARE C1 SCROLL CURSOR FOR SE_FLD1     
PREPARE SE_FLD1 FROM :SQL_Stm        
fetch first from... into ...
dow ...
if ...
Update datei set feld1 = :wert1, feld2 = :wert2 where current of c1
call 'altpgm'

Warum gibt SQL den Satz mit dem Update nicht frei bzw was muß ich machen, damit er frei wird ?

Danke
Robi

[BenderD]

... 2 Möglichkeiten:
- der erste update hat nicht geklappt, dann bleibt der Satz bis zum nächsten fetch dieses cursors gesperrt !!!
- Software defect => PTF Bestellen

am einfachsten ist dieses Geschäft immer mit Commit, dann gibt die Commit Operation die Sperren frei.

D*B

[Robi]

Hallo Dieter,
lt. Joblog hat der Update geklappt
Commit kann ich nicht 'mal eben' einführen.
Werde den Job mal so umbauen, das noch ein Fetch kommt
Melde mich
Gruß
Robi

[BenderD]

... das ist eines der größten Vorurteile, seit ILE geht das eben doch, sogar Programm für Programm, wenn man ein paar wenige Grundregeln beachtet.

D*B

Commit kann ich nicht 'mal eben' einführen.

[Fuerchau]

Das Problem ist die Definition im Select ... for update !

"for update" sperrt bereits beim Lesen, so dass anschließend beliebig viele "Update ... current of" durchgeführt werden können.
Dadurch darf ja der Update den Satz eben nicht freigeben!

Zu beachten ist auch, dass bei Satzsperre bereits der Select einen SQLCOD <> 0 liefert.

Wenn du den "for update" wegläßt und den Update mit Schlüsseln ergänzt erfolgt die Sperre erst beim Update mit anschließender Freigabe (wenn ohne commit, ansonsten erst beim Commit/Rollback).

Du solltest daher auch den SQLCOD nach dem Update prüfen bzw. die Anzahl der betroffenen Sätze.

[BenderD]

... die offizielle Doku sieht das anders

http://publib.boulder.ibm.com/infoce...Frbafycncr.htm

Das Problem ist die Definition im Select ... for update !

"for update" sperrt bereits beim Lesen, so dass anschließend beliebig viele "Update ... current of" durchgeführt werden können.
Dadurch darf ja der Update den Satz eben nicht freigeben!

Zu beachten ist auch, dass bei Satzsperre bereits der Select einen SQLCOD <> 0 liefert.

Wenn du den "for update" wegläßt und den Update mit Schlüsseln ergänzt erfolgt die Sperre erst beim Update mit anschließender Freigabe (wenn ohne commit, ansonsten erst beim Commit/Rollback).

Du solltest daher auch den SQLCOD nach dem Update prüfen bzw. die Anzahl der betroffenen Sätze.

[Fuerchau]

When FOR UPDATE is used, FETCH operations referencing the cursor acquire an exclusive row lock.

Bzgl. des Entsperrens nach "Update current of" kann ich nichts entdecken.

[BenderD]

... dann geh mal einen link tiefer (unter commit)
http://publib.boulder.ibm.com/infoce...Frbafycncr.htm

und da Tabelle 26

When FOR UPDATE is used, FETCH operations referencing the cursor acquire an exclusive row lock.

Bzgl. des Entsperrens nach "Update current of" kann ich nichts entdecken.