× 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: How to fins TCP/Ip Address
  • From: Dinesh Goyal <din_goe@xxxxxxxxx>
  • Date: Thu, 30 Sep 1999 08:21:13 -0700 (PDT)

Can any body tell me how to find out TCP/IP address of
the AS400 m/c I am working on?


--- 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
> +---
> 

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.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-Ups:

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.