Re: The target for a numeric operation is too small to hold the resul t (C G D F)

[Ken Sims <mdrg4136@xxxxxxxxx>]

Hi Ted -

>  In response to Scott Klement with Rob Berendt's additional comment:
>
>  What Rob said I guess?!  I just don't want to have to go to each db that 
> has the field that is smaller in size and have to make it bigger.  Did 
> Z-ADD just drop all digits to the left of decimal that wouldn't fit?  I 
> guess I'm looking for some easier solution to EVAL.  What would most 
> folks do in this situation, without having to change database field sizes?

If the problem is in an intermediate work field, often times the problem 
can be solved by rearranging the order.

E.g. change
  eval  d = (a / b) * c
to
  eval  d = (a * c) / b

Division should always be as late in the calculation as possible.

Where that is not possible, %dec or %dech can be used to force the 
expression within to a known good precision.  (Splitting it into multiple 
evals with all but the last going into work fields accomplishes the same 
thing.)

You can also use the H-spec EXPROPTS keyword and the EVAL opcode extenders 
to control the way the compiler assign intermediate result field sizes, but 
I prefer to do it explicitly.

If the problem is NOT an intermediate work field, but that the result is 
just plain too big to fit, there are ways to handle that as well.

If having the exact result is not critical, I like to eval into a work 
field that is big enough to contain any possible result, then compare that 
result to the maximum value that will fit.

E.g.
  eval big_ol_work_field = expression
  select
  when big_ol_work_field > 9999999.99
  eval real_field        = 9999999.99
  when big_ol_work_field < -9999999.99
  eval real_field        = -9999999.99
  other
  eval real_field = big_ol_work_field
  endsl

If the result is critical, then I would add some kind of error report that 
would be written to in the two WHENs.

You also can use the MONITOR opcode to monitor for an overflow in an eval 
(or another operation or set of operations).  This is new in V5R1.

--
Ken
http://www.ke9nr.net/
Opinions expressed are my own and do not necessarily represent the views of 
my employer or anyone in their right mind.