We have an Adabas file with a column called INFO that is defined to the database as A40. The current Natural application move a mixed data type content to the column. The Natural program is written like this:
define data local
1 #column (a40)
1 redefine #column
2 #first-half (a20)
2 #packed (p5)
2 #last-half (a17)
end-define
move ‘begin’ to #first-half
move 123.5 to #packed
move ‘end’ to #last-half
move #column to the A40 database column INFO and update.
When we do a select INFO from the table (via sample java app or Infonaut), all we see is the value “begin”. It is as if CONNX ignore the packed value compressed into this A40 field as well as all text that comes after.
How can we process this INFO column in our java code via CONNX JDBC? In the data dictionary this column is define with Text.
We need to extract the packed value in our java application.
When I display INFO in Natural on mainframe using (em=hhhhh), I see the INFO column as having the right character representation + the packed representation so I know the problem is not with the storing of the data in the Adabas database.
The Adabas SQL Gateway maps Adabas data types to SQL data types. In this case, the adabas data type of the field is A40 - and that is mapped to a SQL type of CHAR 40. As Rick stated, by default, the embedded binary zero in the character field is causing the data to be truncated. However, there is a setting that will enable you to retrieve the full 40 characters that can be enabled in the configuration manager, ALLOWNULLINCHAR. I recommend that you open a support issue can we can walk you through the details on how to accomplish this.
Thanks for the suggestion. I am aware of the Allowed Null in Character configuration parm that you mentioned. Even when I do get all 40 bytes back, I find it still ugly to parse such a string to extract the “packed” values…
I will test this out.
I think you guys are great: always have very good suggestions!
We faced a similar problem on our side. Data fields defined as Axx in adabas FDTs were used as containers which may hold data types not equal to Alpha. Working strictly in one environment (we are on z/OS) this works fine. Trying to query these data will fail. Larry’s comment exactly describes the problem.
We tried combinations of SUBSTRING() and CONVERT() to extract the data from the alpha fields, but we were
not successful. We surived using a post processing logic: The sql records are “cracked” using natural programs. Using natural you have the “redefine” mechanism available.
By the way, some of our “redefines” are even worse: The first byte defines how the rest of the alpha field is (ab)used.
Maybe the Adabas SQL Gateway will offer something like a “redefine” mechanism in the future.
This may be applied on the CREATE TABLE/CLUSTER DESCRIPTION.
Currently, you are on your own and must crack the alpha fields.