daszynski
asked on
Using IBM CBLLE (COBOL), I want to pass an array of three items in binary to another program.
We currently have a COBOL program that calls an old IBM program to generate a graph using QGDDM. The receiving IBM program is specific in the parameters it is receiving. One of the parameters is looking for a three (3) item table that we have in working storage that is coded as binary. The one that works now is IBM COBOL. We need to use ILE COBOL because of the new postal barcode can only be handled with ILE.
When we took the current program and compiled with ILE, it gives us an error stating that the array we are sending is not subscripted. True, we are sending the AX array, which consists of three (3) items. The current one works because the error is only a warning. ILE is saying it is a fatal error.
Each item in the table is described as:
03 FX OCCURS 3 TIMES INDEXED BY F-INDEX PIC S9(5) COMP-4.
Our call looks like this:
CALL "GDDM" USING CHBATT
FRAME-COUNT
FX.
The error we are getting is:
* 1285 MSGID: LNC2750 SEVERITY: 30 SEQNBR: 102600
Message . . . . : 'FX' table item but not subscripted.
So we get no valid compile. On the call, we have tried FX (1), but of course it only passes the first of three items.
QUESTION becomes:
How can we pass this array to the receiving program????
Larry
When we took the current program and compiled with ILE, it gives us an error stating that the array we are sending is not subscripted. True, we are sending the AX array, which consists of three (3) items. The current one works because the error is only a warning. ILE is saying it is a fatal error.
Each item in the table is described as:
03 FX OCCURS 3 TIMES INDEXED BY F-INDEX PIC S9(5) COMP-4.
Our call looks like this:
CALL "GDDM" USING CHBATT
FRAME-COUNT
FX.
The error we are getting is:
* 1285 MSGID: LNC2750 SEVERITY: 30 SEQNBR: 102600
Message . . . . : 'FX' table item but not subscripted.
So we get no valid compile. On the call, we have tried FX (1), but of course it only passes the first of three items.
QUESTION becomes:
How can we pass this array to the receiving program????
Larry
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I am having trouble setting up the tables with the correct byte count......
COMP-4 and COMP-3 is confusing to me. Maybe that is the whole problem....it is not passing
the correct number of bytes? But the error says
'Data type specified on a CALL GDDM not valid.'
Here is what I have and it is giving this error....
01 DX-ARRAY PIC X(16).
01 DX-ARRAY1 REDEFINES DX-ARRAY.
03 DX-ARRAY2.
05 DX OCCURS 4 TIMES
INDEXED BY D-INDEX PIC S9(5) COMP-4.
01 FRAME-ARRAY PIC X(12).
01 FRAME-ARRAY1 REDEFINES FRAME-ARRAY.
03 FRAME-ARRAY2.
05 FX OCCURS 3 TIMES INDEXED BY F-INDEX PIC S9(5) COMP-4.
01 Y-ARRAY PIC X(52).
01 Y-ARRAY1 REDEFINES Y-ARRAY.
03 Y-ARRAY2.
05 AY OCCURS 13 TIMES INDEXED BY AY-INDEX
PIC S9(5)V9 COMP-3.
Coding for call is:
CALL "GDDM" USING DSOPEN (Line 1280 in compile)
DEVICE-ID
DEVICE-FAMILY
DEVICE-TOKEN
DEVICE-PROCOPT-CNT
DX-ARRAY2
DEVICE-NAME-CNT
DEVICE-NAME.
Error:
Message ID . . . . . . : LNR7200 Severity . . . . . . . : 50
Message type . . . . . : Inquiry
Date sent . . . . . . : 12/06/10 Time sent . . . . . . : 13:11:17
Message . . . . : Message 'CPF8680' in program object 'FOK065' in library
'FOBJECT' (C D F G).
Cause . . . . . : Message 'CPF8680' was detected in COBOL statement 1280 of
COBOL program 'FOK065' in program object 'FOK065' in library 'FOBJECT'.
Recovery . . . : Enter a G to continue the program at the next MI
instruction, or a C if no dump is wanted, a D if a dump of the COBOL
identifiers is wanted, or an F to dump both the COBOL identifiers and the
file information. The message text for 'CPF8680' follows: 'Data type
specified on a CALL GDDM not valid.'
Possible choices for replying to message . . . . . . . . . . . . . . . :
C -- No formatted dump is given
D -- A dump of the COBOL identifiers is given
Dump:
LNR7200 exception in module 'FOK065 ', program 'FOK065 ' in library 'FOBJECT ' at statement number 1280.
Optimization level for the module is '*NONE'.
Formatted data dump for module 'FOK065 ', program 'FOK065 ' in library 'FOBJECT '.
Data in dump:
DX OF DX-ARRAY2 OF DX-ARRAY1
DIM(1) (1 4)
DX OF DX-ARRAY2 OF DX-ARRAY1
BIN(4)
(1) 00000.
"00000000"X
... ...
DX-ARRAY
CHAR(16) " "
"0000000000000000000000000 0000000"X
COMP-4 and COMP-3 is confusing to me. Maybe that is the whole problem....it is not passing
the correct number of bytes? But the error says
'Data type specified on a CALL GDDM not valid.'
Here is what I have and it is giving this error....
01 DX-ARRAY PIC X(16).
01 DX-ARRAY1 REDEFINES DX-ARRAY.
03 DX-ARRAY2.
05 DX OCCURS 4 TIMES
INDEXED BY D-INDEX PIC S9(5) COMP-4.
01 FRAME-ARRAY PIC X(12).
01 FRAME-ARRAY1 REDEFINES FRAME-ARRAY.
03 FRAME-ARRAY2.
05 FX OCCURS 3 TIMES INDEXED BY F-INDEX PIC S9(5) COMP-4.
01 Y-ARRAY PIC X(52).
01 Y-ARRAY1 REDEFINES Y-ARRAY.
03 Y-ARRAY2.
05 AY OCCURS 13 TIMES INDEXED BY AY-INDEX
PIC S9(5)V9 COMP-3.
Coding for call is:
CALL "GDDM" USING DSOPEN (Line 1280 in compile)
DEVICE-ID
DEVICE-FAMILY
DEVICE-TOKEN
DEVICE-PROCOPT-CNT
DX-ARRAY2
DEVICE-NAME-CNT
DEVICE-NAME.
Error:
Message ID . . . . . . : LNR7200 Severity . . . . . . . : 50
Message type . . . . . : Inquiry
Date sent . . . . . . : 12/06/10 Time sent . . . . . . : 13:11:17
Message . . . . : Message 'CPF8680' in program object 'FOK065' in library
'FOBJECT' (C D F G).
Cause . . . . . : Message 'CPF8680' was detected in COBOL statement 1280 of
COBOL program 'FOK065' in program object 'FOK065' in library 'FOBJECT'.
Recovery . . . : Enter a G to continue the program at the next MI
instruction, or a C if no dump is wanted, a D if a dump of the COBOL
identifiers is wanted, or an F to dump both the COBOL identifiers and the
file information. The message text for 'CPF8680' follows: 'Data type
specified on a CALL GDDM not valid.'
Possible choices for replying to message . . . . . . . . . . . . . . . :
C -- No formatted dump is given
D -- A dump of the COBOL identifiers is given
Dump:
LNR7200 exception in module 'FOK065 ', program 'FOK065 ' in library 'FOBJECT ' at statement number 1280.
Optimization level for the module is '*NONE'.
Formatted data dump for module 'FOK065 ', program 'FOK065 ' in library 'FOBJECT '.
Data in dump:
DX OF DX-ARRAY2 OF DX-ARRAY1
DIM(1) (1 4)
DX OF DX-ARRAY2 OF DX-ARRAY1
BIN(4)
(1) 00000.
"00000000"X
... ...
DX-ARRAY
CHAR(16) " "
"0000000000000000000000000
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The older COBOL/400 did not have COMP-2 (floating point), so COMP-3 was one of the work-arounds. But ILE COBOL does have COMP-2. You might want to try using actual floating point for the elements that are defined in GDDM for it. Perhaps GDDM adapts to the calling protocol.
A COMP-4 (binary/integer) data item will be 4 bytes wide. A COMP-3 (packed decimal) will be 2 digits per byte plus a sign nybble (half-byte); S9(5)V9 is six digits plus a sign nybble plus the half-byte pad for a total of 4 bytes.
COBOL passes operational descriptors when USING ... DESCRIBED is specified for LINKAGE TYPE for a CALL. You might adjust the sizes of your existing items, or try using actual floating point where GDDM expects them, or try operational descriptors for either of the previous two alternatives.
I don't have any COBOL uses of GDDM any more, so I can't run easy tests. (Since the DOS graphical 5250 went away, I stopped working with GDDM.)
I can't think of any other choices right now. If additional errors show up after you run new tests, post them here. They might help illuminate what's happening.
Tom
A COMP-4 (binary/integer) data item will be 4 bytes wide. A COMP-3 (packed decimal) will be 2 digits per byte plus a sign nybble (half-byte); S9(5)V9 is six digits plus a sign nybble plus the half-byte pad for a total of 4 bytes.
COBOL passes operational descriptors when USING ... DESCRIBED is specified for LINKAGE TYPE for a CALL. You might adjust the sizes of your existing items, or try using actual floating point where GDDM expects them, or try operational descriptors for either of the previous two alternatives.
I don't have any COBOL uses of GDDM any more, so I can't run easy tests. (Since the DOS graphical 5250 went away, I stopped working with GDDM.)
I can't think of any other choices right now. If additional errors show up after you run new tests, post them here. They might help illuminate what's happening.
Tom
ASKER
Provided info that help find the problem.
Tom