I'm not Barbara but ...
On 10/04/2010, at 9:58 AM, Dennis Lovelady wrote:
But a question for you, Barbara: Won't the above code cause all
elements of
myNumbers to be filled with the value that's in myNumbers(1)?
Why so Grasshopper? The move does not reference array elements but
rather the containing the DS and thus becomes a simple byte copy from
[1 to (end - %size(mynumbers))] into [(%size(mynumbers)+1) to end].
RPG sorts out the length differences (i.e., the right operand is
longer than the length of the left operand and is truncated).
It will leave the first array element containing the original value
but that's easily dealt with. The move (copy really) uses overlapping
operands so a temporary appears to be required behind the scenes.
For example:
Before:
Raw hex dump:
EVAL array1ds:x
00000 00000010 0F000000 200F0000 00300F00
00010 0000400F 00000050 0F000000 600F0000
00020 00700F00 0000800F 00000090 0F000001
00030 000F.... ........ ........ ........
Array element data:
MYNUMBERS OF ARRAY1DS(1) = 0000001.00
MYNUMBERS OF ARRAY1DS(2) = 0000002.00
MYNUMBERS OF ARRAY1DS(3) = 0000003.00
MYNUMBERS OF ARRAY1DS(4) = 0000004.00
MYNUMBERS OF ARRAY1DS(5) = 0000005.00
MYNUMBERS OF ARRAY1DS(6) = 0000006.00
MYNUMBERS OF ARRAY1DS(7) = 0000007.00
MYNUMBERS OF ARRAY1DS(8) = 0000008.00
MYNUMBERS OF ARRAY1DS(9) = 0000009.00
MYNUMBERS OF ARRAY1DS(10) = 0000010.00
After:
Raw hex dump:
EVAL array1ds:x
00000 00000010 0F000000 100F0000 00200F00
00010 0000300F 00000040 0F000000 500F0000
00020 00600F00 0000700F 00000080 0F000000
00030 900F.... ........ ........ ........
Array element data:
MYNUMBERS OF ARRAY1DS(1) = 0000001.00
MYNUMBERS OF ARRAY1DS(2) = 0000001.00
MYNUMBERS OF ARRAY1DS(3) = 0000002.00
MYNUMBERS OF ARRAY1DS(4) = 0000003.00
MYNUMBERS OF ARRAY1DS(5) = 0000004.00
MYNUMBERS OF ARRAY1DS(6) = 0000005.00
MYNUMBERS OF ARRAY1DS(7) = 0000006.00
MYNUMBERS OF ARRAY1DS(8) = 0000007.00
MYNUMBERS OF ARRAY1DS(9) = 0000008.00
MYNUMBERS OF ARRAY1DS(10) = 0000009.00
I probably wouldn't use this method because I think it's a bit
obscure. I'd rather use array operations on arrays--even if that means
dropping out of free-form. On 530 and above you could use %SUBARR but
you'd need two arrays because, although it is not constrained to
different arrays like MOVEA, using overlapping or coincident operands
is suspect. From the Reference manual.
CAUTION:
It is valid to use %SUBARR to assign part of an array to another part
of the same array. However, if the source part of the array overlaps
the target part of the array, unpredictable results can occur.
Perhaps Barbara can explain why it is so--seems to me coincident
operands could be trapped and handled.
I remember this technique from my 360 Assembler days, when we would
clear a
printer field by doing:
MVC OUTPUT,OUTPUT-1
Don't we need a Right-to-Left move? Or will the compiler figure
that out?
Why do you think the move need not be left to right?
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
