Re: Alternative to MOVEA?

Hi Barbara,

Thanks for taking the time to reply. About MOVEA, you're absolutely right
-- I guess I spaced on on %SubSt(), or I never would have asked the
question. Your claim still stands!

In general, I agree with you about MOVE -- the clever things you can do
with it  can easily come back to bite you big time, and when I was
learning RPG one of the hardest parts was piecing together exactly what
each MOVE operation did (especially the clever ones).

In our shop, our continued use of MOVE is probably due more to laziness
than anything else. Our standard is to pass parms as character values
(comes from the old days when the boss liked to test programs by calling
them from the command line), but of course we often have numeric values
(almost never with decimal points, though, and never negative -- things
like order number, line number, etc.)  Typically, in the beginning of a
program we'll MOVE all the  entry parms (all alpha) to work fields (some
alpha, some numeric) of the same size; then if we end up calling other
programs within the main program we move the work fields back to parms. I
know there are other ways to accomplish this -- I'm trying to condition
myself  to use Eval    A  = %editc(B:'X') or Eval   A = %atol(B) instead
of    MOVE B   A, but I guess I have a nostalgic fondness for the
simplicity and straightforwardness of MOVE in this particular situation.

However, that's just me and that's just this shop, so please don't
everyone flame me for being an idiot Luddite! :-) Over time, I'm sure I'll
get beyond this. . . .

rpg400-l@midrange.com writes:
>Mike, if you're asking whether I think there's a case for blessing MOVE
>and its friends by adding them to the set of free-form opcodes, then
>no, I don't think so.
>
>Your particular function of setting everything after a certain array
>element might be a common enough problem to warrant some special syntax
>to accomplish easily.  But your particular case is another one of the
>kind where the array isn't even necessary.  A simple substring will do:
>
>   EVAL  %subst(field : start) = *all'*'
>
>Regarding moving between characters and numerics, MOVE and MOVEL have
>some very odd behaviour that doesn't really have much use these days.
>Basically, the "character" form of the numeric data is really the
>zoned value.  So -12345 becomes '1234M'.  When the numeric value and
>character value are the same length, it's easy to use a zoned/character
>overlay to get the same results.  Where they are different lengths ...
>well, then you get into the really bizarre behaviour that I think would
>be better spelled out in the code.  MOVE   A   B looks too innocuous, if
>what it's really doing is overlaying the last 3 digits of B with some
>new digits, leaving the rest the way they are.



Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA  01376
413-863-4357 x444
mnaughton@juddwire.com