RE: Redefining a DS

I thought memcpy is a C function - there is no implicit connection to
anything on the i. How it's implemented depends on whatever version of
C/C++ you use. If it has been a direct mapping to some MI function -
well, we can't depend on that, cuz implementation changes as better
ways
are found. And I'd be very surprised to be able to depend on this

Ummm... it is my understanding (perhaps flawed? Barbara? Simon? Bueller?)
that "procedures" like _memcpy are actually interfaces to the MI
instruction.

I would suggest that the MI memcpy operation code (and yes, there is one -
see
http://publib.boulder.ibm.com/iseries/v5r1/ic2924/tstudio/tech_ref/mi/MEMCPY
.htm) similarity to the C function is an engineered "coincidence."

I would also suggest that since IBM have opted to provide such interfaces
into the lower levels of the system, they won't take those interfaces away.
Finally, I see occasional suggestion from Barbara and others to use the MI
built-ins (see http://archive.midrange.com/rpg400-l//200301/msg00433.html as
an example), so I say that with some confidence.

As Simon tried to point out, the MEMCPY.htm link I provided above warns
about overlapping fields and undefined results, so I won't be trying the MI
after all.

But I still would like to know why Simon said that about it being more
likely the compiler than the MI. Is _memcpy() an interface to MI, and does
the ILE RPG compiler influence its actions?

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"I'm one of those mayors whose management style is to allow free and
unlimited debate up to a point."
-- Washington, D.C. mayor Marion Barry