Welches Programm sperrt Satz

[Hubert]

Hallo zusammen,

wir haben ein Problem mit einer Satzsperre:

Sporadisch tritt der Fehler auf, dass ein Programm einen gesperrten Satz lesen will. Ich habe bisher keine Möglichkeit gefunden, festzustellen, welches Programm die Sperre stehen lässt. Der Aufrufstapel des sperrenden Jobs hilft nicht weiter, da viele Programme mit *INLR = *OFF verlassen werden, so dass das sperrende Programm möglicherweise gar nicht mehr im Aufrufstapel steht.

Vielen Dank im Voraus

Hubert

[Fuerchau]

Da hast du tatsächlich schlechte Karten.
Wenn du nicht weißt, welches Programm diese Datei geöffnet hat, kann dir das System da leider auch nicht helfen.

Problematisch sind da vor allem Anwendungen, die mit SHARE(*YES) die Datei ggf. mehrfach öffnen.
Da hilft tatsächlich nur, die Anwendung explizit zu analysieren.

[BenderD]

wenn die Sperre von einem update herrührt, dann kann man das sicher und relativ einfach durch Journalisierung herausfinden.

D*B

Hallo zusammen,

wir haben ein Problem mit einer Satzsperre:

Sporadisch tritt der Fehler auf, dass ein Programm einen gesperrten Satz lesen will. Ich habe bisher keine Möglichkeit gefunden, festzustellen, welches Programm die Sperre stehen lässt. Der Aufrufstapel des sperrenden Jobs hilft nicht weiter, da viele Programme mit *INLR = *OFF verlassen werden, so dass das sperrende Programm möglicherweise gar nicht mehr im Aufrufstapel steht.

Vielen Dank im Voraus

Hubert

[Fuerchau]

@Dieter
Wie wird denn beim Lesen eine Satzsperre journalisiert ?

[BenderD]

... deshalb habe ich auch geschrieben: wenn die Sperre von einem update herrührt...

@Dieter
Wie wird denn beim Lesen eine Satzsperre journalisiert ?

[Hubert]

Tja, dann bleibt wohl doch nur Sysyphus - Arbeit.


Vielen Dank

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