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



nah, I trust Barbara's coding skill a bit better than my own. Plus, she can
probably comes up with something that is really easy to use like "rate =
%move(char7)", which I won't be able to do if I would have to create one on
my own.





<BMay@xxxxxxxxx> wrote in message
news:mailman.17571.1291320332.2702.rpg400-l@xxxxxxxxxxxxxxx
So if this is something you do often, write a subprocedure to hide any of
the complexity. Or better yet, stop putting numeric data in character
fields without proper decimal points.

Brian May
Project Lead
Management Information Systems
Garan, Incorporated
Starkville, Mississippi



"hockchai Lim" <lim.hock-chai@xxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
12/02/2010 01:55 PM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>


To
rpg400-l@xxxxxxxxxxxx
cc

Subject
Re: Moving a field and removing blanks






I agreed that O extender is probably not very useful and I can eaily live
without it. But there is one feature in MOVE opcode (I've not used this
opcode for years now) that I sometime wish I can have that in free form.
The feature that I'm speaking of is its ability to move a char string into
a
numeric field. Well, yes, I can use %dec, %int... to achive that. But
those bif requires actual decimal point to be present in the char string
for
it to work correctly.

Now look at the code below. The value of the rate would be 12345.67,
which
is what I wanted, after executing the MOVE statement.:
D char7 S 7a inz('1234567')
D rate S 7 2

C move char7 rate
. . .

to do this samething in free form, I'll have to do some calculations, not
bad, but it always makes me think that the program is trying to perform
some
calculation that is related to some sort of a business requirement.

So to achieve the samething as MOVE opcode, I've to do this:
rate = %dec(char7 :7 :0) / 100
or
rate = %int(char7) / 100

and if the char7 happens to contain the value of blank, the above code
will
blow up. MOVE opcode, on the other hand, will set the rate to 0.00. Oh,
how I miss the MOVE ...... :)


"Scott Klement" <rpg400-l@xxxxxxxxxxxxxxxx> wrote in message
news:mailman.17546.1291313969.2702.rpg400-l@xxxxxxxxxxxxxxx
I agree that this O extender is probably not worth doing. As others have

pointed out, you can solve this problem using %subst or %replace, even if

the code isn't quite as elegant as we might want.

And how often does someone need to do something like this? I do a _ton_

of string manipulation of all sorts, but almost never need something
like
this where data has to be both left-justified and right-justified in the

same field. Indeed, I can't think of any reason why someone would need
something like this -- although Pete obviously needs it, it might be the

only time he ever will.

On 12/1/2010 7:50 PM, Barbara Morris wrote:
I suppose there could be an extender, say O for Overlay, for EVAL and
EVALR, not to pad the remainder with blanks. That idea has been
kicking
around for a long time, but there is a perceived lack of general
usefulness for this feature. Notwithstanding this current case.



--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.





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.