Ich habe mich bei unserer BI-Anwendung damals für die von Dieter angegebenen Firebird-Datenbank entschieden.
Gerade was den Optimizer angeht, könnte IBM doch von dieser OpenSource-DB viel lernen.
Dieses gehuddel mit "Optimize for" kann ich deshalb nicht nachvollziehen.

Wieso verändert STRSQL meinen eingegebenen Select mit einer eigenständigen Optimize-Klausel ?
Das gehört verboten!
Wie soll man denn da vernünftige Entscheidungen bezgl. des SQL's treffen ?
Ich baue viele SQL's erst mal per STRSQL bevor ich mich der Mühsal des Programmtestens unterziehe.
Den OpsNav verwende ich da nicht, da mir das einfach zu langsam geht und tatsächlich nervt.

Der Vorteil von embedded SQL's insbesonders dem Einbinden von Servicemodulen (auch in OPM-Konzepten durchaus vorhanden), die sowohl in Batch als auch Dialog aufgerufen werden ist somit dahin.

Ich muss also in den Programmen abfragen, ob es ein Dialog- oder Batchprogramm ist um den entsprechenden statischen SQL aufzurufen ?
Der Jobstatus alleine reicht da nun mal nicht mehr aus, da es auch Batch-Services gibt, die eigentlich auf Dialog ausgerichtet sind (Web-Services).

Und was passiert, wenn man mal per RDB auf eine AS/400 durchgreift, die den Optimize for noch nicht kennt ?

Also alles nicht so schön, wie IBM immer beschreibt.
Da kann ich nun langsam die Anwender verstehen, dass sie zu SQL-Server oder Oracle wechseln, wenn es um SQL-Anwendungen geht (nicht nur wegen der bunten Oberflächen).

PS:
Und was die Compiler angeht, so ist ja das Lizenzmodell ab V6 erschreckend, dass man nun 2 Compilergruppen hat:
1. preiswerte ILE-Compiler
2. teure OPM-Compiler mit Tendenz zum Verschwinden
Bei tausenden OPM-Anwendungen, die sicherlich auch noch nach V6 gewartet und auch als OPM erweitert werden müssen, ist das kein gutes Zeichen.