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.

[Bogomil]

Wenn das Feld vom Typ Datum ist: DatumN = %dec(Datum: *iso)

Bei Zeichenfelder: DatumN = %dec(%date(DatumZ: *EUR.): *iso)

[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

[RobertMack]

(und mir ;- )

Gibt's aber auch komprimiert:
http://www.mysamplecode.com/2011/05/...umeric-or.html

[dschroeder]

Habe ich die Aufgabenstellung falsch verstanden? Der Code %dec(Date:*iso) würde ein "normales" deutsches Datum in JJJJMMTT drehen. Wenn er das Datum weiterhin im deutschen Format TTMMJJJJ im numerischen Feld haben möchte, muss er %dec(Date:*eur) verwenden, denke ich.

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

[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/...on-cheat-sheet

(falls noch andere Formate konvertiert werden sollen)