# MOVE BY NAME - spaces converted to zeroes ?? **URL:** \ **Category:** Forum\ **Tags:** Adabas-Natural, Natural, Natural-on-Mainframes, Adabas-Natural-Cloud\ **Created:** [August 7, 2006, 8:17pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296 "2006-08-07T20:17:50Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![thespin](https://avatars.discourse-cdn.com/v4/letter/t/8c91f0/32.png) [@thespin](https://techcommunity.softwareag.com/u/thespin)\ **Post date:** [August 7, 2006, 8:17pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/1 "2006-08-07T20:17:50Z")
If there are two fields defined: ```auto DEFINE DATA LOCAL 01 FIELD-1 02 LEVEL-2 (A10) 02 REDEFINE LEVEL-2 03 LEVEL31 (N4) 03 LEVEL32 (N4) 03 LEVEL33 (N2) 01 FIELD-2 02 LEVEL-2 (A10) 02 REDEFINE LEVEL-2 03 LEVEL31 (N4) 03 LEVEL32 (N4) 03 LEVEL33 (N2) END-DEFINE * RESET FIELD-1 FIELD-2 WRITE 'FIELD-1: ' FIELD-1 ' FIELD-2: ' FIELD-2 * MOVE ' ' TO FIELD-1.LEVEL-2 * MOVE BY POSITION FIELD-1 TO FIELD-2 WRITE 'FIELD-1: ' FIELD-1 ' FIELD-2: ' FIELD-2 * MOVE BY NAME FIELD-1 TO FIELD-2 WRITE 'FIELD-1: ' FIELD-1 ' FIELD-2: ' FIELD-2 END ``` If one does a MOVE BY POSITION, the result will be SPACES in FIELD-2.LEVEL-2. If one does a MOVE BY NAME, the result will be ZEROES in FIELD-2.LEVEL-2. Wat up wit dat, dog ? Who gave the compiler permission for this conversion in MOVE BY NAME ?? (Certainly, no programmer would! Of course for maintenance reasons no programmer would ever use MOVE BY NAME/POSITION but unfortunately there is some law that says “build an instruction and they will code”!!) ---
**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\ **Post date:** [August 7, 2006, 9:50pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/2 "2006-08-07T21:50:55Z")
Documentation says: -----------------snip------------------------ This option is used to move individual fields contained in a data structure to another data structure, independent of their position in the structure. A field is moved only if its name appears in both structures (this includes REDEFINEd fields as well as fields resulting from a redefinition). The individual fields may be of any format. The operands can also be views. Note: The sequence of the individual moves is determined by the sequence of the fields in operand1. -----------------snap------------------------ Thats why your Redefines at Level 03 will give the Format. Greetings Sascha ---
**Author:** ![thespin](https://avatars.discourse-cdn.com/v4/letter/t/8c91f0/32.png) [@thespin](https://techcommunity.softwareag.com/u/thespin)\ **Post date:** [August 7, 2006, 10:09pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/3 "2006-08-07T22:09:22Z")
Thanks, Sascha, for your reply. But it did not address my question. I know the purpose of the MOVE BY NAME/POSITION. My question is: Why does MOVE BY POSITION work the way it should as far as the result fields containing the SAME VALUE as the sending field, while MOVE BY NAME convert SPACES TO ZEROES if the receiving field is defined numeric ? I would NOT EXPECT the compiler to have that type of conversion logic built in and I doubt ANY OTHER COMPILER would make such a conversion (though there may be a couple that would abend the program - most would abend ONLY if the field was used for arithmetic). Programmers depend on MOVEs maintaining the VALUE of the sending field. The thing is that this compiler change is fairly recent since old modules which are now being changed and recompiled are not working as they originally did. Is there a compiler option to make the compilation work as original - and correctly ? ---
**Author:** ![Wilfried\_B](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/wilfried_b/32/83_2.png) [@Wilfried\_B](https://techcommunity.softwareag.com/u/Wilfried_B)\ **Post date:** [August 7, 2006, 10:29pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/4 "2006-08-07T22:29:50Z")
Adam, don’t be so impatient. Read the docs: > [@](#): > > MOVE BY POSITION > The values are moved field by field from one group to the other in the order in which the fields are defined (this does not include fields resulting from a redefinition). Thus, with move by name you do a numeric move (that converts h’40’ to h’F0’) with the level 3 fields and move by position does an alphanumeric move with the level 2 fields. That’s all! And now you really know the purpose of MOVE BY NAME/POSITION! ---
**Author:** ![thespin](https://avatars.discourse-cdn.com/v4/letter/t/8c91f0/32.png) [@thespin](https://techcommunity.softwareag.com/u/thespin)\ **Post date:** [August 7, 2006, 11:33pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/5 "2006-08-07T23:33:52Z")
Thanks, Wilfried. That clears up the MOVE BY POSITION working as expected - that is: the receiving field having the same value as the sending field. However, that does not explain why a ‘numeric’ MOVE would convert SPACES to ZEROES. IN FACT, IF THE SENDING FIELD IN THE EXAMPLE AT TOP CONTAINS ‘ABCDEFGHIJ’, THE RECEIVING FIELD AFTER THE ‘MOVE BY NAME’ IN THE SAME EXAMPLE WOULD CONTAIN ‘123456789J’!!! IN THE NAME OF ALL THAT IS DIGITAL, why in DIGITAL’s NAME would a compiler make this conversion ??? WHY, OH WHY, OH WHY WHY WHY ??? :roll: It appears that SOMEONE has a SPECIFIC APPLICATION in mind while COMPILERS are SUPPOSED TO BE designed for very generic NON-SPECIFIC USES!! EDIT: BTW ‘\*BCDEFGHIJ’ will abend the application with a SOC7 … see what I mean … ---
**Author:** ![Ralph\_Zbrog](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/ralph_zbrog/32/78_2.png) [@Ralph\_Zbrog](https://techcommunity.softwareag.com/u/Ralph_Zbrog)\ **Post date:** [August 8, 2006, 12:44am UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/6 "2006-08-08T00:44:43Z")
The, 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). ---
**Author:** ![thespin](https://avatars.discourse-cdn.com/v4/letter/t/8c91f0/32.png) [@thespin](https://techcommunity.softwareag.com/u/thespin)\ **Post date:** [August 8, 2006, 2:15am UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/7 "2006-08-08T02:15:08Z")
Thanks, Ralph, for your reply. We are running Natural version 4.3 on an IBM mainframe. What I would expect on moving a non-numeric value on a MOVE to a numeric field is either an ABEND or the compiler treating the receiving field as another alphanumeric field (the latter is what a COBOL compiler would do - packed fields are handled differently). I would have been happy with an abend which would have forced the programmer to do a better job of coding. You appear to be mistaken when you say that “in your example, Natural does move the spaces; there is no conversion.” In said example the field displayed is NOT the numeric field but the group field - and the results are the same if I display the alphanumeric field, LEVEL-2, which means that there is in fact a ‘0’ in positions where I place a ‘space’ in the sending field. IN FACT, if I place ’ BCDEFGHIJ’ in the sending field, the hex display of the receiving field is ‘F0F2F3F4F5F6F7F8F9F1D2’. IT’S ILLOGICAL FOR A COMPILER, USED FOR GENERIC APPLICATIONS, TO DO THIS TYPE OF CONVERSION. ---
**Author:** ![Matthias1](https://avatars.discourse-cdn.com/v4/letter/m/9fc348/32.png) [@Matthias1](https://techcommunity.softwareag.com/u/Matthias1)\ **Post date:** [August 8, 2006, 3:58pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/8 "2006-08-08T15:58:24Z")
The following example shows, that the conversion is not done by MOVE. It is done by REDEFINE. ```auto DEFINE DATA LOCAL 01 #A4 (A4) 01 REDEFINE #A4 02 #N4 (N4) END-DEFINE * WRITE '=' #A4 '=' #N4 END ``` The REDEFINE is very tolerant. I think the automatical conversion is done to avoid the runtime-error “invalid character in numeric field”. Otherwise it would be impossible to redefine alphanumerics with numerics or vice versa. ---
**Author:** ![thespin](https://avatars.discourse-cdn.com/v4/letter/t/8c91f0/32.png) [@thespin](https://techcommunity.softwareag.com/u/thespin)\ **Post date:** [August 8, 2006, 7:16pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/9 "2006-08-08T19:16:40Z")
Thanks, Matthias, for your reply. However, all your example shows is that Natural will ALSO convert SPACES TO ZEROES when you try to WRITE or DISPLAY a numeric field which has spaces. In MY example at the top, the WRITE of the ALPHANUMERIC field FIELD-2.LEVEL-2 after the MOVE BY NAME shows not the ALPHA characters but the compiler converted characters - the conversion actually took place when the MOVE was done. ---
**Author:** ![Matthias1](https://avatars.discourse-cdn.com/v4/letter/m/9fc348/32.png) [@Matthias1](https://techcommunity.softwareag.com/u/Matthias1)\ **Post date:** [August 8, 2006, 7:49pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/10 "2006-08-08T19:49:08Z")
> [@thespin](#): > > In MY example at the top, the WRITE of the ALPHANUMERIC field FIELD-2.LEVEL-2 after the MOVE BY NAME shows not the ALPHA characters but the compiler converted characters - the conversion actually took place when the MOVE was done. That’s not completely correct. The reason for this is, that a MOVE BY NAME results in: ```auto MOVE FIELD-1.LEVEL-2 TO FIELD-2.LEVEL-2 MOVE FIELD-1.LEVEL31 TO FIELD-2.LEVEL31 MOVE FIELD-1.LEVEL32 TO FIELD-2.LEVEL32 MOVE FIELD-1.LEVEL33 TO FIELD-2.LEVEL33 ``` On the other hand, a MOVE BY POSITION is ```auto MOVE FIELD-1.LEVEL-2 TO FIELD-2.LEVEL-2 ``` As Wilfried B ---
**Author:** ![thespin](https://avatars.discourse-cdn.com/v4/letter/t/8c91f0/32.png) [@thespin](https://techcommunity.softwareag.com/u/thespin)\ **Post date:** [August 8, 2006, 8:38pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/11 "2006-08-08T20:38:31Z")
Thanks, Matthias, for your reply. Consider yourself corrected! :o It’s clear that you haven’t read all the posts in this thread. Please do so! ---
**Author:** ![Matthias1](https://avatars.discourse-cdn.com/v4/letter/m/9fc348/32.png) [@Matthias1](https://techcommunity.softwareag.com/u/Matthias1)\ **Post date:** [August 8, 2006, 9:41pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/12 "2006-08-08T21:41:51Z")
> [@thespin](#): > > Consider yourself corrected! :o > > It’s clear that you haven’t read all the posts in this thread. Please do so! I did, but maybe I’m a blockhead … 😉 So please write a little program, which proofs that the MOVE-statement itself does the conversion (and not the REDEFINition). ---
**Author:** ![thespin](https://avatars.discourse-cdn.com/v4/letter/t/8c91f0/32.png) [@thespin](https://techcommunity.softwareag.com/u/thespin)\ **Post date:** [August 8, 2006, 10:14pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/13 "2006-08-08T22:14:15Z")
Thanks, Matthias, for your reply. I believe this should convince you. ```auto DEFINE DATA LOCAL 01 #A4 (A4) 01 REDEFINE #A4 02 #A4N (N4) * 01 #N4 (N4) * 01 #N4-2 (N4) 01 REDEFINE #N4-2 /* reversed 02 #N4A (A4) /* redef order END-DEFINE * MOVE ' ABC' TO #A4 MOVE #A4N TO #N4 WRITE '=' #N4 (EM=HHHH) /* HEX VALUE * MOVE #A4N TO #N4-2 WRITE '=' #N4A END ``` ---
**Author:** ![Matthias1](https://avatars.discourse-cdn.com/v4/letter/m/9fc348/32.png) [@Matthias1](https://techcommunity.softwareag.com/u/Matthias1)\ **Post date:** [August 9, 2006, 12:48pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/14 "2006-08-09T12:48:45Z")
The output-screen of your Program on NAT6.1.1@Solaris is ```auto #N4: 30313233 #N4A: 0123 ``` In other words ’ ABC’ is converted to 0123. I can do this without a move: ```auto DEFINE DATA LOCAL 01 #A4 (A4) 01 REDEFINE #A4 02 #A4N (N4) END-DEFINE * MOVE ' ABC' TO #A4 DISPLAY #A4N (EM=-ZZZ9) END ``` As you wrote you’ll get an error if you move a ‘_’ into #a4. In my case it is a NAT6223. The reason is, that a '_’ is 0x2A (if you use ASCII) or 0x5C (in EBCDIC). Every value bigger than ‘9’ in the second half byte leads to a this runtime error. If I try out ‘J’ (which is 0x4A on my computer), I get the same error. The first half byte seems to be ignored. ---
**Author:** ![Wilfried\_B](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/wilfried_b/32/83_2.png) [@Wilfried\_B](https://techcommunity.softwareag.com/u/Wilfried_B)\ **Post date:** [August 9, 2006, 2:23pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/15 "2006-08-09T14:23:37Z")
Matthias, your example only shows, that Natural does a conversion with DISPLAY, not with move. It does not show the true values of the variable. What I mean is: the ‘-’ in the edit mask is derived from the left halfbyte of the rightmost byte in the variable (if it is any of B, D it is negative, any other is treated positive, as a memory hook: CAFE is positive I learned when having first COBOL contact) ```auto HEX NUM ---- --- 0000 0 0010 0 0020 0 0030 0 0040 0 0050 0 0060 0 0070 0 0080 0 0090 0 00A0 0 00B0 - 0 00C0 0 00D0 - 0 00E0 0 00F0 0 ``` The value for the 'Z’s and '9’s is derived from the whole byte in the variable, from left to right. If the value is ‘F0’ it is suppressed (in case of ‘Z’), else it is displayed as is (N4.1.4 z/OS) [code] HEX NUM * * * 0F00 ?0 1E11 ?1 2D22 ?2 3C33 ?3 4B44 .4 5A55 ---
**Author:** ![Matthias1](https://avatars.discourse-cdn.com/v4/letter/m/9fc348/32.png) [@Matthias1](https://techcommunity.softwareag.com/u/Matthias1)\ **Post date:** [August 9, 2006, 4:13pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/16 "2006-08-09T16:13:27Z")
[quote="Wilfried B ---
**Author:** ![Steve\_Robinson](https://sea1.discourse-cdn.com/techcommunity/user_avatar/techcommunity.softwareag.com/steve_robinson/32/107_2.png) [@Steve\_Robinson](https://techcommunity.softwareag.com/u/Steve_Robinson)\ **Post date:** [August 9, 2006, 5:18pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/17 "2006-08-09T17:18:58Z")
This thread is getting a little silly. When you were in grade school Thespin, you learned English spelling and pronunciation. Did you object to what you perceived as inconsistencies? Or, to avoid appearing foolish and uneducated , did you put up with such fun contradictions as the identical pronunciation for threw and through? My guess is the latter. You are now learning Natural. Fine. Most of the rest of the people in this thread have been using Natural for quite a long time. They understand how MOVE BY NAME and MOVE BY POSITION work. From your original posting, it is clear you did not. Please stop objecting to the syntax and execution of Natural as “errors” because you are new to the language. Learn the language. It is very powerful, and a lot of fun to code. Does it have idiosyncracies? Absolutely. Learn them so you do no appear silly when you post the equivalent of an objection to “ghoti” being pronounced “fish”. steve ---
**Author:** ![Matthias1](https://avatars.discourse-cdn.com/v4/letter/m/9fc348/32.png) [@Matthias1](https://techcommunity.softwareag.com/u/Matthias1)\ **Post date:** [August 9, 2006, 6:02pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/18 "2006-08-09T18:02:46Z")
> [@Steve Robinson](#): > > This thread is getting a little silly. Maybe, but it’s still interesting. Because I found another way of “conversion”: ```auto DEFINE DATA LOCAL 01 #A2 (A2) 01 REDEFINE #A2 02 #N2 (N2) END-DEFINE * MOVE H'69D6' TO #A2 DISPLAY 'HEX' #A2 (EM=HH) #N2 (EM=-Z9) ADD 0 TO #N2 DISPLAY #A2 (EM=HH) #N2 (EM=-Z9) * END ``` The output (on Solaris) is: ```auto HEX #N2 ---- --- 69D6 -96 3976 -96 ``` Please note that an ADD 0 “converts” the value. But to come to an end: For me it’s completely clear now: 1. “Converting” is not a matter of MOVE BY NAME or MOVE BY POSITION, it is a matter of the redefinition-logic and the internal presenation of numeric values. 2. Space is converted to zero because: 2.1) space is 0x40 (EBCDIC) or 0x20 (ASCII) 2.2) only the right half bytes are taken to representate a numeric value (excepting 4 bit for the sign) ---
**Author:** ![thespin](https://avatars.discourse-cdn.com/v4/letter/t/8c91f0/32.png) [@thespin](https://techcommunity.softwareag.com/u/thespin)\ **Post date:** [August 9, 2006, 7:32pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/19 "2006-08-09T19:32:23Z")
> [@Steve Robinson](#): > > This thread is getting a little silly. Steve, there is a saying that “consistency is the hobgoblin of little minds”. Despite that, I would have had only a teeny problem if Natural had ALWAYS done the MOVE BY NAME and the alpha-to-numeric conversion that way. HOWEVER, the reason I am upset is that I am changing some older Natural programs and code that used to work correctly is now working incorrectly because NATURAL’s way of handling either MOVE BY NAME or alpha-to-numeric has changed from the time that the original code was compiled! I don’t find this silly at all … ---
**Author:** ![Matthias1](https://avatars.discourse-cdn.com/v4/letter/m/9fc348/32.png) [@Matthias1](https://techcommunity.softwareag.com/u/Matthias1)\ **Post date:** [August 9, 2006, 8:13pm UTC](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296/20 "2006-08-09T20:13:45Z")
By the way: I found the following description about Unicode and REDEFINE. 😉 > [@](#): > > Unicode and the REDEFINE Statement > There has been great discussion amongst the Natural development team if the REDEFINE statement should be allowed for Unicode fields. A developer can make a big mess by redefining Unicode data incorrectly, thus destroying the Unicode characters. > > The result of the Natural development team’s discussion is the conclusion that all the developers programming in Natural are highly intelligent and responsible persons and they will know exactly what they are doing with their data. So the REDEFINE statement is available for Unicode fields. Any Unicode field can be redefined as a hexadecimal field or as a single byte a-type field. This allows the developer to process the Unicode data in all possible methods they can think of. The first approach simply would be that the developer can see how his/her data is encoded internally. See [http://developer.softwareag.com/ets/knowhow/Natural\_tech/FINAL\_Unicode\_2\_Article\_030106.pdf](http://developer.softwareag.com/ets/knowhow/Natural_tech/FINAL_Unicode_2_Article_030106.pdf) [Next page](https://techcommunity.softwareag.com/t/move-by-name-spaces-converted-to-zeroes/61296.md?page=2)