RE: MOVE (was: /FREE RPG compiler errors)

Got to agree with you.  I never learned the ins and outs of MOVE for two
reasons.  First I was too lazy to memorize it all, and second I really
didn't like the idea of MOVE doing anything but simple minded assignment.  I
don't like "tricky" code if it doesn't give a HUGE performance boost.  I
want to make sure a complete idiot like me can understand the program.  In
RPG Classic it's not too hard to do the other things MOVE can do without
using it.  For some things like numeric conversions using MOVE doesn't save
you much work if you take the trouble to validate the data.  I've gotten a
couple <g> of support calls in the middle of the night about programs that
use MOVE to convert character to numeric.   

> -----Original Message-----
> From: Buck Calabro [mailto:Buck.Calabro@commsoft.net]
> Sent: Wednesday, February 12, 2003 6:23 AM
> To: RPG programming on the AS400 / iSeries
> Subject: RE: MOVE (was: /FREE RPG compiler errors)
> 
> 
> >Buck Calabro wrote:
> >> c                   move      cust          suffix
> >> and then I get to find out that this is really extracting 
> >> the last three characters of the customer ID, which 
> >> nominally looks like "1234567-001".  In this example, 
> >> it's really "substring the last three characters" and 
> >> not a MOVE at all.
> >
> >Buck, assuming "suffix" is exactly big enough to hold the 
> >suffix, use EVALR.
> >   EVALR suffix = cust;
> 
> Hi Barbara!
> Yes indeed.  However...
> 
> (Opinion alert!)  This seems like multiplying by 10000.01 to 
> flip MMDDYY to
> YYMMDD.  It works, but the operation hides the intent 
> somewhat.  The "real"
> thing that's happening is that I am extracting a substring.  
> If I were doing
> this in any other language (even MI!) I would use substring.  
> In RPG II, I
> used the I specs to effectively substring.  In RPG III with externally
> defined files, *I* would have used a data structure.  Someone 
> else used
> MOVE.  In RPG IV, if I saw a MOVE I would substitute a 
> substring.  I believe
> that broadcasts the intent of the code better.
> 
> I understand the purpose of your post is to show how many of the
> straightforward uses of MOVE directly map to EVAL, but I'm 
> going a step
> beyond that and saying that MOVE wasn't the choice I would 
> have made in the
> first place.
>   --buck
> _______________________________________________