|
> The conversion also does not change "X ADD Y Z"
> statements to the "Eval z = x + y".
This presumes using the IBM CVTRPGSRC command. 3rd party utilities
_might_ create EVAL out of MOVE, etc...
> And there are some rules regarding overflow
> that cause these otherwise identical statements
> to behave differently that you need to
> learn about.
Before using expressions (EVAL, etc.) have a read in the manual where
it describes how expressions work. Basically, using expressions as
opposed to
one
complete
calculation
per
line
means that the compiler needs to store intermediate results within
internal work fields. Those work fields are defined by rules
published in the section entitled 'intermediate precision.' A quick
example may help:
Say you have the following RPG III code:
C Z-ADD500 KB 30
C KB MULT 1024 BYTES 30
C BYTES MULT 8 BITS 30
C BITS DSPLY
C SETON LR
Somewhere, you specifically gave a size to kb, bytes and bits. If you
run this code, you'll find that BITS is 0. That's because MULT
silently truncates the results when overflow occurs. Run this code
through CVTRPGSRC and you get something quite similar - similar enough
that you won't notice the 'learning curve':
H DEBUG
C Z-ADD 500 KB 3 0
C KB MULT 1024 BYTES 3 0
C BYTES MULT 8 BITS 3 0
C BITS DSPLY
C SETON
LR
If you modify this to use EVAL instead of separate lines of code, you
might have:
H DEBUG
d kb s 3p 0 inz(500)
d bits s 3p 0
c eval bits = kb * 1024 * 8
C BITS DSPLY
C SETON
LR
Run this and you'll get:
Message . . . . : The target for a numeric operation is
too small to hold the result (C G D F).
That is because RPG IV won't let you silently lose your data. This is
perhaps the main difference between EVAL (and other operations that
allow expressions) and the traditional calculation operation codes.
The compiler creates a temporary work field to store 'kb * 1024'. How
large a field does it create? When the runtime tries to assign the
value of the temporary work field to bits (3/0), it sees that you will
lose some of the digits, so it complains about it.
The moral of the story: Read up on intermediate precision. Search the
archives here, and try to determine (without cut & try) what you need
to do to make this little example work properly.
--buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.