MOVE BY NAME - spaces converted to zeroes ??

, , ,
1

If there are two fields defined:

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”!!)

2

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

3

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 ?

4

Adam,

don’t be so impatient. Read the docs:

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!

5

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 …

6

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).

7

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.

8

The following example shows, that the conversion is not done by MOVE. It is done by REDEFINE.

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.

9

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.

10

That’s not completely correct. The reason for this is, that a MOVE BY NAME results in:

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

MOVE FIELD-1.LEVEL-2 TO FIELD-2.LEVEL-2

As Wilfried B

11

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!

12

I did, but maybe I’m a blockhead … :wink:
So please write a little program, which proofs that the MOVE-statement itself does the conversion (and not the REDEFINition).

13

Thanks, Matthias, for your reply.

I believe this should convince you.


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
14

The output-screen of your Program on NAT6.1.1@Solaris is

#N4: 30313233
#N4A: 0123

In other words ’ ABC’ is converted to 0123. I can do this without a move:

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.

15

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)

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

16

[quote="Wilfried B

17

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

18

Maybe, but it’s still interesting. Because I found another way of “conversion”:

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:

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)
19

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 …

20

By the way: I found the following description about Unicode and REDEFINE. :wink:

See
http://developer.softwareag.com/ets/knowhow/Natural_tech/FINAL_Unicode_2_Article_030106.pdf