Zitat Zitat von BenderD Beitrag anzeigen
... noch eine Bemerkung zu eurem Sperrverfahren:
Ich würde hier Satzsperren und Prozesssynchronisation gedanklich voneinander trennen. Satzsperren sind kurz andauernd (Milllisekunden) und dienen der Transaktionskontrolle, das macht die Datenbank automatisch und hier dürfen keine lang andauernden (mehar als eine Bildschirmtransaktion) Sperren auftreten.
Prozesssynchronisation benötigt lang andauernde Sperren, bis ein anderer Prozess fertig ist. Hierunter fallen z.B.: Reisebuchungen, Verwaltung von Versicherungsverträgen können dazu gehören, auch Bestellungen mit Reservierungen können dazu gehören; in dieselbe Kategorie fallen auch etliche Batchprogramme (während Verbuchung A läuft, dürfen manche Prozesse nicht laufen), insbesondere bei Parallelisierung (wg. Speed).
Euer Ansatz mit einer Datei, die Sperren verwaltet ist erst mal OK. Ich würde das allerdings optimieren.
- Sperre setzen durch schreiben eines Sperrsatzes unter commit in einer ACTGRP, die nie commited wird.
- Sperre freigeben durch löschen des Sperrsatze.
- bricht das irgendwo ab, macht die Datenbank einen automatischen Rollback (hackt jemand die Stromzufuhr durch, beim nächsten IPL)
- zentralisiert wird das in einem SRVPGM, das als einziges die Sperrdatei benutzt und dazu aufgerufen wird. Beim CRTSRVPGM ACTGRP(NOCOMMIT) verwenden.
- kann eine Sperre nicht erteilt werden, sendet die entsprechende Procedure eine Abbruchmeldung.
- optional kann man noch einen wait Parameter in die Schnittstelle aufnehmen, bei immed sendet man eine Escape Message - ansonsten blockiert man den aufrufenden Prozess (lässt ihn warten).
Die Sperrdatei wird mit recordwait immed angelegt.

D*B
Guten Morgen,
unser Sperrverfahren läuft in etwa so, wie du es skizziert hast, denke ich. Der Satz in der Sperrdatei wird mit einem physischen Lock versehen. Zugegebenermaßen noch mit F-Bestimmung. Es gibt auch nur ein zentrales Tool, das die Sperren verwaltet.