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