Du musst unterscheiden zwischen der Query-Gruppierung und einem Group-By !

Beim Query muss eine Sortierung angegeben werden, wenn die Gruppierung sinnvolle Summen auswerfen soll.
Da beim Query sowohl die Einzelsätze als auch die Gruppensummen ausgewiesen werden können (in mehreren Stufen), erfolgt eben erst die Sortierung (falls angegeben) und anschließend eine ganz normale Gruppenwechsel-Verarbeitung.
Der Optimizer betrachtet beim Query im Wesentlichen die Satzauswahl und die Sortierung.
Von der anschließenden Gruppierung weiß er nähmlich nichts.

Bei SQL sieht das anders aus.
Da hat man nur 2 Möglichkeiten:
- nur Einzelsätze
- nur Gruppierung über max. 1 Ebene
Der Optimizer entscheidet hier jeweils über
- where
- Group
- having
- order
Klausel, wobei die Sortierung nicht eindeutig ist wenn man order-by weglässt, egal ob group-by oder nicht.

@Birgitta
Das mit der View geht solange gut, solange man wenige Sätze hat.
Da der Optimizer nun mal immer auf der PF aufsetzt, habe ich zwar für Query nun die Satznummer, aber bei einer Sortierung nach dieser erfolgt eben immer ein Table-Scan und zwar unabhängig von jedweder Verfügbarkeit von LF's (ich habe es mit einer 2,5Mio-Date bei V5R3 ausprobiert).
Lasse ich die Sortierung weg, klappts auch mit den LF's.
Ich denke, das liegt daran, dass die RRN eine Funktion und kein Feld ist. Bei Sortierung nach UDF's siehts genauso bescheiden aus.

Wenn ich aber weiß, dass das Zwischenergebnis nur ein paar 1000 bis 10.000 Sätze sind, ist das über einen Insert/Select bzw. Create/Select um Faktoren schneller.

@Frank
Prüfe mal an deiner Tabelle, ob REUSEDLT(*YES) eingeschaltet ist. Dann ist deine Eingangsfolge nähmlich keine mehr und das Problem löst sich in Luft auf.