Hallo hel400,

die Idee ist prinzipiell OK und praktizieren wir auch. Das ganze scheitert aber dann, wenn - wie bei /36-Umgebung nicht unüblich - in an sich gezonten/gepackten Feldern Blanks enthalten sind. Eine konditionierte DDS-Beschreibung kriegen Sie meines Wissens nach mit DDS nicht hin. Das würde aber in SQL gehen (mit entsprechendem Definitonsaufwand, ggf. mit einer UDF unterstützt). Ein entsprechender SQL funktioniert auch wie gewünscht. Soll aber mit diesem SQL eine View angelegt werden, weigert sich die AS/400 mit dem SQL7008, Ursachencode 3(View auf programmbeschriebene Datei nicht möglich). Warum IBM das verbietet, kann ich auch nicht ganz nachvollziehen. Natürlich kann man die programmbeschreibene Datei in eine DDS-beschriebene Datei umkopieren - wie von Bender auch vorgeschlagen -, das ändert aber noch nichts an den problematischen zoned/packed-Feldern. Auch der von Bender vorgeschlagenen PlanB, über ein Trigger-Programm eine korrekte Schattendatei aufzubauen ist eine gute Lösung - aber halt mit Aufwand verbunden. Diese Trigger automatsich zu generieren ist aber in unserem Fall nicht wirklich möglich, da es sich um RPG/36-Programme($MAS aus den 70er Jahren) handelt und keine Cobol-Copy-Books vorliegen.