Dazu muss man wissen, wie der Optimizer arbeitet.
Häufig wird der eigene SQL intern umgebaut und ergänzt um bessere Ergebnisse zu erzielen.
D.h., dass der SQL aus der VIEW entnommen wird und mit den zusätzleichen Feldern/Where/group/having ergänzt wird.
Folge:
aus
"select rrn(abc), ... from (select distinct ...) abc"
wird
"select distinct rrn(abc), ....."

und siehe da, RRN kann nie distinct sein und somit taucht jeder Satz auf.

Hieran kann man die Probleme von RRN sehr eindeutig erkennen und eben besser mit Schlüsseln arbeiten.
Ein anschliessender "select * from file where rrn(file)=nnn" führt nicht zum direkten Zugriff sondern zum Table-Scan.

RRN liefert nur die temporäre Satznummer und ist keine reguläre SQL-Funktion.

Hintergrund:
Bei einem Select auf eine View oder LF wird nie das Ergebnis verwendet, da aus Optimizer-Sicht sonst erst die gesamte View verarbeitet werden müsste bevor man zum eigentliche Select käme.
Durch obiges Umbauen kann aber häufiger schneller zugegriffen werden.

Deswegen nennt Dieter diesen ja auch "Pessimizer".

Übrigens:
Mit RRN verhindert man mit Sicherheit eine temporäre Kopie (meistens nur ein Auszug) der Daten in den Internspeicher (bzw. *QUERYnnnn in QTEMP).