Datum in numerisches Feld bringen in Free-RPG

[Fuerchau]

Ja und Nein:).
Im Programmspeicher wird das Datum tatsächlich als reine Zeichenkette gespeichert.
Dies kann man bei DS-Definitionen sehr schön sehen. Auch bei der Anzeige im Debugger weiß dieser nichts vom Typ Datum.
Einzig beim Zugriff auf Datum/Zeit/Zeitmarken-Felder wird zusätzlicher Code auf gültige Werte ausgeführt. Erfolgt der Zugriff über die DS, also übergeordnet, kann keine Prüfung erfolgen da der Compiler nun mal nichts von Datumfeldern merkt und man kann dann sogar Schrott da reinstellen.
Ebenso gilt dies beim Lesen/Schreiben von/nach zur Datenbank.
Man kann sich ja schön per DSPFFD ansehen, dass mit der Pufferposition und Länge das Feld bereits aufbereitet geliefert bzw. erwartet wird.
Die Prüfung des Formates erfolgt dann beim Schreiben. Beim Lesen ist eine Prüfung nicht erforderlich da man tatsächlich nur gültige Werte (auch bei DDS) schreiben kann.
Beim Schreiben mit UPDATE/WRITE werden wiederum MOVE's generiert, die aus den Datenfeldern in den IO-Puffer übertragen und somit durch die Runtime geprüft werden.

Bei SQL sieht es nur geringfügig anders aus.
Der SQL-Precompiler generiert ja entsprechende Variablen für jede Hostvariable die mit MOVE's gelesen bzw. geschrieben werden. Hier schlägt dann die RPG-Runtime mit den Prüfungen wieder zu.
Dies kann man dann schon mal sehen, dass z.B. beim FETCH in ein 8-stelliges Datumfeld (TT.MM.JJ) mit einem ungültigen Wert eine RPG-Fehlermeldung und kein SQL-Fehler gemeldet wird da das SQLnnnn-Feld 10-Stellig definiert wurde.

In COBOL wird direkt mit den IO-Puffern gearbeitet. Nach einem READ kann man daher auch hier den Puffer mit den bereits aufbereiteten Datum-Feldern sehen. Außer bei den Datum-Feldern kann man daher mit COBOL auch Schrott in numerische Felder bringen.

[camouflage]

Habe mit %date und %int schon alles (un)mögliche versucht. Hat jemand eine Lösung für mich?

Dr. Google hätte dir sofort eine Antwort gegeben...

siehe z.B. hier:
http://search400.techtarget.com/tip/RPG-free-format-date-conversion-cheat-sheet

(falls noch andere Formate konvertiert werden sollen)

[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.