Welches Programm sperrt Satz

[Fuerchau]

Nunja, Updatesperren bleiben ja nur unter Commit/Control ohne Commit bestehen, aber ohne Commit/Control gibt's ja nach Update keine Satzsperre mehr.

Da wird ja dann (da die Anwendung das ja meist nicht beherrscht ohne Redesign) das Problem nur verschärft.

[Fuerchau]

@Hubert
Das Problem bei Share-Open ist auch, dass das sperrende Programm mit *INLR=*ON auch deaktiviert werden kann und die Sperre trotzdem bestehen bleibt.

Zur Analyse:
Häufig bleiben Sperren bestehen, wenn nach dem Lesen mit Sperre eine Bedingung dazu führt, dass eben kein Update erfolgt um die Sperre aufzuheben.

Solche Programme hatte ich da auch schon zu suchen.
Ich habe mir aber nur die Mühe gemacht, zu prüfen ob der Satz bei Verlassen des Pgm's tatsächlich noch benötigt wird und dann einfach einen UNLCK auf die Datei vor dem Programmende eingebaut.

[kuempi von stein]

Tritt denn das Problem immer an der gleichen Stelle auf?
Ich meine, hat immer das gleiche Programm an der gleichen Stelle das Problem?

Dann würde ich gar net gross suchen nach dem Fehler, sondern einfach mal ein WRKOBJLCK nach Liste (bzw. Call nach CLP was sowas macht) direkt davor einbauen und dann einfach abwarten bis das Problem nochmal auftaucht.

Dann die Listen sichten und hoffentlich den Übeltäter zu finden.

k.

[Robi]

Wir haben einen allg. gültigen Trigger, den wir in einem solchen Fall anhängen. Er schreibt den Key und den Pgmstack in eine Datei mit 50 Feldern.
Bisher haben wir nur update delete und insert abgedeckt.

aber das hat uns schon oft geholfen, zu finden warum da mal ein Satz verschwindet oder sich ab und zu (ohne grund) verändert.

Da der Trigger auch bei read ausgelöst wird ...
Je nach dem wieviel trafic auf der Datei ist, wird es zwar ne Weile recht langsam, aber wenn du evtl sogar den Satz spezifizieren kannst ....


Robi

[ExAzubi]

Hallo,

also wir bauen hier immer am Ende des CL ein RCLRSC ein.
Das hat den Vorteil, das das Problem nicht mehr auftreten kann.

Ich würde es in alle CL's einbauen, kostet ja weder Performance oder sowas.

[BenderD]

davon würde ich dringend abraten:
- ist für ILE wirkungslos
- hat für OPM Nebenwirkungen, die vielleicht nicht gewollt sind
- kann sehr wohl nicht zu vernachlässigende Performance Nachteile haben

D*B

Hallo,

also wir bauen hier immer am Ende des CL ein RCLRSC ein.
Das hat den Vorteil, das das Problem nicht mehr auftreten kann.

Ich würde es in alle CL's einbauen, kostet ja weder Performance oder sowas.

[Hubert]

Danke für die vielen Hinweise, die ich leider nicht umsetzen kann. Es handelt sich um eine seit Jahren gewachsene Anwendung, die nicht "mal eben" redesignt werden kann. Der Fehler tritt auch an unterschiedlichen Stellen auf.

Die Idee mit dem Trigger werde ich mal mit den Kollegen diskutieren; vielleicht kommen wir so weiter.

[kuempi von stein]

moin Hubert,

auch wenn da eine riesen-uralt-Anwendung erst mal die Hoffnung schwinden lässt....
würde ich persönlich die Sache mal locker angehen.

Mach einfach mal nen CL was den ganzen Tag in ner Schleife läuft und sagen wir mal alle 5 Minuten einfach nen WRKOBJLCK nach Liste produziert.

So kommen pro Tag läppische 288 Protokolle zusammen, die Du am drauffolgenden Tag einfach wieder löscht, wenn nichts gefunden..

Bin mir ziemlich sicher, dass man so die Sache mit wenig Aufwand einkreisen könnte.
Das CL ist in 5 Minuten geschrieben und tut nicht weh.

just my 2 cent

kuempi