Und noch mal für alle Technikbegeisterten:
Dateizugriffe erfolgen, egal mit welchen Methoden im Endeffekt mit den Routinen
QDBGETxxx (Leseroutinen)
QDBPUTxxx (Schreibroutinen)
Diese Methoden arbeiten bei der Parameterübergabe mit sog. Dateikontrollblöcken sowie einem Satzpuffer.
Dieser Satzpuffer entspricht genau dem Aufbau, den man sich per DSPFFD ansehen kann und die Feldausprägungen und Positionen im Satzpuffer sind genau so festgelegt.
Dazu gehört nun (leider) auch das Feld mit Datumsformat!
D.h., dass die Leseroutinen bereits im Satzpuffer das Datumformat so liefern, wie es beim Erstellen der Datei festgelegt wurde und im Gegenzug das Datum auch genau in diesem Format erwarten.
Die DB-Runtime speichert dann das Datum in der von Birgitta erwähnten "Scaliger Nummer".

Schaut man sich das Ganze dann in SQL an, so stellt man fest, dass SQL im Endeffekt genauso auf die QDBGET/QDBPUT-Funktionen zugreift.
In Folge dessen muss auch SQL genau mit dem Datumformat arbeiten, dass die Datenbank für das definierte Feld festlegt. SQL hat den Vorteil, dass Datumkonvertierungen, soweit möglich, automatisch durchgeführt werden können. Hierfür gibt es i.Ü. sogar MI-Befehle (CVTD, CVTT, CVTTS), die die diversen Umformatierungen vornehmen können.

Somit erklärt sich also der obige Sachverhalt eindeutig, dass das Datumformat eines Dateifeldes nicht geändert werden kann.
Dies gilt für OPM-Programme genauso wie für ILE-Programme, da die DB-Schnittstellen (QDBGET/QDBPUT) in allen Verwendungen identisch ist.

Quellen:
COBOL-Umwandlungliste mit MI-Output
RPG-Umwandlungsliste mit MI-Output
In diesen Listen kann man erkennen, dass die Aufrufe direkt die Datenpuffer mit dem benötigten Datenformat enthalten.
Hier kann man auch erkennen, dass COBOL mit den Satzpuffern direkt arbeitet, während bei RPG/LE nach dem Read Moves mit den Übertragungen aus dem Satzpuffer in die Felder und beim Write Moves aus den Feldern in den Satzpuffer erfolgen.

Über TRCJOB kann man die Aufrufebenen vom Programm über QSQxxx bis hin zu QDBxxx genau verfolgen.

Fazit:
Die Scaliger-Nummer ist eine Speicherung in der Datenbank und hat mit SQL überhaupt nichts zu tun.
Oberhalb der DB, also SQL und Native-IO muss mit einem korrekten Datumformat passend zur Datei gearbeitet werden.