Potential Natural Upgrade Problem in DEVL Environment

, ,
1

Greetings,

I was wondering if anyone might know what’s causing the following problem in our development environment. Please note that I am paraphrasing testing conducted by a team member:

Z/OS platform just upgraded to -
Natural 4.1.4
Adabas Online System 7.4.3
Natural Optimizer Compiler 4.1.3

There appears to be an issue with how we process fields using redefinitions of numeric fields into alpha fields under Natural 4.

We use a VSAM file that contains two different record layouts inside of the file. Positions 7-9 determine which layout to use. If the value within those positions are spaces, the record is a Header Record, otherwise it is a Trailer Record.

The issue is that the VSAM File has a field with two conflicting data formats. If record layout is Header Format the VSAM MHF-Address field in particular is an Alpha field. However, If record layout is Trailer Format the VSAM field is made up of several numeric fields (MTF-TEST-MOD-1, Etc…).

Based on our testing it appears that every field transaction (MOVE, ASSIGN, READ, FIND, Etc…) that deals with numerics goes through some form of a conversion routine that is meant to ensure valid numeric data.

Example 1:
To access the fields, we use the following command…
RD1. READ MTF BY MTF.MTF-PRIMARY-KEY STARTING FROM ’ ’

In the program I defined the view with the MTF-TEST-MOD-1 in the following method…
1 MTF VIEW OF AF-VSAM-MECH-TR-FILE
2 MTF-TEST-MOD-1
2 REDEFINE MTF-TEST-MOD-1
3 #MTF-TEST-MOD-1 (A2)

When the actual read is performed, I write both the original format of the field and the redefined version.
WRITE MTF.MTF-TEST-MOD-1 MTF.#MTF-TEST-MOD-1

Here are the results…
A3 AT

Developer Comments:
Based on the record layouts, the first record should have a value of ‘AT’ in the field since the MTF-TEST-MOD-1 Field is the 7th and 8th position of the MHF-ADDRESS Field. We see from the results that the redefined Alpha field has the correct value, but the numeric value which should have the same address pointer as the redefine has a value of A3. It appears that Natural is doing a conversion of the data as it is read into the program’s view of the VSAM DDM.

Example 2:
Now, the next requirement was to move the MTF.MTF-TEST-MOD-1 field to a different location. Here is the definition of the new location…
1 #MHF
2 MTF-TEST-MOD-1 (N2.0)

Note that I chose to use the same format for the receiving field as had been established for the sending field. Now for the move and the write…
MOVE MTF.MTF-TEST-MOD-1 TO #MHF.MTF-TEST-MOD-1
WRITE MHF.MTF-TEST-MOD-1

The results of this should have been an abend since A3 is not a valid numeric, but no abend ever occurred. Instead the new field has a very different value…
13

In this particular case, we know that a file really shouldn’t have two formats, but this just highlighted the problem of the odd conversion that Natural seems to be executing now with field transactions. I also want to stress that this is not an Adabas issue, but a Natural issue. The same code works completely different in the Test Region which has the latest upgrade of Adabas, but not of Natural.

Please provide any suggestions or comments.

2

You are committing one of the CARDINAL sins in Natural, namely REDEFINEing an alpha field as numeric.

Here is your first example (on Natural 6 - PC)

DEFINE DATA LOCAL
1 #A (A2)
1 REDEFINE #A
2 #N (N2)
END-DEFINE
*
INCLUDE AASETCR
MOVE ‘AT’ TO #A
WRITE ‘=’ #A 5X ‘=’ #N
END
Page 1 06-05-04 14:23:19

#A: AT #N: A4

Natural does the best it can. Hence, the A$ for what is ostensibly a numeric field.

Want to have even more fun??

DEFINE DATA LOCAL
1 #A (A2)
1 REDEFINE #A
2 #N (N2)
END-DEFINE
*
INCLUDE AASETCR
MOVE ‘AB’ TO #A
WRITE ‘=’ #A 5X ‘=’ #N
ADD 1 TO #N
WRITE ‘=’ #A 5X ‘=’ #N
END

Page 1 06-05-04 14:27:03

#A: AB #N: A2
#A: 13 #N: 13

So AB + 1 = 13. Oh good.

REDEFINEing alpha as numeric, and visa versa is just asking for trouble. As shown in the last example, Natural will even perform arithmetic, to the best of its ability, on alpha fields.

DO NOT use such REDEFINEs.

steve

3

Thanks Steve. I will share this information with other team members. I think one major problem is that we are maintenance programmers of badly designed application. We are working towards improvements…

Thanks again.

4

You can use MASK to check, whether the numeric redefinition is valid or not:

IF MTF-TEST-MOD-1 = MASK(NZ)
  you can use MTF-TEST-MOD-1 without any risk
ELSE
  use #MTF-TEST-MOD-1 instead
END-IF

MASK(NZ) checks for valid numeric data in numeric or packed fields, the Z stands for a signed digit.