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



Hi Rory,

most XML readers ignores the number of decimals as long as they are
zero and currency should be passed as a attribute, so what is the
problem ?

/henrik




Kurt Anderson <kurt.anderson@xxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
06-04-2010 18:09
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>


To
"'RPG programming on the IBM i / System i'" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: BIFs requiring constants = frustrating






Hey Rory,

Yeah, that's essentially what I've done. I just felt like ranting, and
also opening it up in case I was taking the long way of going about coding
my procedure.

Thanks for the response.

-Kurt

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Rory Hewitt
Sent: Tuesday, April 06, 2010 11:03 AM
To: RPG programming on the IBM i / System i
Subject: Re: BIFs requiring constants = frustrating

Kurt,

Until IBM allows variables in these BIF's, you could just write a
procedure
which does basic numeric->character conversion for you, so in your in-line
code, you simply have this:

rtnAmount = charValue( Amount : w_DecPos : editCode : '*CURSYM' );

I know, I know, it's not ideal (and it sounds like you may already do (or
want to do) this anyway, but at least you have a single line in your
in-line
code, which can eventually be replaced with the variable-allowed-BIF...

Rory

On Tue, Apr 6, 2010 at 8:35 AM, Kurt Anderson
<kurt.anderson@xxxxxxxxxxxxxx>wrote:

%kds - number of keys to use has to be a constant
%dec - length and decimal positions have to be constants
%editc - edit code has to be constant

I'm working with amounts that I'm writing to XML. They can have
differing
decimal precision based on the client processed. I thought, wonderful,
I
can create a procedure, pass in some parameters, and simply insert those
parms into a statement to format my return value. If only it were so
easy.
But why isn't it? What is the purpose of making BIF parms requiring
constant values? Where is the flexibility in that? I suppose it may
be
easier on the RPG developers, but is it better for the language?

Info about my example. Amounts are already rounded to the needed
precision. Also, we go out to 6 decimals, I cut the example down to
only
going out to two decimals.

So in my example, instead of being able to code:
rtnAmount = %trim( %editC( %dec( Amount: LEN_Amount: w_DecPos ):
EditCode:
*CurSym);

I have to code:

20983 Select;

20983 When w_DecPos = 0;
20983 Amt0Dec = Amount;

20983 Select;
20983 When EditCode = 'A';
20983 rtnAmount = %trim( %editc( Amt0Dec: 'A': *CURSYM ) );
20983 When EditCode = 'B';
20983 rtnAmount = %trim( %editc( Amt0Dec: 'B': *CURSYM ) );
20983 EndSl;

20983 When w_DecPos = 1;
20983 Amt1Dec = Amount;

20983 Select;
20983 When EditCode = 'A';
20983 rtnAmount = %trim( %editc( Amt1Dec: 'A': *CURSYM ) );
20983 When EditCode = 'B';
20983 rtnAmount = %trim( %editc( Amt1Dec: 'B': *CURSYM ) );
20983 EndSl;

20983 When w_DecPos = 2;
20983 Amt2Dec = Amount;

20983 Select;
20983 When EditCode = 'A';
20983 rtnAmount = %trim( %editc( Amt2Dec: 'A': *CURSYM ) );
20983 When EditCode = 'B';
20983 rtnAmount = %trim( %editc( Amt2Dec: 'B': *CURSYM ) );
20983 EndSl;
20983 EndSl;

If I'm missing something and there's an easier way to do what I'm doing,
please let me know.

Thanks,

Kurt Anderson
Sr. Programmer/Analyst
CustomCall Data Systems
Madison, WI


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.