Eigentlich kann es nur noch schlimmer kommen.
Beide Optimizer unterstützen ja keine derived Indices.
Der ein sagt, da sind welche vorhanden, also nimm den anderen (es sei denn QAQQINI definiert was anders), und der andere ignoriert diese sowieso.
Warum denn dann nicht gleich.

Ausserdem kann es dann passieren (wie mir eben), dass laufende Programme plötzlich kein Ergebnis liefern.

Desweiteren stelle ich mir vor, dass es da ein Tableset (PF+LF's) ohne derivied Indices gibt, alles läuft wie geschmiert.

Plötzlich überlegt sich jemand, da könnte man doch eben eine LF bzw. derived Index anlegen und laufende Programme werden plötzlich umgeroutet, liefern SQL0255 oder ganz anderes.

Inzwischen sind Anwendungen so komplex geworden, dass man sich ja gerade deswegen für SQL entscheidet.
Anwendungen weisen heute einen Mix aus OPM/ILE/RLA/SQL auf, was ja i.W. funktioiert.

Es darf aber einfach nicht passieren, dass sich bei existierenden SQL's mal so mal so entschieden wird.

Hier wäre ggf. ein Set Option hilfreich, um diesen Problemen aus dem Weg zu gehen. Schließlich enthält ein Programm ja meist doch viele SQL's, Actgrp's nicht zu vergessen, Commitzyklen über mehrere Programmaufrufebenen u.v.m.

Da darf man sich nicht von einer QAQQINI abhängig machen, die man auch noch je Job spezifizieren muss.
Ich müsste dann auch noch bei jedem SBMJOB, Dialogjob, ggf. vorgeschaltete CLP's einen CHGQRYA einbauen.

Ich habe auch Anwendungen mit Schnittstellen zu anderen Anwendungen, die per CALL aufgerufen werden.
Ändere ich nun für meine Anwendung die QAQQINI kann diese schon für das Fremdprogramm vollkommen falsch eingestellt sein.

So langsam sollte sich die IBM da was einfallen lassen.
- Wegfall der CQE (ich sehe da keinen Grund zur Erhaltung, spätestens ab V6R2)
- Wegfall der QAQQINI !!!