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


  • Subject: Re: [Re: [Re: RPGILE V4.3 Gotcha]]
  • From: Frank Kolmann <fkolmann@xxxxxxxxxxxx>
  • Date: 1 Oct 99 11:16:41 EST

Gee, thanks Hans.  The mind boggles. Almost makes me want to code in RPGII and
never do another EVAL again. (only kidding, but will certainly be more
caerful)

PS.  We never got no manuals with V4.3 , I had to download the thing off the
net, and its sure got a lot of differences, have not got up to speed yet
(mabey never will). >:)



boldt@ca.ibm.com wrote:
> 
> 
> Frank wrote:
> >The point I am making is that the program work fine as RPGIV ILE code under
V4
> >R2 .  When we went to V4 R3 it produced the gotcha.
> 
> This is what I don't understand about your note.  The V4R3 ILE RPG
> compiler is exactly the same compiler you used under V4R2.  No
> difference.  (Except perhaps for additional PTFs, but these wouldn't
> change the behaviour of the arithmetic precision rules.)  Except for
> some additional options, the precision rules haven't changed since
> V3R1.
> 
> >How many other instances
> >are out there waiting to pop up?  I needed to put in the new BIF %DEC so
that
> >the program procuded the correct result at 3 decimals.  The bit about
> >precision is a mystery to me.  What is the difference between decimals and
> >precision.
> >
> >Anyway all the formulae should produce the same result, they do not.
> 
> This question pops up occasionally, especially for those new to ILE
> RPG IV.  (Is anyone out there writing up a FAQ list?)
> 
> Have you read Chapter 21 of the ILE RPG Reference?  Expecially the
> section called "Precision Rules for Numeric Operations"?  Basically,
> whenever you have complicated arithmetic expressions, the results of
> individual operations are stored in compiler generated temporary
> variables.  The sizes of these temps is determined by the sizes of the
> operands.  For example, if you multiply two decimal values, say a (10,2)
> value times a (5,3) value, the result is a decimal value with precision
> (15,5).  But in cases where the natural precision of the result is
> greater than 30 digits, we truncate down to 30 digit precision.  In
> order to minimize the likelihood of numeric overflow, we first reduce
> digits to the right of the decimal point.  Table 35 (in Chapter 21)
> lists the rules for all operations.
> 
> Let's look at one of your statements in detail:
> 
>        EVAL(H)   DAABE(07) = RCDNC1 / 100.00 * DTITRD * DTIQNS
>                              (11,3)   (5,2)    (15,4)   (11,3)
> 
> The evaluation of this expression proceeds as follows:
> 
> 1) RCDNC1 / 100.0    ->   (11,3) / (5,2)     =>  (30,20)
> 2) (temp) * DTITRD   ->   (30,20) * (15,4)   =>  (45,24) => (30,9)
> 3) (temp) * DTIQNS   ->   (30,9) * (11,3)    =>  (41,12) => (30,1)
> 
> As a result of applying the precision rules, you end up with a
> decimal precision of (30,1), which is what you see in the answer.
> (I'll leave it to you to work out how the other answers are computed.)
> 
> As someone else already mentioned, perhaps what you should do is
> code EXPROPTS(*RESDECPOS) on the H-Spec.  This ensures for all
> decimal expressions that the number of decimal positions in temporary
> variables never drops below the number of decimal positions in the
> corresponding result variable.  (You could also code opcode extender
> R on the EVAL.)  This is probably better than using %DEC to control
> intermediate result precision.
> 
> In the example above, using *RESDECPOS, the precision of the result
> in step 3 would be (30,4).  The result variable has precision (15,3).
> The compiler adds an extra digit of precision because you also
> specified half-adjust on the EVAL.
> 
> Note that using *RESDECPOS is not a general panacea, since it cannot
> work in cases where there is no result, such as in logical expressions.
> 
> Cheers!  Hans
> 
> Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
> 
> 
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---


____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at 
http://webmail.netscape.com.
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.