EVAL-Statement ->Ergebnisfeld zu klein

[Marchfeld]

Hallo RPG-Spezialisten!
Habe das Probelm, daß nach einem EVAL-Statement mit Berechnung der Fehler "RNQ0103" = "Ergebnis ist für das Ziel zu groß" ausgelöst wird. Was kann ich da machen? Kann ich das abfangen, sodaß es zu keinem Absturz kommt?
Bin für jede Antwort dankbar!

[Robi]

Wir haben dafür ne procedur, die heisst rechne

empfang numerisch 30,6 (die rechnung)
empfang nmerisch 2 0 vorkommastellen des zielfeldes
empfang numerisch 1 0 nachkommastellen ...,
empfang Rundungskennzeichen (auf, ab, kaufm.) wahlweise
empfang rnd genauigkeit wahlweisr


aufruf :

eval feld=rechne(die wildeste formel die mann sich vorstellen
kann:9:2:1(=aufrunden):0,1)

die procedur gibt Hival zurück bei feldüberlauf

Gruß Robi

[Marchfeld]

Danke, aber genau das ist ja mein Problem; wie behandelt denn die Procedure den Überlauf? Wie kann ich das abfangen?
Bitte noch einen Tipp, dank!

[Robi]

Die procedur empfängt 30,6.
Das läuft nicht über

und sie kennt die größe des ergebnissfeldes
also wird anzahl kommagerecht verglichen

(über alpha felder und %substr), mit null überschreiben ...


hilft das
Robi

[B.Hauser]

Hallo,

wenn Du bereits auf Release V5R1M0 oder höher bist, kannst Du den Feldüberlauf mit einer Monitor-Group handeln.

Beispiel:

/Free
    Monitor;
         Ergebnis = FeldA * Feldb / (FeldC - 2**10);
    On-Error  103;              //Feldüberlauf
         Ergebnis = *HiVal;
    On-Error  102;              //Division durch Null
         Ergebnis = *Zeros;
    On-Error;                       //sonstige Fehler
         Ergebnis = *Zeros;
    EndMon;    
/End-Free 

Mit der Monitor-Group kann jeder Fehler, in einem Statement, Programm, Prozedur abgefangen werden.
Die Monitor-Group kann auch anstatt der (E)-Erweiterung bzw. der mittleren Bezugszahl verwendet werden.

Vor Release V5R1M0 musst Du einen Feldüberlauf über eine If-Abfrage abfangen:

Beispiel:

D Erg             S              5  2 inz(*Zeros)                  
D MaxErg          S                   like(Erg) inz(*HiVal)                   
                                                                   
D Fakt1           S              5  2 inz(999,99)                  
D Fakt2           S              3  0 inz(999)  

C                   if        MaxErg     > %abs(%float(Fakt1 * Fakt2))
C                   eval       Erg        = Fakt1 * Fakt2              
C                   else
C                   eval       Erg        = *HiVal                       
C                   endif 

Birgitta

[Marchfeld]

Herzlichen Dank für alles !!!
Das hat geholfen.

[Robi]

Ich schätze du hast meine Lösung nicht verstanden
macht nix,
Überleg die nur,
ob du in jedem PGM die Monitorgroup oder den Vergleich codieren willst oder es einmalig in einem *srvpgm hinterlegen willst
Robi

[loeweadolf]

Ich finde es ja schlimm, dass die in den letzten Jahren eingeführten RPG-Erweiterungen teilweise zwingen, umständliche Prüfungen vorzunehmen.
Ein paar Mal habe ich auch unliebsame Erfahrungen mit Feldüberlauf beim EVAL (Programmabbruch) gmacht, und zwar in Fällen, in den der Überlauf gewollt war.

In diesen speziellen Fällen helfe ich mir jetzt folgendermassen:
a) Ergebisfeld als möglichst großes Feld definieren
b) anschl. mit dem guten alten Z-ADD den Wert übertragen in
das eigentliche Ergebnisfeld.


Nicht alles, was man heute im RPG IV nicht mehr verwenden sollte, war schlecht.

mfg. Ludger

[B.Hauser]

Hallo Ludger,

mir persönlich ist es lieber, wenn ein Programm abbricht und einen sauberein Rollback macht, als wenn eine führende Ziffer in einem Feld abgeschnitten wird.

Kaum beim nächsten Monatsabschluss und ein paar 10.000 Euro später holt einem das Ganze ein!
Und der Zeitaufwand, um den Fehler zu finden und das Desaster dann zu bereinigen ist erheblich!

Deshalb ist die erste Devise sowieso, ein Feld so gross zu definieren, dass der Maximal-Wert aufgenommen werden kann.
Werden Summen oder Produkte ermittelt, kann man das Ergebnis-Feld in den D-Bestimmungen über Schlüssel-Wort LIKE erstellen und vorsichtshalber 1 oder 2 Stellen zufügen.
(Mit *LIKE DEFINE in den C-Bestimmungen kann der gleiche Effekt erzielt werden. Da die Definition in den C-Bestimmungen im RPG-Free-Format nicht mehr unterstützt wird, sollten alle Felddefinitionen in den D-Bestimmungen erfolgen.)

Und, nimm's mir nicht übel Ludger, ein gewollter Feldüberlauf ist für mich keine saubere Programmierung sondern Mauschelei um nicht zu sagen Pfusch!

Birgitta

[loeweadolf]

Hallo Birgitta,

Einen Feldüberlauf zu programmieren kann sehr wohl gewollt sein, es kommt auf die Art der Anwendung an. Natürlich darf so etwas z.B. nicht in der Finanzbuchhaltung vorkommen.

Im techn. Bereich kann es durchaus Bereiche geben, wo dieses gewollt ist. Bevor man dann zu so was unsaubere Programmierung, Mauschelei bzw. Pfusch sagen würde, sollte man doch ein bißchen vorsichtiger sein, vor allem dann, wenn man keine Ahnung hat, um was es sich handelt.

Ludger