RE: The target for a numeric operation is too small to hold theresul t (C G D F)

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx / Ted J Barry
> Sent: Saturday, July 24, 2004 11:33 AM
>
> I have a similar situation where I have two different database
> fields. The result field is 10, 4 and the other is 11,4.
> Obviously too small, but what if you don't want to go around
> changing all of the database fields? Is there a routine anyone
> knows of to handle getting the result you want without having to
> change the db?

In a scenario like this, I define a program variable 30,4 and use that as my
own intermediate result field for the math problem.  I move *HIVAL to the
intended DB variable, then compare the two values.  If my 30,4 variable is
greater than the *HIVAL of the DB variable, then I know I've got an overflow
situation, and I have to invoke error handling.

Obviously, if dealing with negative numbers, you'd have to test with *LOVAL
as well.

BTW, I never have this issue with DB fields, but with display & printer
fields, as we attempt to show results that fit in a given space.  If 9,2
works w/o overflow problems 99.999% of the time, and we don't have space to
show 10,2, then my error handling fills the display/printer field with
*HIVAL (or *LOVAL, as appropriate) nines, and I'll show/print a message that
indicates the true value.  (Thank goodness for %trim(%edtcde(n:'L')) !)

hth,
db