The EVAL operation does not perform math correctly in all situations. This problem has been acknowledged since RPG IV became available. To correct it IBM introduced the M (max digits) and R (Result field digits) operation extenders. These extenders also do not solve the problem in all situations.

The basic problem is rounding. Mathematical equations like the following, do not compute the same with EVAL as they do with traditional MULT and DIV operations.

(32.78 / 15) * 100 = ?

Using MULT and DIV, and storing the numbers 32.78 and 15 in 7-position packed fields with 2 decimals, the result is either 219.00 or 218.00 depending on whether the Half Adjust extender is used.

Using EVAL and storing the numbers in the same Pkd(7,2) fields, the result is always 218.53 regardless of whether the M, H, or R extenders are used.

You need to be aware of this difference when using EVAL.

One blunder people make is to blindly converting every existing routine to EVAL. Business rules, pricing algorithms and payroll are the most often converted routines. If these routines use the fixed format math operations today, they should probably continue doing so. Try to avoid the seduction of using one of those conversion tools to convert everything from fixed-format to EVAL operations.

I've provided an example RPG IV program that clearly illustrates the problem discussed in this article. It is 63 lines of code, and prints the results of the two styles of mathematical expressions to the printer. To compile the source code, use the CRTBNDRPG command. The program can run in the default activation group or a named activation group. If you're like me, you've already changed the DFTACTGRP parameter to *NO on the CRTBNDRPG command.