Das ist bei der AS/400 "state of the art".
D.h., es werden keine Satzversionen für alte Transaktionen vorgehalten (SQL-Server Snapshot, Firebird, o.ä.).
Deshalb sind veränderte und neue Datensätze in einer offenen Transaktion gesperrt, bis der Commit/Rollback erfolgt.
Eine andere Transaktion wartet mit "Read commited" also auf die Freigabe der Sperre.
Bei "Read uncommited" wird nicht gewartet sondern der geänderte/neue Satz tatsächlich gelesen.
Da nicht feststellbar ist, ob der Satz auch tatsächlich gültig ist, kann man sich u.U. nicht auf die Information verlassen.

Da beim Lesen ja über die Satzwartezeit der Datei (default 1 Minute) gewartet wird, sollte also eine Transaktion, die Sperren hält, nie länger als die Satzwartezeit andauern.
Anwendungsentwicklung => Transaktionskonzept!

Der lesende SQL erfährt über SQLCODE/SQLSTATE warum das Lesen nicht erfolgreich war.
Ggf. musst du für deinen Select die Anzahl gelesener Sätze zählen und per "select ... offset n rows" den gesperrten Satzt überspringen.
Ob dabei allerdings Sperren ignoriert werden kann ich nicht sagen.