View Full Version : Physische Satzsperren werden nicht aufgehoben
Hallo,
gibt es eine Möglichkeit, alle Eingaben eines Users mitzulocken, um festzustellen, warum eine Satzsperre nicht aufgehoben wird.
Ablauf COBOL:
Lesen eines Datensatzes und update mit jobnr und user. User macht im Programm weiter und verlässt das Programm ordnungsgemäß und lt. Source und Debug wird die Sperre freigegeben.
3 User von 300 schaffen es jedoch immer wieder, dass die Sperre also der neuerliche update mit user und jobnr nicht durchgeführt wird.
Wir haben schon alles mögliche ausprobiert, können das aber nicht nachstellen. Und es passiert nicht immer, aber immer die selben user
Vielleicht irgendeine Idee????
... der User kann hier nix falsch machen, das Programm ist Murks und da ist der Programmierer dran schuld!!!
D*B
Es könnte sein, dass die Maßnahme *ENDJOB des Systemwertes QINACTMSGQ ausgeführt wurde, weil die User das Zeitlimit in QINACTITV überschritten haben.
Das Programm wird dann abgebrochen und kommt nicht mehr dazu, den Satz freizugeben.
Im Joblog nachschauen, ob das zutrifft.
Das Programm (bzw. der Programmierer) muss damit rechnen, dass Programmabbrüche vorkommen können und geeignete Vorkehrungen für einen Wiederanlauf treffen.
Wenn ein Job abgebrochen wird, werden alle Sperren aufgehoben, das kann es nicht sein.
Was macht ihr denn, wenn das Lesen mit Sperre denn schiefgeht, also eine Sperre existiert?
Dann wird "Invalid key" ausgeführt was man nicht ignorieren sollte.
Wie steht denn die Satzwartezeit (default 1 Minute), da müssten die User schon des öfteren "geschrien" haben.
Wird journalisiert und CommitControl verwendet?
Dann bleibt die Sperre bis Commit/Rollback.
... der User kann hier nix falsch machen, das Programm ist Murks und da ist der Programmierer dran schuld!!!
D*B
Wenns bei 297 Usern funktioniert und nur bei 3 nicht, dann glaube ich nicht an Murks.
Wenn ein Job abgebrochen wird, werden alle Sperren aufgehoben, das kann es nicht sein.
Was macht ihr denn, wenn das Lesen mit Sperre denn schiefgeht, also eine Sperre existiert?
Dann wird "Invalid key" ausgeführt was man nicht ignorieren sollte.
Wie steht denn die Satzwartezeit (default 1 Minute), da müssten die User schon des öfteren "geschrien" haben.
Wird journalisiert und CommitControl verwendet?
Dann bleibt die Sperre bis Commit/Rollback.
Programm wird nicht abgebrochen.
Der User der den gesperrten Satz verwenden will, bekommt die Nachricht, das der Satz durch den anderen User gesperrt ist. Commit/Rollback wird verwendet. Wiederanlauf ist ausprogrammiert für unsere gesamte Online-Anwendung. Sind Standardcopies, die in jedem PGM eingebunden sind. Und auch für die Batchprogramme ist der Wiederanlauf programmiert.
Was wir leider nicht wissen ist, mit welchem Programm die Sperren gesetzt werden. Das wird leider nicht mitgeschrieben.
Wenns bei 297 Usern funktioniert und nur bei 3 nicht, dann glaube ich nicht an Murks.
... wer seine eigenen Fehler bei Anderen sucht, muss sich nicht wundern, wenn er sie nicht findet!!!
Dann würde ich die Journale diesbezüglich analysieren.
... wer seine eigenen Fehler bei Anderen sucht, muss sich nicht wundern, wenn er sie nicht findet!!!
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.
Der User der den gesperrten Satz verwenden will, bekommt die Nachricht, das der Satz durch den anderen User gesperrt ist. Commit/Rollback wird verwendet. Wiederanlauf ist ausprogrammiert für unsere gesamte Online-Anwendung. Sind Standardcopies, die in jedem PGM eingebunden sind. Und auch für die Batchprogramme ist der Wiederanlauf programmiert.
Was wir leider nicht wissen ist, mit welchem Programm die Sperren gesetzt werden. Das wird leider nicht mitgeschrieben.
Könnte es sein, dass der Benutzer auf eine zweite Ebene oder einen anderen Job geht? Und so sich selber sperrt?
Birgitta