Wissensfrage READPE und gesperrte Sätze

[cbe]

Man kann doch beim READ Bezugszahlen angeben, und damit ER und EOF getrennt auswerten.
(evtl. macht die Funktion %ERROR dasselbe?)

Dann kannst Du doch den Lock vom NoReocord unterscheiden.
Wenn Du dann noch die Wartezeit etwas runtersetzt (OVRDBF WAITRCD(1) oder so glaube ich), dann brauchst Du nicht mehr prophylaktisch ohne Sperre lesen.

[Fuerchau]

Im ILERPG heißt das
READE(E) ...
if %eof();
endif;
if %error();
endif;

Alternativ kann man das auch in eine MONITOR-Gruppe packen.

[cbe]

Reicht die Abfrage auf %error(), damit das Programm bei Lock-fehler nicht abbricht?

in eine MONITOR-Gruppe packen

immer dieser neumodische Kram
Eine bodenständige Bezugszahl ist doch viel schöner...

[Fuerchau]

bei READE(E) ja.......

[harkne]

Das kann man doch aber so gar nicht brauchen.

Mein Fall. Im Lager gibt es Kisten.

User 1 legt die Kiste 1 an. Wir halten diese gesperrt und zwar tatsächlich. Also mit Commit-Steuerung WRITE auf Datei ohne COMMIT. Somit gesperrt.

User 2 legt die Kiste 2 an. Jetzt werden verschiedene Dinge gemacht unter anderem wird aus der Kiste 2 die Kiste 3. Alle Datensätze von Kiste 2 gelöscht.

Mache ich jetzt einen READPE mit Kiste 2 (ID 2) um die Sätze zu löschen hauts mir das Programm weg, weil er irgendwann die Kiste 1 lesen will und diese aber von User 1 noch gesperrt ist. Die hat aber überhaupt nix mit dem User 2 zu tun. Und deshalb bleibt mir hier nur die Möglichkeit den READPE mit (N) auf die ID 2 zu machen. Findet er mache ich einen CHAIN und lösche den Satz. Das müsste ich nicht machen, wenn er nicht intern versuchen würde die ID1 zu sperren, die er gar nicht lesen soll. Ganz so einfach ist es nicht sonst könnte ich ja in einer Schleife mit ID immer einen CHAIN machen bis alles gelöscht ist, aber da kommen noch ein paar Bedingungen dazu.

Das hat meiner Meinung nach nichts mit dem herkömmlichen Sperren, UF oder IF oder COMMIT zu tun. Das Problem ist das E hinter READ. Er findet noch einen Satz den er gar nicht zu finden hätte aber finden muss ob er noch im "E"-Bereich ist und anstatt erst zu prüfen und dann zu sperren, versucht erst zu sperren und da hauts ihn weg.

[dschroeder]

Hallo harkne.

Du hast das Problem meiner Ansicht nach vollkommen richtig erkannt. Ich habe mich auch schon oft über das Verhalten von READE geändert. Aus meiner Sicht ist das ein Designfehler von IBM. RPG sperrt den nächsten Datensatz nämlich, bevor es den Schlüssel vergleicht. Ich meine dieses Verhalten auch schon mal vor Jahren mit der IBM-Hotline besprochen zu haben. Die haben gesagt, dass das Verhalten im Handbuch beschrieben ist. Und das es damit OK ist. Ich glaube, dass sich IBM die Implementierung nur sehr einfach gemacht hat. Die hatten zuerst den read und haben später den reade gebaut. Da haben sie einfach den read verwendet und danach geprüft, ob der Schlüssel noch passt. Auf die Idee, dass man den nächsten Satz erstmal nicht sperren sollte, weil man den Schlüssel vielleicht gar nicht haben will, sind die IBM-Entwickler damals wohl nicht gekommen.

Wir haben in unserer Anwendung inzwischen (hoffentlich) alle Programmstellen korrigiert, die bei reade bzw. readpe Probleme machen. Es ist genauso, wie du es schilderst: Der kurze Moment, in dem der reade den Satz lockt, ist unkritisch. Das Problem tritt auf, wenn jemand anders des Satz länger sperrt und der reade deswegen nicht weiterkommt. Man kann den Usern das Problem auch kaum erklären, weil der sperrende User meistens gar nichts mit dem Vorgang zu tun hat, den man mit reade lesen will.

Ich halte es auch für keine Lösung, den reade mit einer Monitor-Group oder Bezugszahl abzufangen. Bei einer Satzwartezeit von 30 Sekunden wartet die Schleife ja ewig, bis der Fehler erkannt wird. Und einen OVRDBF zur Änderung der Satzwartezeit finde ich auch nicht sehr elegant.

Wir haben alle Stellen so geändert, dass wir einen reade immer mit nolock durchführen. Also reade(n). Wenn das gut gegangen ist, sperren wir den Satz mit einem zusätzlichen Chain, der dann den kompletten unique Schlüssel nutzt.

In neuen Programmen nutzen wir reade gar nicht mehr. Da nutzen wir embedded sql.

Dieter

[Fuerchau]

Es ist soweit richtig erkannt, dass ich natürlich mit READE(N)/READPE(N) arbeiten muss wenn ich gesperrte Sätze, die für mich nicht relevant sind, überlesen muss.
Bei SQL ist das halt so gelöst, dass ich (bis auf Ausnahmen) beim Select nie sperren kann.
Die Ausnahmen sind entsprechender Sperr-Level in der Commit-Definition oder "... for update ..." im Cursor. Aber auch genau dann habe ich das Problem, gesperrte Daten zu überlesen.

Konzeptionell sollte man das aber eigentlich über eine View (LF) lösen, die zu überlesende Daten direkt ausschließt. Somit stellt sich die Satzsperre nicht mehr als Problem dar und performanter ist es auch noch.

Ansonsten: READE/READPE wird wohl eher von der RPG-Runtime ausgeführt als von der DB-Ebene.
Zum Vergleich: COBOL kennt solche Befehle überhaupt nicht.

[Pikachu]

User 1 legt die Kiste 1 an. Wir halten diese gesperrt und zwar tatsächlich. ...

Warum ???

[harkne]

@DieterSchröter,

danke erstmal für das Problemverständnis. Ist anscheinend noch nicht überall angekommen. Genau so machen wir das im Moment auch. Ich dachte nur es gäbe vielleicht eine andere Lösung. Vielen Dank für die ausführliche Antwort

@Fuerchau
Ich will den Satz doch gar nicht lesen und schon gar nicht sperren. Das System liest den intern und trifft auf einen gesperrten Satz und lockt somit. Er hat aber an dieser Stelle gar nicht zu locken. Außerdem verwende ich eine LF, die ist nach Case ID geschlüsselt und ich mach einen READE mit Case-Id 3. Er will intern aber Case-ID 2 sperren weil er beim reade über ID3 raus liest zum vergleich. Er hat an dieser Stelle wie Dieter bereits geschrieben hat aber eigentlich nicht zu sperren weil ich den Satz gar nicht lesen will.

@Pikachu
Kann ich leider nicht mehr sagen. Ist auch nicht von mir. Ich habe nur mitbekommen dass hier über mehrere Programme hinweg gearbeitet wird und dies nicht anders ging. ***Hüstel*** Ich weiß. Das Ding fass ich aber nicht an ;-)

[Fuerchau]

Die Datei ist für Update geöffnet.
Wenn du also einen READE ohne (N) kodierst wird der gelesene Satz immer gesperrt (was soll das System denn auch anderes tun) und prüft nun die Schlüssel.
(Von deiner Sortierung ist das dann ja wohl absteigend;-).)
Wenn du statt READE selber einen READ und anschließenden IF für die Schlüssel machst hast du doch genau dasselbe Problem.

[harkne]

Wenn ich das so programmiere ist das genauso schlecht wie das System das jetzt macht. Ich hätte erwartet dass er intern einen READE(N) macht, vergleicht und dann erst den Lock macht.. Wenn man ein klein wenig Hirnschmalz reinsteckt dann könnte man "INTERN" hergehen und das genau so machen wie heute und wenn man feststellt, dass ein Satz einen Lock hat den selben Satz mit (N) lesen und dann prüfen ob er überhaupt zu der Gruppe die gelesen werden soll passt.

Allerdings habe ich ja schon von Anfang an akzeptiert dass die Dinge sind wie sie sind. Ich wollte nur wissen ob es noch andere Lösungen gibt, die diese Problematik vielleicht selbstständig löst.

[Fuerchau]

Die Lösung heißt eigentlich SQL.
Da der Select nicht automatisch sperrt hast du das Problem erst gar nicht.