Re: "The evils of MOVE" by (Barbara Morris?)

On 3/25/2014 4:12 PM, CRPence wrote:

On 25-Mar-2014 12:28 -0700, Charles Wilt wrote:

I seem to recall seeing an article or post by Barbara that provided
considerable detail into the intricacies of MOVE and why IBM
depreciated <sic> it by not including it in free form.

Now that fixed-form can appear with little effort or the conspicuous
/free and /end-free tags, any implication that the instructions were
deprecated seems somewhat insincere.

I'm a sucker for these debates. One of my many character flaws.

MOVE still requires a C in column 6, the letters MOVE in columns 26
through 29, the source in columns 36 through 49 and the destination in
columns 50 through 63. If one were to indent that, one would be
showered with compiler generated epithets. It need not be noted that
indentation is perhaps the entire point of free form code.

In my mind, I'm calling it "The evils of MOVE"... shades of "The
evils of GOTO" :)

Does anybody else recall this and more importantly do you have a
link to it?

I tried looking, but had no luck. I tried several variants, including
'MOVE considered harmful'.

No, but IMO the documentation for the various MOVE* instructions do a
fine job of revealing their evils; i.e. a slew of nuanced effects noted
to be based on the numerous variations on source and target data types
and different sizes.

My well-worn copy of SC21-7504-5 System/3 RPG II Reference Manual, April
1975, page 195 (Figure 128) starts with the same example that's in the
7.1 manual (Figure 345). Where that old book differs, it has arrows and
braces showing which pieces of the fields are affected. I'm no graphic
designer, and I learnt RPG from that manual, so I'm biased, but I like
that presentation a bit better than the current one. Old people, am I
right? :-)

the instruction is not overloaded to that degree. To be clear, I think
the evils are more about code maintenance than new code; i.e. someone
originally choosing to effect explicitly what the MOVE* instruction
provides is likely to get exactly what they want.

I definitely agree with this, although it's my personal experience that
programmers implementing MOVE tend to use an iterative cut and try
approach for any but the simplest 'substring' type of processes.
--buck