Die DB interessiert sich tatsächich nicht dafür, SQL sehr wohl.
Eine RPG-Laufzeitfehler gibt es bei der Übertragung meines Datums von *ISO in die SQL-generierten Variablen.
Merkst Du eigentlich, dass Du Dir wiedersprichst!
RPG crasht und nicht SQL! Die zusätlichen Host-Variablen sind RPG-Variablen, die lediglich vom SQLPreCompiler in den Source Code eingebunden werden.
RPG konvertiert die scaliger no immer in ein lesbares Format abh. von Angaben in den D- oder H-Bestimmungen. Innerhalb des Programms wird die alphanumerische Variablen hin- und hergeschoben und erst unmittelbar vor dem Zurückladen wieder in die scaliger no konvertiert. Der Überlauf/Crash passiert innerhalb von RPG wenn die Datums-Formate nicht zusammen passen.
Das passiert aber auch, wenn echte RPG-Datums-Variablen mit nicht zusammenpassenden Formaten umgeladen werden.

SQL ist die Sprache der DB umd muss sehr wohl das verwendete Datumformat kennen.
SQL kann die alphanumerische Darstellung eines Datums im Format YYYY-MM-DD (ISO), DD.MM.YYYY (EUR), MM/DD/YYYY (USA) erkennen und korrekt verarbeiten. SQL kann ebenfalls ein Datum aus einer gültigen alphanumerischenb Zeitmarken-Darstelllung YYYY-MM-DD-HH.MI.SS.MSMSMS (ISO), YYYY-MM-DD HH:MM:SS.MSMSMS (ANSI), YYYYMMDDHHMMSS herausbrechen. Beides ist unabhängig von dem Format, das im Job oder der aktuellen Verbindung gerade verwendet wird.
Diese Darstellung wird in die entsprechende scaliger no konvertiert und dann verarbeitet.
Bei Datums-Angaben mit 2-stelligem Jahr, muss das Format angegeben bzw. korrekt sein, da SQL weder die Position des Jahres noch aufgrund der Trennzeichen das eigentliche Format ermitteln kann!

Warum gibt es wohl in SQL DDL keinen Editier-Code für ein Datum wie in DDS?
... weil es nicht interessiert!

Wenn das Datum nicht angezeigt werden kann, ist das ein Problem der Verbindung bzw deren Definition und kein Problem von SQL.

Birgitta