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