Re: Target for numeric operation too small

Tony,

Not to rant at you specifically, but yours is just the post I happened to pick
to respond to in general.

Rant(*On)

>I agree with the former posts...we need an H-spec which quiets this error.
>The ridiculous numbers are the problem, like the percentage stated
>previously.

No you don't, you just need different coding styles.  Percentages are about the
only thing where I'll accept the fact you may not want to enlarge the field to
handle the potential cases, due to space constraints in dspf/prtf layouts.

But I *still* don't want truncation.  I want the percentage to print as
something like ++++++ or even 999.99% but I *don't* want 1002.34% to be printed
as 2.34% just because the report only had room for a percentage field defined as
5 digits with two decimals.

RPG IV makes this so easy.  Just make a subprocedure to calculate the
percentage.  Pass it the two values and the maximum percentage allowed.  In the
subprocedure you perform the test to make sure the divisor is not zero, then
compute the actual percentage variance.  Compare the absolute value of this to
the maximum allowed percentage.  If with range, return the actual variance,
otherwise return the maximum variance preserving the sign (eg +999.99 or
-999.99).

This makes the inline calculations VERY simple and readable, and simultaneously
solves the problems of zero divisors (which you may not want to report as 0% but
instead return the maximum or some people may say 100.00%), and also solves the
problem of percentages exceeding the range for which you have room to print or
display.

Subprocedures seem so very underutilized to me.  They are great for "extending"
the language for things like this.  This works all the way back to V3R2.  Why do
people keep clamoring for features which may help them years down the road, when
a few minutes of coding a service program routine solves the problem *now*?

And in this particular case, like many others, I *want* the program to have a
hard halt if I didn't consider the range of possibilities.  That is NOT the
fault of IBM -- it would be mine alone.

Switching to RPG IV did not cause the bug.  And IBM's conversion didn't even
switch the arithmetic to EVAL for that very reason.  This was either done by a
programmer, or a non-IBM utility.  So noone can blame IBM.  The field was always
too small.  Wouldn't you rather know about it rather than suppress it?

Who wouldn't rather have 999.99% print instead of 2.34% when the real variance
was 1002.34%?  I can't think of a single valid case for using truncation,
including the calculation of percentages.  And please, let's not say reformating
dates is a valid use of truncation!

Depending on the report and the expected range of variance, I may allow more
than a maximum variance of 999.99%, but I'd never agree that simply dropping the
left hand digits is appropriate.  Like Barbara points out, I don't accept that
on my paycheck either!

>While we're at it, a Move(E) would be good for those invalid date problems.

Again, what's the big deal?  Just create service program subprocedures which do
whatever logic you want.  Code it once, put it in a binding directory with
prototypes in a /Copy member, and forget about it.

I want Toronto to spend their efforts adding features which I *can't* already do
readily with subprocedures in service programs.  This kind of stuff is just too
easy to deal with yourself -- once -- and move on to the business problem at
hand.

Over time you should find you get a good collection of "tools" in your service
program collection.  I group mine by functionality: one for all date routines,
one for string manipulations, another for using user spaces, another for mesage
handling APIs, yada, yada.  All I need to do is name the binding directory and
add a simple /Copy for each group of prototypes to be brought into the program
(dates, etc).

Rant(*Off)

Doug