"Sofern kein Datums-Format vorhanden ist (wie bei DDL-Tabellen)..."
Und wenn man mal per DSPFFD eine DDL-Tabelle ansieht, dann wird dort explizit das Datumformat *ISO festgelegt, denn aus dieser Information holt sich der Compiler das Feldformat. Dies ist insofern wichtig, als dass man eben eine DDL-Tabelle auch ohne SQL (z.B. CPYF) bearbeiten kann.
Die Überschreibung des Datumfeldes in der Struktur ist fatal, denn nach jedem Read und vor jedem Write/Update ist der Inhalt dann zu konvertieren.
Allein der Vorschlag vergrößert die Huddelei und erhöht die Gefahr, insbesonders wenn man die Konvertierung vergisst und auf das Feld dann zugreift.
Daher ab damit in die tiefste Tonne.

Die Idee mit der 1:1-View und Anpassung des Datumformates halte ich für (fast) genial!
Das "fast" bezieht sich leider auf eine neuere Möglichkeit der Read/Write-Befehle mit Angabe von Strukturen "read file struct", "write file struct". Dies bietet sich häufig mit Qualified an.
Hier verlangt der Compiler, dass die Struktur von der richtigen Datei mit *likerec definiert wird.
Da habe ich nur die Vermutung, dass der Move dann nicht feldweise erfolgt sondern direkt aus dem/vom Puffer.

Da man Qualified aber auch auf F-Bestimmungen angeben kann, könnte man eben nach dem Read bzw. vor dem Write mit einem eval-corr übertragen. Beim Einsatz von File-Handlern die leichteste Übung.