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