@Furchau
Ich finde es toll, dass Du immer alles besser weißt als Barbara Morris (die ja keine Ahnung hat wie ihr compiler und die RPG Runtime funktionieren) und Scott Forstie (der ja auch keine Ahnung von der Architektur der Datenbank) hat.
... und bitte unterlasst zukünftig Eure blöden Bemerkungen. Ich hab' nämlich langsam wirklich keine Lust mehr auch nur noch irgendwas in diesem Forum zu posten.
Birgitta
Das nacht einfach die Erfahrung;-). Und ich habe mir schon früher die Mühe genacht, den generierten MI-Code zu analysieren.
Und daher weiß ich, dass in den Tiefsten Schichten der Datenbank die Funktion QDBGET/QDBPUT aufgerufen werden. Und wenn ich eine Tabelle intern beschrieben einlese, werden mir wie beim DSPPFM de aufbereiteten Datum/Zeit und Zeitmarkenfelder übergeben. Da spielt die RPG-Runtime noch gar keine Rolle.
Zum Vergleich: COBOL nutzt auch bei ILE die nativen Datenpuffer der File-Controlblocks. Und da ist von scaliger Nummern auch nichts zu sehen.
Aber viel wichtiger ist doch, was am Ende rauskommt.
Und da entscheiden die Definitionen der RPG-Felder, die durhch H-Bestimmung und Option-Statement die Formate festlegen.
Was die Datumskonvertierungen angeht, so liegen diese schon früher in den nativen MI-Befehlen, die von der RPG-Runtime halt nur mit verwendet werden.
Deshalb gibts auch MCH- und keine RPG-Fehler.
https://www.ibm.com/docs/en/i/7.4?topic=interfaces-i-machine-interface
Z.B.:
https://www.ibm.com/docs/en/i/7.4?topic=instructions-convert-date-cvtd
Somit gibt es mehrere MI-Befehle, die für Konvertierungen und Berechnungen zur Verfügung stehen. Warum sollte sich eine Runtime darüber Gedanken machen und das Rad neu erfinden?
Ich habe sogar einen MI-Compiler geschrieben, mit dem man all die schönen Dinge komfortabel programmierren kann.