MOVE BY NAME - spaces converted to zeroes ??

[system]

@Matthias

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

Unicode and the REDEFINE Statement
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.

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

rotflbtc :lol:

[Steve_Robinson]

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!

Perhaps you could tell us what version this code was compiled under; and show us exactly what the code used to do (or were you simply told the code used to work) and what it does now.

steve

[Ralph_Zbrog]

Much of this thread has seemed like a first-year programming class, but in The’s defense, Natural has changed, and I couldn’t find anything in the release notes to document it. In 4.1 Natural changes the zone nibble to a valid value.

Here’s the code (substantially like the original sample):

DEFINE DATA LOCAL                     
1 #1                                  
  2 #2 (A10)       INIT <'ABCDEFGHIJ'>
                   2 REDEFINE #2      
    3 #N1 (N1)                        
    3 #N2 (N2)                        
    3 #N7 (N7)                        
1 #A                                  
  2 #B (A10)       2 REDEFINE #B      
    3 #N1 (N1)                        
    3 #N2 (N2)                        
    3 #N7 (N7)                        
1 #NAT-VERS (A8)   INIT <'3.1.6'>     /* <*NATVERS>
END-DEFINE                            
MOVE BY NAME #1 TO #A                 
DISPLAY #NAT-VERS                     
        #1.#N7                        
        #1.#N7 (EM=H(7))              
        #A.#N7                        
        #A.#N7 (EM=H(7))              
END

Output from 3.1.6:

#NAT-VERS   #N7         #N7         #N7         #N7      
--------- -------- -------------- -------- --------------
                                                         
3.1.6     -DEFGHI1 C4C5C6C7C8C9D1 -DEFGHI1 C4C5C6C7C8C9D1

Output from 4.1.3:

#NAT-VERS   #N7         #N7         #N7         #N7      
--------- -------- -------------- -------- --------------
                                                         
04.01.03  -DEFGHI1 C4C5C6C7C8C9D1 -4567891 F4F5F6F7F8F9D1

[thespin]

@Steve Robinson

Perhaps you could tell us what version this code was compiled under; and show us exactly what the code used to do (or were you simply told the code used to work) and what it does now.

Example:
There is a file handler module that moves the to-be database fields from the Parameter area to the View area using MOVE BY NAME. Fourteen of these fields are Dates defined as alphanumeric and then redefined as three numeric fields (yyyy, mm, dd).

The ‘design’ of the system is such that editing of the fields to be written is handled in these file handler modules.

The module’s date edit logic is:

IF VIEW.DATE GT ' '
    move VIEW.DATE to 'datechek' area
    CALLNAT 'datechek'
    If error
        msg :=
        escape
     end-if
END-IF 

This logic works fine if I use the compiled version in production. But if I move that version to test and recompile WITHOUT ANY CHANGES (I just did it), the date edit for a blank date fails. I must either do individual moves of the alpha definitions of the dates right after the MOVE BY NAME -or- change the logic to:
IF VIEW.DATE GT ‘00000000’

I can’t access production except thru the VERSION CONTROL system. But I did a COMPARE and this falls out at top:
NAT2 }N 3.1 0006
This falls out for the newly compiled version:
NAT2 }N 4.1 0003

[Wilfried_B]

Thanks to the developers of Natural they eliminated a bug! If there are programs that rely on this bug: they have to be changed.

That’s all!

BTW. If a programmer has expected that a value is not changed while moving numeric values, he did not understand what’s happening. If the target fields are not of the same format, a conversion has happend always! Only in this special case where the formats are identical, the compiler freaks had implemented a “performance” option (without thinking about the consequences).
Perhaps you should insist on a field consistency checking rule for all “N” fields. If it does not contain a valid numeric value (whole bytes!), you should get a NAT0945. But then: “happy performance lost”.

How, ich habe gesprochen!

[Wilfried_B]

…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…

Haha!
Why is there still such a thing like a data area editor (especially with Natural for Windows)? This editor exactly shows the opposite!

I know my data and don’t need a restrictive editor to define them. What I need is a normal text editor with special functions to support me, e.g. including data definitions from a view.

Here is a real life scenario:
You have to add a field to a view. In a normal text editor you would insert a line and type the name of the field. In the data area editor you have to do the following:

1. list the view in split screen mode
2. navigate to the desired field in the view
3. type the number in front of the field in the split screen into the line where you want to insert the field.

Another:
A database field has changed the format.
In text editor: nothing to do!
In Data area editor: Delete the field and insert it again (see above).

Bye!

[Matthias1 (Matthias)]

@Ralph Zbrog

but in The’s defense, Natural has changed, and I couldn’t find anything in the release notes to document it.

:shock: :shock: :shock:
Now the question is: Was the logic of MOVE BY NAME or the logic of REDEFINE changed?

@Ralph Zborg: Could you please substitute the MOVE MY NAME in your program with the following code

move #1.#n1 to #A.#n1
move #1.#n2 to #A.#n2
move #1.#n7 to #A.#n7

I think: If the outputs remain as they are, the REDEFINE-logic changed.

[thespin]

Ralph, thanks so much for the information. If SAG made the change without informing it’s customer base IN A VERY PROMINENT WAY and also telling them they must update all their Natural programs if necessary as they recompile them, then that was a MAJOR (MAJOR!) OVERSIGHT!!

What I believe that Matthias is asking you to do is to test in version 3.1.6 and see whether MOVE BY NAME once worked like MOVE BY POSITION in that if sending and receiving fields (with the same name in the case of MOVE BY NAME) are redefined, then the MOVE occurs only at the higher level - not at the REDEFINES level. OR in version 3.1.6 did the conversion of alphas to numeric values take place or not when moving to a numeric field.

[quote="Wilfried B

[Ralph_Zbrog]

As expected, changing the MOVE BY NAME to individual MOVEs produced identical results. After all, what does the compiler do with a MOVE BY NAME, but translate it into individual MOVE operations?

MOVE BY POSITION also has changed from 3.1 to 4.1. In 4.1, zone digits are set/converted in the target numeric field, as with MOVE and MOVE BY NAME.

I don’t understand what Matthias is asking when referring to “REDEFINE logic.” REDEFINE is a compile-time statement which maps a variable name to memory locations, and that mapping has not changed. Any logic, internal (in the nucleus) or external (in our programs), would apply at execution time to those variables based upon their format and length definitions.

It has always been good practice to avoid mapping alpha fields to numeric, thereby avoiding the issues discussed in this thread. I prefer Natural’s new method of processing zone-digits in version 4.1, but I would have expected SAG to mention the change (e.g. as was done with the change to system function processing in 6.2).

If this change was documented, and I simply didn’t see it, then I apologize to SAG for my accusation.

[thespin]

Thanks, Ralph. Now we know that the zone nibble compiler logic was changed from 3.1.6 (as you stated in your Aug 09, 2006 10:45pm post).

But we cannot really tell whether the MOVE BY NAME was changed or not. The only way to test this is to move a value like ‘*’ into the higher level alpha variable and then do the MOVE BY NAME. If the program abends in 3.1.6 then MOVE BY NAME moves the elementary REDEFINE numeric items not (just) the originally defined area as MOVE BY POSITION does.

Here is a test program for that:

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 '=' LEVEL-1 '=' LEVEL-2
*
MOVE '**********' TO FIELD-1.LEVEL-2
MOVE BY NAME FIELD-1 TO FIELD-2
*
WRITE '=' LEVEL-1 '=' LEVEL-2
*
END

[Ralph_Zbrog]

In 3.1, MOVE, MOVE BY NAME, and MOVE BY POSITION move individual fields on a byte-by-byte basis. There is no test for numeric content.

In 4.1, MOVE, MOVE BY NAME, and MOVE BY POSITION test the source field’s content when the target is numeric. If the source contains an invalid zone-digit (left-nibble), it is changed to F. If the source contains an invalid decimal-digit (right-nibble), a 954/S0C7 is thrown.

How Natural determines which fields to move has NOT changed from 3.1 to 4.1. As documented, MOVE BY NAME matches field names, including redefinitions. MOVE BY POSITION matches on a field-by-field basis, excluding redefinitions.

Using TheSpin’s sample

DEFINE DATA 
LOCAL 
01 FIELD-1 
   02 LEVEL-1         (A10) 
   02 REDEFINE LEVEL-1 
      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 '=' LEVEL-1 '=' LEVEL-2 
* 
MOVE '**********' TO FIELD-1.LEVEL-2 
MOVE BY NAME FIELD-1 TO FIELD-2 
* 
WRITE '=' LEVEL-1 '=' LEVEL-2 
* 
END

FIELD-1.LEVEL31, FIELD-1.LEVEL32, and FIELD-1.LEVEL33 are filled with H’5C’.

In 3.1, after the MOVE BY NAME, FIELD-2.LEVEL31, FIELD-2.LEVEL32, and FIELD-2.LEVEL33 contain H’5C’.

In 4.1, the MOVE BY NAME ABENDs with a 954/S0C7.

[Matthias1 (Matthias)]

@Ralph Zbrog

I don’t understand what Matthias is asking when referring to “REDEFINE logic.”

Maybe “REDEFINE logic” is not the completely correct name for it, but what I’m trying to say is:
I think, the interpretation of numerics in REDEFINE-sections has been changed. And this influences DISPLAY, ADD, COMPUTE, MOVE, MOVE BY NAME, etc. Due to your test I wouldn’t say, that the MOVE-BY-NAME-Statement has been changed.

The initial question of this thread was: “Why does a MOVE BY NAME convert spaces to zeros?” And my answer was all the time: “MOVE BY NAME doesn’t make conversions. REDEFINE (numeric to alpha or vice versa) implies a conversion!” So I called it “REDEFINE logic”…

It has always been good practice to avoid mapping alpha fields to numeric

ACK! In this case we’re talking about redefinitions of fields in views!

BTW: From my point of view, mapping alpha to numeric works good if you use it carefully. But the programmer should use the redefinition only in “one direction”. This means: Don’t move values into the field and next time into the redefinition. Use one side only for reading purposes and the other side for changing the value.

And much more important is to avoid mappings like integer ↔ alpha.

[thespin]

Thanks, Ralph, for running that test program in version 3.1.6.

It appears that the BOTTOM LINE on this problem is that from Natural versions 3.1.6 to 4.1, BOTH the MOVE BY NAME instruction AND the MOVE elementary numeric-to-numeric instruction were changed.

The HR system I am working on was designed with Alpha dates in YYYYMMDD format (what version was Natural Native Date format introduced?). Most Date variables in the system are redefined with numeric elementary items probably for ease of manipulation.

If Ralph is right and SAG did not HIGHLIGHT these changes for it’s customer base when 4.1 was released, then tsk-tsk-tsk …

[Wilfried_B]

Adam “thespin”,

I’m not willing to give up!

From the release notes:(COMPOPT)

NMOVE22 - Assignment of Numeric Variables of Same Length and Precision
ON Assignments of numeric variables where source and target have the same length and precision is performed as with Natural Version 2.2.
OFF Assignments of numeric variables where source and target have the same length and precision is performed as with Natural Version 2.3 and above, that is they are processed as if source and target would have different length or precision. This is the default value.

Set it to ON and your problems are (hopefully) gone! You can set it for each program with a OPTIONS NMOVE22=ON or with COMPOPT before compiling the code.

That’s it!

[thespin]

[quote="Wilfried B