× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.