Datum in numerisches Feld bringen in Free-RPG

[ubas]

Hallo zusammen,

habe das Problem das ich ein Datumswert (z.B. 28.10.2014) in ein 8stelliges numerisches Feld bringen muss. Das ganze in Free-RPG. Habe mit %date und %int schon alles (un)mögliche versucht. Hat jemand eine Lösung für mich?

[Fuerchau]

Das ist nur mit "%dec(Date:*iso)" möglich.

[Fuerchau]

Ich weiß gar nicht, wofür die IBM eigentlich die schönen PDF-Handbücher rausbringt wenn da (außer mir) sowieso keiner reinschaut.

[KingofKning]

Na ja, früher haben die Pappnasen sich auch noch die Mühe gemacht die Bücher in Deutsch rauszubringen, die Kohle schenken sie sich jetzt auch schon.GG

[ubas]

Ich weiß gar nicht, wofür die IBM eigentlich die schönen PDF-Handbücher rausbringt wenn da (außer mir) sowieso keiner reinschaut.

Schlaumeier, hätte ich das Beispiel im Handbuch gefunden, hätte ich mich bestimmt nicht hier gemeldet. Ironie kannste behalten, den Rest nehme ich.

[Fuerchau]

Ich finde die Sachen ja auch nur im Handbuch , manches probiere ich da sogar aus.

Ansonsten kann man bei der Konvertierung eben angeben was man will:
%dec(Datum:*iso) => JJJJMMTT
%dec(Datum:*eur) => TTMMJJJJ
%dec(Datum:*jul) => JJJJTTT

[B.Hauser]

Vielleicht zur Erklärung:
Ein echtes Datum ist ein numerischer Wert (sogenannte Scaliger Nr.).
Datums-Formate werden nur dazu verwendet, um den numerischen Wert lesbar zu machen.
In RPG wird die Scaliger Nr. immer beim Lesen in eine alphanumerische Repräsentation des Datums konvertiert, abhängig vom Datums-Format in den D- oder H-Specs. Ist weder in den D- noch in den H-Specs ein Datums-Format vorgegeben wird das Format *ISO verwendet.
Unmittelbar vor dem Zurückschreiben wird das alphanumerisch aufbereitete Datum wieder in die Scaliger Nr. konvertiert.
Bei dem Format, das in der Built-in-Function %DEC angegben wird, handelt es sich immer um das Ausgabe-Format, da das eigentliche Datum lediglich die konvertierte Scaliger Nr. ist.

Birgitta

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

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