Dezimaldatenfehler

[Bratmaxxe]

Moin Zusammen !

Ich habe ein RPG III Subfile - Programm an geänderte Bedingungen angepasst, neu umgewandelt (CVTOPT *DATETIME) --> funktioniert.

Da das Debuggen bei RPG III Programmen ziemlich lästig ist, dachte ich mir das Programm nach RPG IV zu konvertieren.
Gesagt getan, Programm dann ebenfalls neu umgewandelt (CVTOPT *DATETIME) --> und nun funktionierts nicht mehr (Dezimaldatenfehler).

Woran kann das liegen ?

Gruß
Bratmaxxe

[Fuerchau]

Diese Angaben sind ja etwas dürftig.
"Normalerweise" sollte es da keinen Unterschied geben, aber ...

MOVE ignoriert die meisten Dezimal-Fehler, EVAL nicht.
RPG wird ggf. mit "Dezimalfehler ignorieren" umgewandelt (siehe DSPPGM), bei ILERPG gibts das nicht mehr.

Fazit:
Die Fehler gabs früher schon, werden mit ILE aber jetzt erst gemerkt.

[Bratmaxxe]

Danke für die Info....

Gruß
Bratmaxxe

[B.Hauser]

Hallo,

füge mal den folgenden Eintrag in den H-Bestimmungen ein:
H TRUNCNBR(*YES)

In RPGIV werden führen Überläufe in numerischen Feldern grundsätzlich zu einem Abbruch und zwar unabhängig davon, ob MOVE oder ein anderer OPCODE verwendet wurde!

Es sei den man gibt dieses Schlüssel-Wort entweder im Compile Command oder in den H-Bestimmugen an. Dann werden die Feldüberläufe wie in RPGIII gehandelt, also notfalls vorne abgeschnitten!

Aber "Schweinereien" funktionieren nur in Verbindung mit den alten OpCodes, wie Z-ADD, ADD, SUB, Z-SUB, MULT, DIV und MOVE. Bei einem Feldüberlauf mit neuen OpCodes oder mit Built-in-Funktionen erfolgt auch dann ein Abbruch, wenn dieses Schlüssel-Wort angegeben wurde.

Da diese Option eigentlich "Pfusch" ist, wird sie per Default nicht verwendet. Aber für Fälle, wie in Deinem, wird gewährleitstet, dass Programme sich nach der Konvertierung genauso verhalten wie vorher.

Birgitta