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

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.

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.