LCKW - LockWait - Wer (User) blockiert?

[Fuerchau]

Da scheint mir auch die Satzwartezeit auf *NOMAX zu stehen, sonst würde das Programm auch abbrechen.
Eine BZ alleine beim CHAIN/READ reicht da nicht aus.

Ansonsten stimme ich Dieter da zu, dass das Design der Anwendung fehlerhaft ist.
Aber nichts desto trotz gibts auch hierfür API's.
http://publib.boulder.ibm.com/infoce...6f%63%6b%22%20

Man bedenke aber, dass diese Information bereits veraltet sein kann, da der Job ggf. weiter läuft oder die Wait-Situation nicht mehr zutrifft.

[roman]

Vielen Dank für die Antworten. - Ich habe vergessen anzufügen, dass wir KEINEN Einfluss auf die Software nehmen, können, da wir nicht die Entwickler sind und deshalb keine Sourcen haben.
Selbst hätte ich natürlich dieses Problem auch programmtechnisch umschifft - habe ich andernorts auch schon getan.
Deshalb bleibt mir nur die "passive" Lösung übrig.
Werde mir das mit dem API mal genauer ansehen (Vielen Dank an Fuerchau). Allerdings habe ich diesbezüglich keine Erfahrung. Vielleicht werde ich mich nochmals ans Forum wenden müssen.
Fürs erste jedoch Besten Dank an alle.
Gruss Roman

[NEich]

@Bender

Die Lehre beinhaltet beide Arten der Sperre, zu sagen eine davon wäre falsch ist zwar eine persönliche Meinung, aber nicht ganz korrekt das als Fakt darzustellen. Es gibt sicherlich Anwendungsgebiete wo dies "Falsch" wäre, aber sicherlich nicht überall.

[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

[Fuerchau]

Schau dir das API genau an. Im Parameter 4 übergibst du die Job-Identifikation um alle Objekt-Sperren incl. Status des Jobs zu erhalten.
Um noch weiter ins Detail zu gehen musst du von dieser Liste für jedes gewünchte Objekt das API Retrieve Lock Information (QWCRLCKI) aufrufen:
http://publib.boulder.ibm.com/infoce...s/qwcrlcki.htm

[BenderD]

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

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

[Fuerchau]

Tja, wenn man denn bloß die Quellen hätte.
Ich habe auch noch keinen LOCK-Trigger gefunden

[BenderD]

@Baldur: zumindest die SQL Locks kriegt man über die offenen Commit Ressourcen weg, aber das bringt auch nix: dann glaubt ein Programm, dass es die Sperre hat, obwohl es sie nicht hat...
mit Gewalt geht das schon (cancel des Sperrers aus dem Job des Warters und dann automatischer retry, aber Software, die so wackelig gebaut ist, hat sicherlich keine Transaktions Sicherung und dann...

mfg

Dieter

Tja, wenn man denn bloß die Quellen hätte.
Ich habe auch noch keinen LOCK-Trigger gefunden

[roman]

@Baldur: zumindest die SQL Locks kriegt man über die offenen Commit Ressourcen weg, aber das bringt auch nix: dann glaubt ein Programm, dass es die Sperre hat, obwohl es sie nicht hat...
mit Gewalt geht das schon (cancel des Sperrers aus dem Job des Warters und dann automatischer retry, aber Software, die so wackelig gebaut ist, hat sicherlich keine Transaktions Sicherung und dann...

mfg

Dieter

Ich getraue mich gar nicht zu schreiben, wie verbreitet und wie lange diese sogenannte "Standard-Software" in der Branche ist. (Ursprung /36 - wen wunderts?). Auch die Branche möchte ich lieber nicht erwähnen, man würde sich wundern - oder eben auch nicht.... ;-)


PS: Danke Baldur, ich werde mich nochmals in die API's vertiefen.

Grüsse
Roman

[BenderD]

Hallo,

nur Mut, sowas muss man outen, sonst wird das nie besser ))
Eine Lösungsansatz wäre auch noch einen Messagehandler an die geschädigten Jobs anzuhängen, der dann wieder die Lock Messages auswertet...

mfg

Dieter Bender

Ich getraue mich gar nicht zu schreiben, wie verbreitet und wie lange diese sogenannte "Standard-Software" in der Branche ist. (Ursprung /36 - wen wunderts?). Auch die Branche möchte ich lieber nicht erwähnen, man würde sich wundern - oder eben auch nicht.... ;-)


PS: Danke Baldur, ich werde mich nochmals in die API's vertiefen.

Grüsse
Roman

[Fuerchau]

Die geschädigten Job's sind doch auch von dieser Software.
Allerdings wird die Automatisierung insoweit schwierig, da das Programm nicht entscheiden darf, welcher Job denn rausfliegt.
Ausserdem, wie Dieter schon sagt, muss das Programm eine eigene Lock-Tabelle überwachen um erst zuzuschlagen wenn die Deadlock-Situation über einen längeren Zeitraum zuschlägt, sonst werden Job's unnötigerweise gekillt.
Ich glaube dies tendiert schon Richtung Fuzzy-Logic

[roman]

(...)
Allerdings wird die Automatisierung insoweit schwierig, da das Programm nicht entscheiden darf, welcher Job denn rausfliegt.
Ausserdem, wie Dieter schon sagt, muss das Programm eine eigene Lock-Tabelle überwachen um erst zuzuschlagen wenn die Deadlock-Situation über einen längeren Zeitraum zuschlägt, sonst werden Job's unnötigerweise gekillt.
Ich glaube dies tendiert schon Richtung Fuzzy-Logic

Also Jobs werden KEINE gekillt. - Es reicht schon, wenn der geschädigte (der vor seinem Schirm wartet und wartet!) per E-Mail mitgeteilt bekommt, durch wen er blockiert wird. Die können sich dann gegenseitig die Köpfe einschlagen.... :-)

Diese Lock-Situation kommt relativ selten vor. Aber wenn sie vorkommt und nicht raschmöglichst erkannt und bereinigt wird, dann kann es zeitkritisch werden und in der Folge bares Geld kosten...