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



My two cents :

If the calling program is passing a parm (14,4),  the Return value has to match the same declaration.
I  would declare  a workfield (14,4) in the procedure  do the calculations based on a field size (31,9).
Return the value from workfield.

________________________________
From: Steven Harrison <steven.harrison@xxxxxxxxxxxxxxxxx>
To: RPG400-L@xxxxxxxxxxxx
Sent: Sunday, September 6, 2009 5:52:32 PM
Subject: Numeric parameters and return values for utility procedures

Hi All,



I am writing some new utility modules for our system that will perform
some common math functions. My question is regarding the parameters and
return values for ILE RPG programs.



I like to write the procedures so they can be utilised by any number of
programs with as little dependence on field size as possible. For
example here is a string function I have written in the past:



    P RemoveWhitespaces...

    P                B                  Export



      // Procedure Interface Definition (Parameters)

    D RemoveWhitespaces...

    D                PI        65535    Varying

    D  string                    65535    Varying Const



      // Return Variable

    D result          S          65535    Varying



      // Local Variables

    D position        S                  Like(StdInt) Inz(0)



      /FREE



      result = string;

      position = %Scan(WHITE_SPACE:result);

      DoW position > 0;

          result = %Replace('':result:position:%Len(WHITE_SPACE));

          position = %Scan(WHITE_SPACE:result);

      EndDo;



      return result;



      /END-FREE

    P                E



As you can see this procedure allows the calling program to pass in a
string of any size (up to 65535 at least!) and will return a string
value of any size (up to 65535). So all the following calls will work:



D question        S          2500

D answer          S          5000



answer = RemoveWhitespaces(question);



Or:



D answer          S          150



answer = RemoveWhitespaces('This sentence is a literal and could have
any size.');



My question is how to get this kind of functionality with numeric
functions? How can I declare a procedure that will accept a decimal
argument of any size and return a decimal argument of any size? Likewise
with integer values? I assume the calling program will need to wrap
calls in something like a monitor function to protect against field
overflow (ie. The result is too large to contain in the result field)
but I'm still a little stuck on the best way to declare the field types
in the utility modules. Do I declare something like:



D Decimal        S            31P 9



D CalculateDiscountRate...

D                                  PI        Like(Decimal)

D sellPrice                                Like(Decimal) Const

D productPrice                          Like(Decimal) Const



The problem I see though is with the return value. Say it calculates to
a value of 300.125 and the calling program has a result field of the
size 14,4. Obviously the field is big enough to contain the answer but
the field size is not going to match the size of the return variable
(31, 9). Will the iSeries allow this? Basically I want to mimic the
functionality of say a C# method where you would just use a decimal
field type (which wouldn't have any reliance on the precision of the
actual values as long as they fit within the decimal type).



Any comments or advice would be appreciated.



Steve


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.