Schau mal unter folgendem:
http://publib.boulder.ibm.com/iserie....htm#HDRDYNMIC

Das Hauptproblem ist wohl das zur Verfügung stellen von Speicher für die Variablen bzw Gesamtpuffern, es sei denn man arbeitet immer mit festen Größen.
Auch die Übergabe der Daten an ein anderes Programm ist dann nicht so einfach, da es ja "beschreibende" Strukturen geben muss.

Ausserdem geht das Ganze eigentlich in die falsche Richtung.
Um performant mit den Daten zu arbeiten sind statische SQL's einfach besser.
Ausserdem schleppt man einen geringeren Overhead mit sich herum.
Zusätzliche Schnittstellendefinitionen, Castings um die Daten zu verarbeiten, und und und ...

Ich würde mir da eher noch mal Gedanken zum Konzept machen.
Das Abschaffen der Filehandler-PGM'e hat insoweit noch Konsequenzen, da nach deiner Methode nur noch 1 Abfrage überhaupt möglich ist.
Oder du benötigst je möglicher paralleler Abfrage ein Programm bzw. Modul, da ein Cursor nicht dynamisch definiert werden kann.
Da aber durchaus mal mehr als 20 oder 50 Dateien auf sein können, hast du ein Problem.

Wie siehts denn überhaupt mit den Schnittstellen aus ?
Dein Konzept bedeutet ja, das das dynamische Programm als Unterprogramm/Servicemodul fungiert. Es kann also innerhalb des Lebenszyklusses durchaus von verschiedenen Programmen aufgerufen werden. Bedenke das mal bei deinem Redesign !

Die Alternative ist dann noch CLI, eine ODBC-ähnliche Schnittstelle mit jeder Menge C-Funktionen. Mit dieser kannst du dann tatsächlich voll dynamisch SQL's verwalten.
Beliebig viele Statments, Cursors usw., was obige Probleme sicherlich lösen kann aber nicht einfacher macht.