Re: Target for numeric operation too small...hello, Toronto?

Reeve wrote:
>Hans, with great respect I say your answer blames the victim.
>
>This is a possibility for many programs converted to RPG IV, and it's not
>necessarily a "logic" error.  You're asking us to EVALuate every line of
>converted code and consider if a numeric overflow could occur.  I haven't
>had many overflows, but I've had enough to know it's a pain.
>
>The manner in which RPG IV presents this error is unfriendly, and IMHO
this
>issue is one of the biggest reasons people aren't moving to RPG IV and ILE
>RPG.  I think this issue needs some consideration in the Lab.

We have considered the issue.  We've considered it a lot in fact.

Masking numeric overflow within expressions would simply have far
worse consequences than any possible benefits.  Numeric overflow
is almost always caused by incorrect logic in your program, and so
allowing overflow without an exception would be a tremendous
disservice to RPG programmers.  (And for those few programs that
count on truncation, there are better alternatives.)

In RPG III, you have complete control over how a computation
proceeds by explicitly coding intermediate variables.  Within RPG
IV expressions, the compiler must make a best guess as to
appropriate precisions for the intermediate values.  As a result,
what happens within a computation isn't as clear.  If you arrange
the steps of the computation incorrectly, you may well get
intermediate values that get too big (or possibly too small).
Understanding how expressions get evaluated is thus much more
important in RPG IV.  Study carefully Chapter 21 of the ILE RPG
IV Reference manual.

(I learned programming 25 years ago starting with a PL/I subset
language called SP/K.  Even in that first programming course, I
learned the importance of carefully coding numeric expressions to
avoid overflow!)

Also, in RPG IV, you're not just dealing with decimal numerics.
What happens when you mask overflow on an integer or unsigned
expression?  You don't just get truncation of high-order digits,
you get truncation of high-order bits!

When dealing with floating point expressions, you might think a
lot of problems go away because of the incredible range of float
values?  No, even with float numbers you can't get away from the
necessity of understanding how the arithmetic works.  With float,
you don't just worry about overflow - you also have to consider
potential numeric underflow.

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com