Vom prinzipiellen Standpunkt aus möchte ich das Umstellen auf SQL auch befürworten, warne aber davor, alles für ganz einfach zu halten.

Ich hatte z.B. mal Anwendungen zu tun, die auf (zu) komplex definierten LF's beruhten, die als Joins z.B. auf 12-15 PF's mit einer Dynamic_Selection basierten. Da die ganze DB so gestrickt war, gab es bei manchen Dateien dann über 30 mögliche Zugriffswege. Unter V5R2 oder VR3 kapitulierte die SQL-Engine bei der Optimierung des Zugriffs, und beschloss in der Regel, die Daten über die Monster-LF's zu scannen - mit katastrophalen Laufzeiten (1-5 Min pro Transaktion).

Ich konnte durch Umformulierung auf SQL hingegen Laufzeiten von 1-3 Sek bekommen, was für sehr komplexe Abfragen durchaus angemessen erschien.

Allerdings haben wir unsere Anwendungen nicht kurzfristig umschreiben können, um mit diesen dynamisch gebildeten SQL's zu arbeiten. Ich konnte zwar ein Konzept dafür liefern, aber selbst innerhalb eines Jahres fanden die Programmierer keine Zeit zur Realisierung meiner Pläne.

In manchen Fällen wird es eher so sein, dass man lieber die ganze Anwendung neu designen und programmieren sollte, als sich zu lange durch Altlasten fesseln zu lassen.