RE: Moves, bifs, old and new (was Strange behavior w/%editc())

oops, i forgot to add.... I didn't look this up, this is not the 'book' on
how it works, this is just how I'd expect move to work with variable
strings...

please don't hit me!

rick

-my original message--
Jim,

---original message with inline comments---
Jim said:

>Well, MOVE(L) does a lot of things.

Yes, they do!

>But what would happen when you MOVE a 5 character field into a varying
>string?

5 charactors from factor two replaces the last 5 char of varying string,
starting with the last non-null position and going left.  unless (P) op
extender is used.  then it does the same, padding with blanks on the left.

>Does it make a difference if the Varying string already contains 10
>characters?

no

>Should it replace the first 5 characters and leave the last 5
>alone?

no

>Or should it make the string 5 characters long?  And if you wanted
>it to just replace the first 5 characters, what would you want it to do if
>the varying string contained only 3 characters?  Should it make the string
5
>character?  Or should it just replace the 3 characters?

It should always leave the size alone.  move is to replace existing
charactors.  if the result is 3, the last 3 char of factor 2 should replace
the 3 char in the varying string.

>I believe the reason Move wasn't ported to freeformat is because of these
>types of questions.  MOVE doesn't work well, IMO, on varying strings
>because, so far, it hasn't had to.

or, if that's too confusing, you could make it easy and just give a 30 on
the compiler that says "varying strings not allowed with the move opcode"

problem solved!

>I really don't know what would happen if I tried to do a MOVE into a
varying
>length string, but I'm sure it wouldnt' be the way I wanted it to.

my suggestions are completely consistant with the behaviour of MOVE since
the beginning of time.  it may not be what you wanted, but it'd be
consistant.

ttfn,

rick