Umstellung von Chain auf setll + reade - seitdem dauernd Satzsperren

[Fuerchau]

"Alle READ-Befehle lesen immer 2 Datensätze, namlich den aktuellen und den nächsten. Wie sollte sonst festgestellt werden können ob %EOF angesetzt werden soll oder nicht. Wenn die Datei als Update-File definiert wurde, wird dadurch nicht nur der aktuelle sondern auch der folgende Datensatz gesperrt."

Nun, das würde man ja über die Lesestatistik sowie Lockübersicht feststellen können, wäre mir aber komplett neu. Ich kann bei einem READE immer nur 1 Satzsperre entdecken.
READ liefert den nächsten Satz in der Folge der Datei (sequentiell, keyed).
Ohne weitere Angabe liefert das OS über den Filestatus-Block eben EOF oder nicht.

READE ist eine spezielle RPG/LE-Funktion, die auch mit verkürztem Key funktioniert. Hierfür vergleicht die Runtime die gelesenen Schlüssel mit den gewünschten und setzt EOF dann selbständig. Zusätzlich wird Unlock aufgerufen, falls die Datei für Update geöffnet ist.
Wenn also kein EOF vom OS gemeldet wird, muss natürlich der Satz gesperrt werden bevor der Vergleich durchgeführt wird, da sonst ja nach dem Vergleich mittels erneutem Read/Chain die Werte schon wieder geändert sein könnten.

Würde READE 2 Sätze lesen, müsste ja anschließend wieder ein READPE durchgeführt werden (also 3 Reads) um auf den aktuellen Satz zurück zu positionieren, da man diesen ja ohne erneutes Lesen sonst gar nicht updaten könnte (4. Read), was aber defakto seit Erfindung der IO's nicht erforderlich ist.
Wobei dieses erneute Lesen wieder zu veränderten Werten führen könnte sowie ein READPE gar nicht zu dem gerade gelesenen sondern zu einem neu eingefügten Satz.

Mehr als 1 Satz zu sperren ist tatsächlich nur unter Commit möglich, und dann auch nur im Modus, ich glaube *CS, der auch gelesene Sätze sperrt. Dies ist aber i.d.R. kein empfohlener Modus, *CHG (Read Commited) ist da eher normal und der sperrt nicht beim Lesen.

RLA sperrt nur genau 1 Satz beim Lesen, falls die Datei Update ist.

[dschroeder]

Wenn also kein EOF vom OS gemeldet wird, muss natürlich der Satz gesperrt werden bevor der Vergleich durchgeführt wird, da sonst ja nach dem Vergleich mittels erneutem Read/Chain die Werte schon wieder geändert sein könnten.

Ich bin der Meinung, dass IBM dieses Problem mit ein bisschen mehr Aufwand beim Implementieren des READE hätte lösen können: Einfach ohne Sperre lesen und dann nach dem Sperren nochmal gucken, ob der Satz immer noch den passenden Key enthält.

Dieses Verhalten beim READE hat mich in der Vergangenheit schon oft geärgert. Aber ich muss zugeben, dass IBM es so dokumentiert hat. Also schlecht implementiert, aber gut dokumentiert => Für IBM ist alles OK.

[Fuerchau]

Das kannst du ja selber ebenso halten, READE(N) ggf. mit Teilkey => Chain mit Gesamtkey.
Du must nur bedenken, dass zwischen dem READE(N) und Chain der Satz oder Schlüssel sich geändert haben könnten oder bei nicht-Unique sich ein Satz dazwischengeschoben haben könnte.
Somit bist du nur beim READE mit Lock, falls du die Daten verarbeiten willst, auf der (etwas) sichereren Seite.
Ansonsten, und das ist ja dann SQL-Like, mach einen READE auf einer Input-LF und dann den Chain mit dem Unique-Key auf der Unique-LF.

Ich habe aber ebenso auch schon Anwendungen gesehen, die den READE mittles READ und If-Abfragen selber implementiert haben. Allerdings halt auch mit denselben Konsequenzen.

[ncc1701e]

Ich danke euch für die Erklärungen.
Werde dann mal tiefer in diese nativen RPG Funktionen einsteigen müssen....

Versuche dann mal eure Vorschläge zu testen.

[BenderD]

Mehr als 1 Satz zu sperren ist tatsächlich nur unter Commit möglich, und dann auch nur im Modus, ich glaube *CS, der auch gelesene Sätze sperrt. Dies ist aber i.d.R. kein empfohlener Modus, *CHG (Read Commited) ist da eher normal und der sperrt nicht beim Lesen.

Meint: einen Satz pro Cursor! Commit level *CHG ist nun mal gerade read uncommited, sprich: lies jeden Schmutz und nur für Auswahl Subfile Anzeigen zu gebrauchen. Sperrlevel *CS liest zwar nur gültige Sätze (read commited), gibt den Satz aber frei, wenn der nächste gelesen wird und der Satz nicht geschrieben wurde. Sperrlevel *ALL ist das, was der Standard unter cursor stability versteht: keine uncommited reads, gelesene Sätze bleiben bis Transaktionsende gesperrt, unabhängig davon ob sie geändert wurden.

Für das diskutierte Beispiel wäre Sperrlevel *ALL und Verarbeitung mit SQL Cursor mit where clause angemessen!!! Die Teilauswahl wird verarbeitet wie ein Satz, Sätze außerhalb der Auswahl werden nicht gesperrt (weil nicht gelesen).

D*B,

der vehement zum Einsatz von Commit rät!!! Umstellung auf SQL ohne Commit ist ein ernsthafter Fehler, (fast) immer und (fast) überall!!!

[Fuerchau]

Ich wollte ja auch nur auf diese Neuheit "Alle READ-Befehle lesen immer 2 Datensätze..." eingehen, muss wohl irgendwie für V8R5 geplant sein um auch wirklich den Letzten von der AS/400 zu vertreiben weil dann nichts mehr geht.

[BenderD]

... das war doch ein Missverständnis, in Wirklichkeit wird jeder Satz zweimal gelesen, erst mit RLA, dann mit SQL und dann verglichen, ob man richtig gelesen hat, wenn man den neuesten Buschtrommeln aus Rochester Glauben schenkt...