Re: MOVE/MOVEL and %Scan

Paul wrote:
>Have things changed, or do I get old ?

We're all getting old, Paul.

>I guess I once tested MOVEL on a VARYING field, and got the result that it
>also overwrote the first two bytes containing the length of the VARYING
>field ?  Has this ever been the case, or is my memory really failing ?
>Anyway, even like it is currently, I find it a dangerous construction as
one
>doesn't really know if the length of the data to MOVE will be the same as
>the current length of the VARYING field (unless one anticipates such
>behavior... but I consider that as "to be avoided implicit behavior")

No, I don't think MOVEL ever had that buggy behavior.  Unless
you're thinking about the days before VARYING was added to the
RPG language.

We had a tough time figuring out what to do with character
varying on the older opcodes, like MOVE.  Since MOVE and MOVEL
might not change the entire result field (depending on lengths
of operands), varying really didn't fit in well with the
semantics of those opcodes.  As a result, our early designs
were rather complex monstrosities, especially in the cases
where the value is right-adjusted in the result.

I suppose that's yet another reason why we don't like to
encourage the use of those older opcodes.  ;-)

>I also encountered another issue that seems to be running fine now ?  In
the
>past when I was doing a %Scan and the search argument was bigger than the
>actual VARYING string, the program crashed.  If I now try this...
everything
>goes fine (and it returns 0... as it should be in my opinion).  Again, am
I
>getting old ?

This was in fact changed in V5R1.  For this situation, %SCAN
was changed to return 0 instead of failing.  Personally, I
think some of the string BIFs are still a bit too restrictive,
but I don't think we'll change them any time soon.

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com