Dezimaldaten

[DKSPROFI]

Hallo Froum,

seit neuestem gibt es immer dann einen Abruchfehler, wenn ein Programm Neu kompiliert wird.
es handelt sich hierbei um eine Datumseingabe ins Bild, wenn die Engabe geprüft ist, dann passiert folgendes:

Beim Übertragen der Werte kommt es plötzlich zu einem Dezimaldatenfehler bei folgendem Statement;

Numdat = 08022024 ;
isodat = %Date ( Numdat : *ISO ) ;

Dort wird immer abgebrochen.

Habt Ihr any Ideas?

[Fuerchau]

Das Format des numerischen Feldes muss stimmen:
TTMMJJJJ = *EUR0
JJJJMMTT = *ISO0
Das Zielfeld kann ein anderes Format aufweisen, es wird dann umgerechnet.

Die 0 steht für "ohne Trennzeichen".

Wobei Bildschirmfelder inzwischen DATE-Felder korrekt unterstützen.

[DKSPROFI]

Hallo zusammen,

Ich habe mir beholfen:

isodat = %Date ( Numdat : *EUR ) ;
isodat1 = isidat ;

Funktioniert, nicht schön, aber selten.

[B.Hauser]

Wieso musst Du das nochmal umlanden?

Beim Konvertieren eines numerischen bzw. alphanumerischen Datums wird im 2. Parameter das Format des numerischen oder alphanumerischen Datums übergeben. Fehlt der 2. Parameter wird davon ausgegangen, dass das (alpha)numerische Datum im *ISO-Format übergeben wurde.
Das Datum selber ist (under the cover) ein fortlaufender Zähler (Scaliger No), der (lt.Documentation) am 01.01.4713 BC (Beginn Julianischer Kalender) aufsetzt. Datums-Formate sind lediglich dazu da, um diese Zahl lesbar zu machen. In RPG wird die Scaliger No in einen alphanumerischen String konvertiert und abh. vom Datums-Format der Variablen (D-Bestimmung/H-Bestimmung) aufbereitet. Unmittelbar vor dem Fortschreiben wird die alphanumerische Aufbereitung des Datums wieder in die Scaliger No konvertiert.
Deshalb muss auch das Ziel-Format beim Konvertieren mit %Date() nicht angegeben werden.

Birgitta

[DKSPROFI]

Hallo Brigitte,

ich habe das deshalb so gemacht, da sonst nicht funktioniert.

[B.Hauser]

Ich weiß nach wie vor nicht warum es nicht funktionieren sollte!
Das folgende Programm wird beim mir ordnungsgemäß kompiliert und auch ausgeführt:


DCL-S DateEur Date(*Eur);
DCL-S DateIso Date(*Iso);

DCL-S DateNum Packed(8) inz(*Zeros);
//--------------------------------------------
DateNum = 14022024;
Dsply DateNum;

DateIso = %Date(DateNum: *EUR);
Dsply DateIso;

DateEur = %Date(DateNum: *EUR);
Dsply DateEur;

DateNum = 20240215;
Dsply DateNum;

DateIso = %Date(DateNum);
Dsply DateIso;

DateEUR = %Date(DateNum);
Dsply DateEur;

*INLR = *On;

Das Ergebnis sieht wie folgt aus:
673

Noch eine kleine Anmerkung: ich heiße BIRGITTA und nicht Brigitte oder Britta oder sonst irgendwas. Wenn Du Dir nicht sicher bist, lass ihn weg.

[Fuerchau]

Wie oben bereits gesagt:
"Das Zielfeld kann ein anderes Format aufweisen, es wird dann umgerechnet."

[BenderD]

Hallo Froum,

seit neuestem gibt es immer dann einen Abruchfehler, wenn ein Programm Neu kompiliert wird.
es handelt sich hierbei um eine Datumseingabe ins Bild, wenn die Engabe geprüft ist, dann passiert folgendes:

Beim Übertragen der Werte kommt es plötzlich zu einem Dezimaldatenfehler bei folgendem Statement;

Numdat = 08022024 ;
isodat = %Date ( Numdat : *ISO ) ;

Dort wird immer abgebrochen.

Habt Ihr any Ideas?

... wenn das nach recompile passiert, muss sich was an extern deklarierten Feldern geändert haben. Externe Datenstrukturen, Dateifelder, Displayfiles oder Deklarationen in Copystrecken. Das kann auch durch libl passieren. Da würde ich mal genauer analysieren, bevor ich das mit irgendwelchen Blindreparaturen bearbeite.

D*B

PS: Es heißt Forum und nicht Froum, wenn Du nicht sicher bist, lass es lieber weg.

[Fuerchau]

Vielleicht wurde statt Froum eben Frodo gemeint?

[BenderD]

Vielleicht wurde statt Froum eben Frodo gemeint?

Baldor ist heute zu Scherzen aufgelegt.