Hallo,

mit dem externen Monitor wird das schwierig, da dieser ja die Information über Locks und deren Dauer zusammen führen müsste, sprich eigene Locktabellen führen müsste.
Realistischer scheint mir da, die Aktion jeweils aus dem Programm zu triggern, das unter dem Lock leidet, sprich:
- Record wait für die Datei darf nicht *NOMAX sein
- bei Abbruch wegen Lock wait wird der Verursacher benannt
- Ursache mit RCVMSG oder API ermitteln
- Eintrag in Worker Q stellen (DTAQ o.ä.)
- Batch Job verarbeitet WorkerQ und tut was immer er will
Zusätzlich würde ich das Verhalten der Software beim Verursacher monieren und Fehlerbehebung verlangen!!! Sollte der auch mit unterschiedlichen Lehren argumentieren (its no bug, its a feature), würde ich Belegstellen für seine "Lehre" verlangen.

mfg

Dieter Bender

Zitat Zitat von roman
Das mit dem API funktioniert - so wie ich es verstehe - nicht! Ich betrachte die Jobs "von aussen". Das heisst, bisher komme ich nur "manuell" zu meiner gewünschten Information (d.h. zum sperrenden User), wenn ich über WRKACTJOB Auswahl 5 Work with Jobs, Auswahl 12 Work with Locks, Auswahl 5 (W w Memberlocks).

Diesen Weg möchte ich automatisieren! - Wie geschrieben: Ich habe keine Möglichkeit die Programme (und das sind viele!!) zu ändern bzw. ändern zu lassen.

Grüsse
Roman