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