Wissensfrage READPE und gesperrte Sätze

[harkne]

Hallo zusammen,

ich würde gerne wissen ob ihr folgende Problematik auch habt und wie ihr das löst.

Wenn ich eine Datei habe die mit UF geöffnet ist und ich lese mit einem beliebigen Schlüssel mit READE oder READPE dann ist der Satz vor bzw. nach dem letzten lesen ebenfalls gesperrt. Andere Programm stürzen dann ab die auf diesen Satz zugreifen wollen.

Also habe ich z.B folgende Datensätze

Feld1 A und Feld2 A
Feld1 A und Feld2 B

und ich mache (nach einem SETGT) einen READPE mit Feld1 A und Feld2 B erhalte ich den Record 2. Mache ich dann noch einen READPE bekomme ich %EOF der Satz 1 ist aber gesperrt.

Wir haben das inzwischen so gelöst, dass wir den READE bzw. READPE immer mit dem Zusatz (n) machen und nach der Abfrage von %eof mit einem eindeutigen Schlüssel auf die Datei mittels CHAIN zugreifen und dann den Satz verändern. Hiermit wird dann der Satz 1 nicht gesperrt.

Viele Grüße Harkne

[Pikachu]

Mache ich dann noch einen READPE bekomme ich %EOF der Satz 1 ist aber gesperrt.

Seltsam, denn in der Dokumentation zu READPE (V5R1) steht folgendes:

If the file being read is defined as update, a temporary lock on the prior record is requested and the search argument is compared to the key of that record. If the record is already locked, the program must wait until the record is available before obtaining the temporary lock and making the comparison. If the comparison is unequal, a BOF condition occurs, and the temporary record lock is removed. If no lock ('N' operation extender) is specified, a temporary lock is not requested.

[harkne]

Naja oder eben umgekehrt :-)
Jemand anders sperrt und ich laufe in diesem Programm auf einen Lock weil er einen Satz vorlesen will und dies nicht kann weil der Satz gesperrt ist. Egal wie rum.

Ich kann auf jedenfall keinen READE oder READPE verwenden wenn ich anschließend updaten will, weil ich immer in Gefahr laufe dass der Satz gesperrt ist.

Ziemlich unschön.

[camouflage]

Vielleicht änderst Du dein Programmdesign. Ich halte es nämlich so, dass ich zum nativ lesen ein logisches Inputfile verwende und den Update mit dem entsprechenden Schlüssel auf die physische Datei mache. Auch wenn ich dabei zwei Dateien brauche.

[harkne]

Naja, ob das dann sein muss. Warum kann ich eine logische Datei update eröffnen ? Mal abgesehen davon dass wir in der physischen Datei keine Schlüsselfelder verwenden. Außerdem ist das ja auch nicht "MEIN" Design, sondern unsere ganzen Entwickler sollten sich dann dementsprechend umstellen. Dass dies so ist habe ich ja bereits mehr oder weniger akzeptiert, dachte nur dass andere auch die Probleme haben und irgendwelche anderen Lösungen gefunden haben.

Danke für die Antworten.

[Fuerchau]

Satzsperren liegen nur bie UF-Dateien an wenn ich das (N) nicht angebe.
Das hat mit READE/READPE nichts zu tun da dies auch bei IF-Dateien funktioniert.
Wird dann EOF gemeldet, ist keine Satzsperre mehr aktiv.

Etwas anderes ist, wenn die mit Journalisierung und Commit arbeitest.
Hast du einen Update gemacht hebt EOF natürlich die Sperre nicht auf sondern erst der Commit/Rollback.

Vom Verfahren ist es in RPG(LE) ganz normal, dass man Zugriffe und Updates auch über LF's steuert.
Bei SQL sind LF's
a) nur Indizes die nicht native gelesen werden
b) Views, also eine Sicht auf die Daten
Hier mache ich natürlich Update/Insert/Delete auf die Tabelle (PF) und nicht auf die View (LF).

[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