@Birgitta
Dass ein CHAIN noch schneller sein soll als ein Select, halte ich für ein Gerücht.
Was ich in RPG mit mehreren native-Befehlen machen muss, erledige ich häufig mit einem SQL.
Das mit der Performance war mal so bei V3 !

**snip**

Och... auch eine V5-Kiste kriege ich mit RPG oder SQL sehr schnell langsam ;-)

Besonders zu beachten ist der gelegentliche Unterschied, wie ein RPG-gewohnter Programmierer sich ein SQL Statement zusammenlötet und dann nicht beachtet, was der gelobte (sic) Optimizer daraus treibt. Ich kann nur eine Lehrstunde mit den Performance-Tools und dem Advisor im OopsNav5.3 empfehlen, auch wenn sonst im V5R3 einige Kataströfchen enthalten sind.

Übrigens schliesse ich mich hier mal Dieters Performance-Aussage an, das kann sogar für das interpretierte Net.Data gelten, wenn man hier optimiert.

Und letztendlich ist Ausführungsgeschwindigkeit auch nicht immer alles. Da bastelt man tagelang um ein interaktives RPG-Programm zum fliegen zu bekommen, und wenn es dann Reisegeschwindigkeit erreicht hat, kommt Herr Interaktivwächter und haut dem Programm eins auf die Fr^h^hNase.
Währenddessen läuft ein Net.Data- oder sonstwieinsbatchgehobene Programm gemütlich aber zügig daran vorbei.

Ich bin ja auch eher ein Freund der grün-auf-schwarzen, aber hier muss man leider der Realität ins Auge sehen.

Übrigens: Wer eine zufällig zwei Maschinen (V5R2 und V5R3) hat, kann ja mal parallel auf beiden Kisten etwas interaktive Last ausprobieren und mit WRKSYSACT sich verlustieren.

Besonders lustige Ergebnisse gibt ein interaktives STRSQL bei parallelem INSERT INTO blubb SELECT * FROM irgendwo ;-)

[Hartgesottene blättern parallel wild im DSPLOG rum]

-h