Physische Satzsperren werden nicht aufgehoben

[BenderD]

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

[HerbertW]

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.)

[BenderD]

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...

[Fuerchau]

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.

[Chris.jan]

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.

[BenderD]

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

[Chris.jan]

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.

[BenderD]

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

[nico1964]

So um das ganze mal abzuschließen. Das Problem wurde gefunden(2.Job geöffnet) und wird auch bei uns intern kommuniziert.
@ D.Bender: Ich würde gerne wissen, wie ich auf die schnelle ca 1500 Programme ändere, die seit 1996 im Einsatz sind und über die Jahre wirklich gute Dienste leisten.(bin selbst erst seit 2007 im Unternehmen und hauptsächlich für Releasemanagment und diversen anderen Firlefanz zuständig.)
Wenn mir jemand einen Lösungsansatz liefert, das ganze relativ schnell und kostengünstig in die moderne Welt der EDV zu bringen, so sehe ich so einer Lösung wirklich offen entgegen. Ich weiß, dass bei uns einige Dinge nicht so programmiert wurden, wie es eigentlich sein sollte.

[BenderD]

So um das ganze mal abzuschließen. Das Problem wurde gefunden(2.Job geöffnet) und wird auch bei uns intern kommuniziert.
@ D.Bender: Ich würde gerne wissen, wie ich auf die schnelle ca 1500 Programme ändere, die seit 1996 im Einsatz sind und über die Jahre wirklich gute Dienste leisten.(bin selbst erst seit 2007 im Unternehmen und hauptsächlich für Releasemanagment und diversen anderen Firlefanz zuständig.)
Wenn mir jemand einen Lösungsansatz liefert, das ganze relativ schnell und kostengünstig in die moderne Welt der EDV zu bringen, so sehe ich so einer Lösung wirklich offen entgegen. Ich weiß, dass bei uns einige Dinge nicht so programmiert wurden, wie es eigentlich sein sollte.

Dazu habe ich eine gute Nachricht und eine schlechte, die schlechte zuerst:
1500 Programme sind auf die Schnelle nicht zu ändern.
Jetzt die Gute:
Es sind meistens immer wieder dieselben Programme, die die Probleme machen, meist gilt auch da die 80:20 Regel; 80% der Probleme werden von 20% der Programme verursacht. Diese Programme haben auch in vielen Fällen den höchsten Änderungsaufwand, werden also häufiger angefasst - und genau da muss man ansetzen.
Konkret könnte man bei Fehlerbehebungen immer einen Redesign Anteil zusätzlich als konkretisierte Anforderung vorsehen, das erhöht zwar den Aufwand für diese einzelne Änderung, ich würde da sogar einen Prozentsatz fest vorsehen, und die Schwelle für neu schreiben statt flicken wird niedriger, aber in der Perspektive wird man da besser. In vielen Fällen geht der Änderungsaufwand in der Summe sogar bereits auf mittlere Sicht (< 2 Jahre) zurück.


Dieter Bender

PS: Beim Tandem fahren gibt es eine Regel: "Der Stoker macht keine Fehler" und solange man die nicht begriffen hat, taugt man nicht zum Piloten.