die Indexe mit der where Klausel könnten sich wieder mal als zweitbeste Idee entpuppen, ich empfehle hier die Finger davon zu lassen.
set option ist auch kein Allheilmittel, immerhin können in derselben ACTGRP mehrere Module mit kollidierenden settings innerhalb einer Transaktion laufen.
ich vermeide generell globale settings (nicht nur hier!!!) und verwende Einstellungen der qaqqini nur zu Testzwecken.
den CHGQRYA könnte man eventuell noch in einer connect routine per stored procedure machen, die Idee reißt mich aber auch nicht vom Hocker.
Perspektivisch muss man von dem Mix runter und alles per SQL machen und sich konsequent an ANSI SQL halten, ich habe in den letzten Jahren genau das versucht und viele Empfehlungen in das OPNCLO versenkt und bin damit ganz gut gefahren.

D*B

Zitat Zitat von Fuerchau Beitrag anzeigen
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 !!!