Datum in numerisches Feld bringen in Free-RPG

[B.Hauser]

Man kann sich ja schön per DSPFFD ansehen, dass mit der Pufferposition und Länge das Feld bereits aufbereitet geliefert bzw. erwartet wird.

DSPFFD bereitet das so auf und kommt noch aus der "alten" Zeit, als das Format im DDS nur dazu verwendet wurde um das Datum in WRKF lesbar zu machen.

Hast Du Dir zufällig mal die Mühe gemacht die Definition von Datums-Feldern in der Catalogview SYSCOLUMNS anzuschauen?
Storage ist 4Byte und nicht 10 Bytes. Die Informationen in der Catalog View kommen übrigens direkt aus der original "Datenbanken-"Datei QADBIFLD und in dieser Datei ist nirgends eine Länge von 10 für Datumsfelder zu finden.

Oder hast Du Dir vielleicht zufällig mal den Hex-Wert eines Datums angeschaut?
Das ist die Scaliger Nr und hat nichts mit irgendeiner aufbereiteten Datums-Format-Representation zu tun. Hex-Value für das heutige Datum ist z.B. 00257D80 (genau 4 Byte und genau so steht es in der Datei)
Ändere das Datums-Format in Deinem Job und die Datumsfelder werden in diesem Format angezeigt. Datumsfelder, die außerhalb des gültigen Bereichs für die Anzeige liegen, werden mit einer Anzahl von Plus-Zeichen angezeigt.
Der Hex-Wert ist jedoch immer noch der gleiche!
Es ist sogar möglich gültige Datumswerte, die außerhalb des gültigen Anzeige-Bereichs liegen einzufügen.
Die Konvertierung erfolgt direkt beim Schreiben (DDS wie SQL).
Ein "falsches" Datum kann nicht konvertiert werden, was bedeutet, dass auch in DDS kein falsches Datum eingefügt werden kann.

Birgitta

[Fuerchau]

Wie die DB dies intern handelt ist mir letztlich egal.
Ich greife mit HLL (RPGLE/COBOL) auf eine Tabelle zu und da wird mir im Puffer genau das Format geliefert, dass für das Feld oder für meine Variable definiert ist.
Das Job-Datumformat hat keine Auswirkungen auf die deklarierte Datum-Variable.
Einzig die "alte" Funktion TIME hat mir (leider) das Ergebnis im Jobformat geliefert was schon so einige Probleme brachte.
Und ob das Jobformat berücksichtigt wird entscheidet jede Anwendung selber.

Bei ODBC bekomme ich den Feldtyp DATE/DBDATE zurück, das Format interessiert hier nicht.
Bei Microsoft ist das kleinste Datum z.b. der 1.1.0100, da ein Datum 1.1.0099 zu 1.1.1999 konvertiert und 1.1.0001 zu 1.1.2001.

Und was die Prüferei angeht so habe ich ja nichts anderes behauptet.
Wenn das Dateifeld im Programm aber als TT.MM.JJ definiert ist, kann ich über native IO kein anderes Datum schreiben als durch die Variable zugelassen wird.
In SQL kann ich das natürlich, was aber dann bei den anderen Programmen mit TT.MM.JJ und native IO zum Laufzeitfehler führt.

[Fuerchau]

Wen es interessiert:
Das Datum in 4-Bytes ist die Anzahl Tage seit dem 1.1.0001 + 1721425.
Warum die IBM diese Basis genommen hat entzieht sich mir.

1.1.0001 = x'001A4452' = 1721426

[AG1965_2]

Weil da die Datumsrechnung beginnt? Womit hättest Du begonnen? Mit dem 1.1.1970? Und alles davor wird negativ?

[Pikachu]

Vermutlich hätte er nicht bei 1721426 begonnen, sondern bei 0.

[Fuerchau]

Da es kein negatives Datum gibt, ist 0 wohl die richtige Wahl.
Das Systemdatum von Windows wird z.b. in Sekunden seit dem 1.1.1601 geführt. vor diesem Datum wird rückwärts gezählt.