View Full Version : Physische Satzsperren werden nicht aufgehoben
Dann würde ich die Journale diesbezüglich analysieren.
Bleibt mir wohl eh nichts anderes übrig, werde mich dann am Wochenende einsperren und x Seiten Journale durchackern, denn die Sperre betrifft leider den Partnerstamm, der eigentlich von überallher aufgerufen wird.
Könnte es sein, dass der Benutzer auf eine zweite Ebene oder einen anderen Job geht? Und so sich selber sperrt?
Birgitta
Das haben wir auch schon vermutet, leider erfahren wir über die Satzsperren nicht unmittelbar wenn Sie auftreten sondern oft erst 1 Stunde später und dann ist der andere User schon vom System und wir finden nichts mehr.
Das Programm, welches wir im Auge haben funktioniert seit 2002 ohne Probleme erst in den letzten Wochen bereiten diese 3 User Probleme und bei allen anderen funktioniert es.
... da fängt doch schon an, ihr sucht den Fehler im falschen Programm!!! Ich würde erst mal drüber nachdenken, was in den letzten 3 Wochen so geändert wurde, oder wo die fachlichen Gemeinsamkeiten bei den 3 Usern liegen und wo die Unterschiede zu den anderen. Auch die Frage ob sich die anderen vielleicht garnicht mehr trauen einen Fehler zu melden, wundern würde mich das nicht...
Nur am Rande vermerkt:
- Journale zeigen nur Datenänderungen und open/close auf, keine Leseoperationen mit Sperre.
- Programme, die Sätze gesperrt halten und die Kontrolle an den Benutzer geben sind Murks!
- keinen Murks zu machen ist unter Commit ganz einfach: vor jedem EXFMT die Transaktion mit Commit oder Rollback schließen.
D*B
Wenn ein Job abgebrochen wird, werden alle Sperren aufgehoben, das kann es nicht sein.
Ich ging davon aus, dass das Programm einen Satz liest, und mit User und Job-Nr fortschreibt. Wenn das Programm ordnungsgemäß beendet wird, dann werden User und Job-Nr. wieder aus dem Satz entfernt. So hat es Nico beschrieben.
Kann mir nicht vorstellen, dass diese Art selbstprogrammierte Sperren durch Jobabruch aufgehoben werden. (Ohne Commitment-Contr.)
Ich ging davon aus, dass das Programm einen Satz liest, und mit User und Job-Nr fortschreibt. Wenn das Programm ordnungsgemäß beendet wird, dann werden User und Job-Nr. wieder aus dem Satz entfernt. So hat es Nico beschrieben.
Kann mir nicht vorstellen, dass diese Art selbstprogrammierte Sperren durch Jobabruch aufgehoben werden. (Ohne Commitment-Contr.)
... auch das kann man unter ILE richtig machen, da gibt es CEE4RAGE und Exit Handler...
Gerade diese selbstprogrammierten Sperren sind doch im Journal dann leicht zu finden um dann festzustellen, was der Job der letzten Sperre denn dann nicht gemacht hat.
Vielleicht melden die User sich nicht korrekt ab sondern klicken auf das Kreuz oben rechts oder nehmen ALT-F4.
Gerade diese selbstprogrammierten Sperren sind doch im Journal dann leicht zu finden um dann festzustellen, was der Job der letzten Sperre denn dann nicht gemacht hat.
Vielleicht melden die User sich nicht korrekt ab sondern klicken auf das Kreuz oben rechts oder nehmen ALT-F4.
Genau darauf tippe ich auch. Das berühmte "aus-X-en" gehört bestraft. Aber grundsätzlich sollte man bei der Programmierung von interaktiven Updates sehr vorsichtig sein. Ich habe da heute erst noch ein Beitrag zu geschrieben. Jede Fahrlässigkeit die man irgendwann mal eingebaut hat, die rächt sich irgendwann mal bei der Fehlersuche. Und Locks sind was ganz böses, besonders beim debuggen.
Das berühmte "aus-X-en" gehört bestraft.
... genau das ist eine faule Ausrede, das schreiben von Programmen, die sowas nicht vertragen gehört "bestraft". Da gibt es Lösungen für, z.B.: separate Sperrsätze unter offener Commitgruppe schreiben, die verschwinden dann automatisch bei irregulärem Jobende, oder Wiederanlaufroutinen, die die Transaktion bei erneutem Aufruf wieder aufnehmen, oder Exithandler, die auch bei irregulärem Ende noch aufgerufen werden, notfalls sogar beim folgenden IPL... Je nach fachlicher Anforderung gibt es für all dies technische Lösungen und ordentliche Programme sind weniger Aufwand, als Fehlersuche ...
D*B
Jein - ich gebe dir da Recht, daß man richtig programmieren muß. Einmal weil für mich zum guten Ton gehört als Programmierer ein gewisses Niveau bei seiner Arbeit zu leisten, zum anderen aber auch deshalb weil man ständig dem DAU entgegentreten muß. Da erspar ich mir selbst viel Arbeit mit.
Aber das "aus-x-en" gehört dennoch bestraft, weil so ein bißchen Disziplin von jedem erwartet werden kann und man leider nicht immer Herr von diversen programmierten Altlasten werden kann. Und in den Zeiten von SOX kann jede angefaßte Zeile programmcode ein Rattenschwanz an Formalarbeit hinter sich her ziehen. Hab das selbst miterlebt.
Und in den Zeiten von SOX kann jede angefaßte Zeile programmcode ein Rattenschwanz an Formalarbeit hinter sich her ziehen. Hab das selbst miterlebt.
... auch das ist wieder mal so ein Beispiel von untauglichen Maßnahmen, das ist auf derselben Ebene wie:
- Compliance Richtlinien bei Banken, wo man dann am untersten Ende Angestellte Revers unterschreiben lässt und das Problem die Bank selber ist, die ihre eigenen Kunden abzockt
- Geldwäschegesetze, wo Girokonten mit 30.000 € und Bargeldbeträge von 2000 € verdächtig sind und das Geld von Banken in Millionentransaktionen verschoben wird
- Steuergesetze wo das Firlefanzamt Einmannfirmen Steuerprüfer auf den Hals schickt und an anderen Stellen am großen Rad gedreht wird...
D*B