Presuming that you are running Natural on an IBM mainframe …
You should review how external decimal values (N in Natural’s parlance) are stored internally. The right nibble of each byte contains a decimal digit; the left nibble contains a zone value, typically F in all bytes but the right-most, where the digit contains a sign. Other than that right-most byte, the zone digit is pretty much ignored.
You ask why Natural converts spaces to numbers. I would ask, why would you expect a move from one numeric to field to another numeric field to result in a non-numeric value?
In fact, in your example, Natural does move the spaces; there is no conversion. Display your target fields with a hexadecimal mask to see H’40’ in each byte. When the target fields are displayed, Natural presumes that the values are valid external decimal. These valid values (the digits 0 thru 9, or H’F0’ thru H’F9’) match their character-representation counterparts, so Natural writes them to the screen without conversion. With your ‘space’ values, you see spaces on the screen, except for the last byte, whose sign-nibble (H’4’) is considered to be positive, so the last digit is displayed as zero.
With alphabetic values, such as ‘A’ (H’C1’), the situation is the same. The character representation is identical to a valid external decimal value.
I expect you received the S0C7 when you attempted to use one of the target fields containing invalid external decimal values (eg H’40’). Natural also will abend if you try to move an alpha value whose right nibble contains a digit other than 0 thru 9. (By the way, if you tried your example with different field lengths in the source and target, Natural would send an abend code.)
If your source is numeric and your target is packed, then Natural must perform a conversion. In this case, Natural looks only at the right-nibbles, so alpha bytes are converted as long as they contain 0 thru 9 in the right-half (eg spaces in the source are converted to zeros in the target).