## Result fields in RPG/400 vs ILERPG

135 pts.
Tags:
ILERPG
RPG ILE
RPG/400
When coding in RPG400, the result of a calculation can be larger than the size of the result field, like this: D Fld1 s 2 0 Inz(20) D Fld2 s 2 0 Inz(10) D Fld3 s 2 0 Inz C Fld1 mult Fld2 Fld3 Fld3 will contain a value of 0 after the code is executed. However, when coding in ILERPG: D Fld1 s 2 0 Inz(20) D Fld2 s 2 0 Inz(10) D Fld3 s 2 0 Inz C Eval Fld3 = Fld1 * Fld2 This line of code will not execute since the result of the calculation is larger than the size of the result field. Other than increasing the size of the result field (which is not always doable), DOes anybody know if there is a way around the problem? I've had to change several programs written in free format back to RPG/400

Thanks. We'll let you know when a new response is added.

Hi TopKat

Here is one, of many ways to get the last two digits.
This could easily be put into a sub-procedure.
HOWEVER YOU WOULD HAVE TO SHOOT ME BEFORE I WOULD USE IT!

D Fld1 s 2 0 inz(20)
D Fld2 s 2 0 inz(30)

D wrkFLDDS ds
D wrkFLD 15S 0
D fld3 14 15S 0
D
C eval wrkFLD = Fld1 * Fld2

HOWEVER,
– I can understand situations where the results won’t fit
– I cannot understand when you would not want an error message or some corrective code when that occurs.

If the customer orders 100 pieces at \$1000.00 each you would bill them 000.00? because the correct value

RPG III/400 masked the error and you don’t like errors?

Correct procedure might be:

D Fld1 s 2 0 Inz(20)
D Fld2 s 2 0 Inz(10)
D Fld3 s 2 0 Inz

C Monitor
C EVAL Fld3 = Fld1 * Fld2
C ON-ERROR
C eval fld3 = 00
c eval ERRFLG = *ON
C ENDMON

Phil
////////////////////
Oh not for invoice amount, then when is it
appropriate to drop the most significant digits?

////////////////////////////////

Thanks CWC

MOVE will work in RPGLE like it did in RPG/400 if you add
TRUNCNBR(*YES) to the H spec. The MOVE is not available in Free Format.
So there is no reason to use RPG/400 but this is all covering up
a serious design problem.

60 * 2 is not 20, never will be 20, not even in new math!

If the 60 was due to a communication error then the report should say ‘* COMMUNICATION ERROR *’ not 20!

Phil

**********
I rarely miss the loose behavior of MOVE and don’t even use it any more since it’s not supported in free format. Assignment statements (via an implicit EVAL operation) combined with the built in functions plus the ability to create our own provide more control over the end result, which I think is preferable.

Thus, I don’t look at the non-availability of MOVE and its variants as a problem, but rather a tightening up on the rules which led to bad practices in the past. Its use with numeric data tends to create some unintended problems which are out of sight and out of mind until they’re discovered down the line and require research to figure out and correct. I think this was one of IBM’s good reasons for not implementing MOVE in free format. And this is more consistent with other environments and languages such as Java and .Net.
CWC