Re: Moving a field and removing blanks

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.