Result fields in RPG/400 vs ILERPG
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
Software/Hardware used:
Software/Hardware used:
ASKED:
February 27, 2009 5:34 PM
UPDATED:
March 3, 2009 5:38 PM
Answer Wiki:
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
wouldn't fit in your field?
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
To see all answers submitted to the Answer Wiki: View Answer History.
Actually, if I were producing an invoice, I would make sure that the result field was the proper size. My reports are receiving data pulled from a j-bus connection in commercial tractor-trailer rigs and making calculations. There are times when the data coming across are way out of whack. A zero value would indicate that there was a problem with the data coming in from the j-bus, and the rig could be pulled in for maintenance.
I would never, ever recommend going back to RPG/400 (III) just because of something like this. This is not a difference between RPG III and IV; it’s a difference in how the MOVE operation truncates data, while the EVAL operation does not. The MOVE is more forgiving, but that’s not necessarily a good thing. RPG IV still supports MOVE in the fixed format, so you could still use that operation as long as the truncation won’t cause a problem for your application. Otherwise, as Phil suggested the MONITOR operation code is quite handy.