How access array in copybook from cobol to local in natural?

Hello my friends.
i have a natural program that call a cobol program using a copybook that fill a array in that copybook. and i created a array in the local , so i can access the results in the local. The problem is that the values are not right.
copybook in cobol are pic s9(04) comp-5 and in the local in the natural i’m using (I4).
Thanks for the help.

Are you using a free trial or a product with a customer license?

What are trying to achieve? Please describe in detail.

Do you get any error messages? Please provide a full error message screenshot and log file.

Have you installed latest fixes for the products

Hello Oliveira,

Could you please share what is wrong with the data?
Is it part of redefine ?
Is it part of a group ?

Eli

the natural program call a cobol, that make a select in a db2 and fill a array in the copybook

results in the display on cobol:
x1 = 00163 - PIC S9(04) COMP-5
x2 = 00002 - PIC S9(04) COMP-5
x3 = 09909 - PIC S9(04) COMP-5
x4 = X322098 - PIC X(06)
x5 = 00011 - PIC S9(04) COMP-5

results in the local on Natural
#x1 = 163 - (I02)
#x2 = 16338 - (I02)
#x3 = 16338 - (I02)
#x4 = - (A06)
#x5 = 16338 - (I02)

in the local on the natural, the values are completely off from the cobol.

Hello,

You first mentioned that you used I4 and in the sample it is I2.
What is the correct one?
We assume it should be I2.

Eli

it’s I02 in the natural for all the PIC S9(04) Comp-5 in the copybook.

I02 and S9(04) Comp-5 should both allocate 2 bytes of memory, so the individual fields should align correctly. How are the arrays defined in the Cobol copybook versus your Natural array definition? Maybe the array definitions don’t match up correctly? You might try redefining the Natural array as a single large (A) field and display that field to see how the data is mapped into it when returned from the Cobol program. You would have to display as hex output since most of the fields are binary.

Hope that helps.
George

in the copybook all pic S9(04) Comp-5 are defined in the natural as I02 and the pic x in the copybook are defined in the natural as A()… the definition in the both arrays are matching correctly. how a display the hex output in natural?
thanks George for the help.

Put an edit mask on the fields to be displayed as hex like this

WRITE #X1 (EM=HH) #X4(EM=H(6))

Isn’t the problem in the cobol declaration? because S9(04) there is a positive or negative sign, and in Natural I2 it does not accept a sign, in Natural it has to be an alphanumeric (A05)

Alysson Oliveira via Software AG Tech Community & Forums <techcommunity@discoursemail.com> escreveu no dia terça, 12/04/2022 à(s) 12:44:

Format I fields in Natural are ALWAYS signed, so the value range for an I2 is +32767 to -32768

i tried thoses and i got “4040404040”

Then your (A5) field is “empty” aka contains “all blanks”

i reset all those fields before call cobol. and even thou i got this “garbage” values except the first value, that came right.

H’404040404040’ is a perfect initial value for an (A6) field after a RESET.

i should get “garbage” for all the fields? why the first field get right, but the others still get wrong?

We would need to see the CALL in your NATURAL Program plus the COBOL PROCEDURE DIVISION + LINKAGE SECTION.

x4 = X322098 - PIC X(06)

X322098 is only 3 bytes and x3220 are not valid printable EBCDIC characters, btw.

in the natural the call of cobol are:
SET CONTROL ‘P=C’
CALL ‘PGM-Name’ USING #LOCAL

in the cobol:

LINKAGE SECTION
01 DFHCOMMAREA.

PROCEDURE DIVISION USING DFHCOMMAREA.

We would need to see the structure within the COMMAREA, but please consider the following from the documentation

If a group name is used, the group is converted to individual fields; that is, if a user wishes to specify the beginning address of a group, the first field of the group must be specified.

well, i don’t get it. but in the local at natural, the array’s definition is the same order in the copybook at cobol.

What the documentation says here is that if you have

1 #LOCAL
  2 #X1 (I2)
  2 #X2 (I2)
..

then try to specify #X1 on the CALL statement instead of #LOCAL