Zu 3 muss ich Dieter zustimmen.
Man macht auch schon mal Queries mit Excel, hat im SQL-Server oder MS-Access verbundene Tabellen. Die kann ich nicht dazu bewegen einen Workaround einzubauen.

Zu 4 kann ich auch nur sagen, dass eine geänderte QAQQINI für ODBC-Zugriffe einfach erforderlich war (durch die plötzlichen Zeitschätzungen der CQE von > 40.000 Sekunden, die es mit V5R3 nicht gab).
Bei ODBC-Verbindungen (ebenso DRDA) kann ich nicht von jedem verlangen, dass er in seinen Verbindungsangaben eine für ihn passende QAQQINI auswählt, es muss also hier eine generellere Lösung geben.
Auch in der AS/400-Anwendung (s.o.) kann ich das nicht machen.

zu 5 kann ich eigentlich nur lachen (Entschuldigung).
Wie soll denn der Optimizer diesen Index verwenden, wenn dieser doch nur eine Teilmenge der ggf. gewünschten Daten enthält ?
Dazu müsste er so intelligent sein, dass er die Select/Omit's mit der Where-Klausel abgleicht.
Dies tun beide Optimizer ja nachweislich nicht, da man diese LF's in den Diagnosenachrichten grundsätzlich abgelehnt findet.
Insbesonders wenn man mit Hostvariablen arbeitet, deren Inhalt nun mal so variable ist, dass der Optimizer bei jedem Open die Optimierung erneut vornehmen müsste.

Zu 6:
Kannst du mir verraten, wie ich bei einer laufenden Anwendung oder ODBC-Zugriffen den OpsNav anwenden soll ?
Die automatischen SQL-Zugriffe kann ich ja nur über QAQQIN mit Diagnosenachrichten prüfen.
Allerdings habe ich auch schon festgestellt, dass SQL-Diagnosen z.T. erst nach DSPJOBLOG ... OUTPUT(*PRINT) erscheinen und nicht in der Dialoganzeige auftauchen (seltsam, sehr seltsam).
Ob das der Verbesserung dienlich ist ?