View Full Version : LCKW - LockWait - Wer (User) blockiert?
Es kommt des öfteren vor, dass durch Unachtsamkeit Anwender mitten in einer Transaktion den Arbeitsplatz verlassen und andere ihrerseits die Transaktion nicht abschliessen können - wegen einem Member-Locking.
Bisher musste stets "auf Zuruf" des Betroffenen mit WRKACTJOB der "Bösewicht" ermittelt werden, welcher das Locking verursacht.
Ich habe nun ein Monitor-Programm geschrieben, welches in regelmässigen Abständen diese Locks ermittelt und per E-Mail mitteilt. Wünschbar aber wäre, dass der Verursacher DIREKT mittels E-Mail aufgefordert werden könnte, die Transaktion abzuschliessen bzw. das Member bzw. den Record freizugeben.
Gibt es eine Möglichkeit, zu dieser Information (Username) zu kommen?
Besten Dank für hilfreiche Informationen.
Gruss
Roman
RobertMack
09-01-06, 17:28
Hallo Roman,
wer seinen Platz verläßt, liest leider auch die Mail nicht.
Was hältst Du denn davon, solche Situationen zu vermeiden:
- Lock schon beim Versuch des Chains feststellen,
- über SDS den Verursacher einlesen,
- dem "Verlierer" eine Meldung anzeigen "Sorry, der Datensatz wird von xyz benutzt"
(mit erzieherischem Effekt, da das sicher jedem 'mal passiert)
Gruß,
Robert
Hallo,
Programme, die Satzsperren halten und die Kontrolle an den Benutzer geben, sind fehlerhaft und sollten entsprechend korrigiert werden:
z.B.:
- lesen ohne Sperren
- anzeigen des Satzes zum ändern
- lesen mit Sperre
- Vergleich auf zwischenzeitliche Änderung
- update oder Fehlermeldung
mfg
Dieter Bender
Hallo Roman,
wer seinen Platz verläßt, liest leider auch die Mail nicht.
Was hältst Du denn davon, solche Situationen zu vermeiden:
- Lock schon beim Versuch des Chains feststellen,
- über SDS den Verursacher einlesen,
- dem "Verlierer" eine Meldung anzeigen "Sorry, der Datensatz wird von xyz benutzt"
(mit erzieherischem Effekt, da das sicher jedem 'mal passiert)
Gruß,
Robert
RobertMack
09-01-06, 18:46
Ich weiß,
so sagt es die Lehre (und verlagert das Problem sonstwo hin).
Ich halte es lieber pragmatisch: es kann nur einer auf der Toilette sitzen... und der Nächste soll sehen, was der Vorgänger hinterlassen hat (statt Rollbacks und Ich-konnte-nicht-Du-mußt-alles-nochmal-neu-eingeben-Messages)
Gruß,
Robert
Okay, ich geb's ja zu: es gibt Anwendungsbereiche, da muß man es "richtig" machen ;-)
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/infocenter/iseries/v5r3/topic/apis/qwcrjblk.htm?resultof=%22%61%70%69%22%20%22%6c%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.
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
@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.
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
Hallo,
welche Lehre denn???
unter einem Transaktionsmonitor, wie CICS zum Beispiel, der auf einem IBM Mainframe bei Bildschirmprogrammen obligatorisch im Spiel ist, gibt jede Leseanforderung auf den Bildschirm implizit alle Satzsperren frei, da kann man das garnicht falsch machen.
Die traurige Tatsache, dass es auf einer AS400 (zu Hauf) sogenannte Standardsoftware gibt, die dauerhafte Satzsperren in Kauf nimmt, wird mich nicht dazu bringen das als korrekt anzusehen.
mfg
Dieter Bender
@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.
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/infocenter/iseries/v5r3/topic/apis/qwcrlcki.htm