RE: Overlapping subfields with a MOVE

 >> We did take care of the issue, but we want to know why EVAL gets away
with it when MOVE does not.

My best guess (which Barbara could confirm/deny) is that the fundamental
differences between Eval and move account for the compiler being more picky.

Since move does most anything except make the dinner and take out the
garbage (bad analogy because it implies that I think move is useful <grin>)
the compiler has to do a lot of checking on the addresses.

After all move doesn't fill the target field, it overlays (with conversion
if needed) a part of it.  Eval on the other hand always changes the entire
target field and always begins at the first position of the source and
target.  Since no calculations are involved with Eval the compiler probably
doesn't bother to check for overlaps since it has no impact.

Move is also a "legacy" op-code.  Moving overlapping fields back in the days
of the S/3, 34 and 36 would (if memory serves) have a different effect to
that on 400s and iSeries.  It may be because of that that move is defined as
not permitting overlaps and hence the compiler error.

Jon Paris
Partner400

www.Partner400.com
www.RPGWorld.com