Look this example, running on Natural 6.3.6 ( IBM aix 5.3)
define data
local
01 w-alf (A10)
01 redefine w-alf
02 w-nome (a6)
02 w-num (N1)
01 w-num1 (N1)
end-define
*
w-alf := 'andreae ’
move w-num to w-num1
write ‘=’ w-alf ‘=’ w-nome ‘=’ w-num ‘=’ w-num1
end
…
Running this program, I see that Natura can move alphanumeric data into numeric field. Is it normal? Can someone tell me why?
is it normal? Why moving
There has just been a thread on SAG-L regarding this very issue. Natural has always permitted the REDEFINE of any format to any other format, so long as the lengths are compatible.
The responsibility for not not making a mess of things resides with the programmer. In the program you posted, it is not Natural’s “fault” if w-num has a non numeric value, it is the programmers fault. The programmer coded such that a long alpha value moved into w-alf created a non numeric value (an e) in w-num. Natural assumed you knew what you were doing.
Here is one of my favorite programs to demonstrate why NOT to redefine an alpha as numeric (or visa versa) (I posted this on SAG-L)
DEFINE DATA LOCAL
1 #A (A5)
1 REDEFINE #A
2 #N (N5)
END-DEFINE
*
INPUT ‘#A HERE==>’ #A
*
WRITE 5T ‘#N BEFORE ADD ==>’ #N #N (EM=H(5))
ADD 1 TO #N
WRITE 5T ‘#N AFTER ADD ==>’ #N #N (EM=H(5))
END
I entered 123 for #A. Please note below I am on my PC, hence the Hex may look unfamiliar. HOWEVER, the exact same thing happens on the mainframe.
PAGE # 1 DATE: 09-11-10
PROGRAM: REDEF01 LIBRARY: INSIDE
#N BEFORE ADD ==> 123 0 3132332020
#N AFTER ADD ==> 12301 3132333031
Not only do we have the floating zero on the first WRITE; not only is 123 + 1 = 12301; But, even worse, look what happened to the blank in the fourth position. It is now a zero.
Now look what happens when I change the ADD statement to: ADD 0 TO #N (123 as INPUT again)
PAGE # 1 DATE: 09-11-10
PROGRAM: REDEF01 LIBRARY: INSIDE
#N BEFORE ADD ==> 123 0 3132332020
#N AFTER ADD ==> 12300 3132333030
Note that the ADD of zero still changes the last two characters from 2020 (blanks) to 3030 (zeroes).
SO, Suppose I move #A (or #N) to #HOLD, then ADD #EXTRA TO #N, then try an IF #HOLD = #N (or #A; basically to see if we added to #N); and suppose #EXTRA is zero. We will be “told” that the IF is not true; WRONG !!!
Now for more fun, enter -123 into #A.
Alpha and Numeric are NOT the same format. There is a limited subset of values where you can successfully get away with this (e.g. enter 12345 for #A). For other values you are just asking for trouble.
Do I do this while “playing” with Natural, or for code that will never be used by anyone but myself? Yes. Would I ever do this (or recommend doing this) in someone elses production code? Absolutely NOT. It is a time bomb waiting to go off.
steve
Natural allows it because the underlying architectures allow it (mainframe and Open Systems).
N-format is what IBM calls external decimal or zoned decimal. The values 0 thru 9 are represented internally as H’F0’ thru H’F9’. (On ASCII machines the internal representation is different, but Natural works the same way.) The internal representations of the characters ‘0’ thru ‘9’ also are H’F0’ thru H’F9’, so in memory, there is no difference between ‘12345’ and 12345.
Natural knows that the left-most nibble is the “zone” and can be ignored in all but the right-most byte, in which the zone represents the numeric sign, because the numeric value is really in the right-most nibble. Problems can occur if you move characters other than the numeric digits to a numeric target. For example, move ‘ABCDE’ to an N5 and you get 12345. This may not be what you expected. Move any character that does not contain a numeric digit in the right-most nibble, and your program will abend.
Redefinition of alpha as numeric (or vice versa) is a similar but separate issue. There are several legitimate reasons for doing this, but you must be careful to avoid the problem described above.