Zitat Zitat von Fuerchau Beitrag anzeigen
Wobei der Abbruch auch noch 1 Minute dauert.
D.h., im Dialog erfährt der User erst nach 1 Minute, dass da ein Lock besteht.
Besser ist da schon die Job-Prüfung, was ja nun auch via SQL geht.
... dass der Abbruch eine Minute dauert, liegt allerdings an den idiotischen defaults der Einstellungen der Dateien. Waitfile steht hier auf *immed und waitrcd auf 60 Sekunden, hier müssen die Jungs und Mädels bei IBM Stunden beieinander gesessen haben und intensiv an Nichts gedacht haben. Waitfile * immed führt dazu, dass das commit level serializable (das der SQL Standard als Unterlassungswert fordert) mit recor level access unvereinbar ist. Datensätze, die langer als Millisekunden dauern, werden auch in Minuten nicht frei: Der Benutzer eines schadhaften Programms hat einen Satz gelesen und ist in die Mittagspause gegangen.
Diese unsinnigen Einstellungen ließen sich korrigieren, für WAITRCD wäre 1 Sekunde angemessen und WAITFILE sollte in jedem Fall größer als WAITRCD sein. Man kann dies allerdings per OVRDBF für das jeweilige Programm anpassen. Für Dialogprogramme auf *IMMED oder die oben gennante 1 sec (wenn man sich nicht traut) und für Synchronisatiuonszwecke von Batchjobs auf *NOMAX (das ist besser als in Schleife warten und neu versuchen, spart Strom und verhindert, dass ein anderer reinrutscht).

Dein Vorschlag mit der Job-Prüfung ist m.E. nur der zweitbeste Weg; genauer (wie der Schachspieler sagen würde) ist, den zu sperrenden Satz ohne zu lesen sofort zu ändern, bzw. zu schreiben.
Der Unlock erfolgt dann durch ROLLBACK oder COMMIT und der nächste wartende Job läuft automatisch an.

D*B

PS: Bei *NOMAX Wartezeiten muss man sorgfältig auf Deadlock Vermeidung achten, was auch für Warteschleifen gilt.