Result fields in RPG/400 vs ILERPG

135 pts.
Tags:
ILERPG
RPG/400
RPGILE
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

Answer Wiki

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
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

Discuss This Question: 2  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TopKat
    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.
    135 pointsBadges:
    report
  • Cwc
    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.
    4,290 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following