Using IBM CBLLE (COBOL), I want to pass an array of three items in binary to another program.

daszynski used Ask the Experts™
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:


Our call looks like this:


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????


Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE® only passes the first of three items.

That should only be true if you're passing BY CONTENT, which might not work for QGDDM anyway. (It's an OPM program, though it might be C.)

If this is your CALL statement:
                     FX (1). 

Open in new window should be fine.

However, a better structure would be to FX as a level 05 item within some level 01 group item. Then pass the level 01 item instead of FX. (It wouldn't have to be levels 01 and 05. Use any level numbers to create a higher level group item to contain the lower level array.)

How did you determine that only a single element was being passed?

I didn't notice that FX is currently a level 03 item. Make it a level 05 instead, and create a new level 03 item above FX. Name it something obvious like FX-ARRAY or FX-GROUP. Then pass FX-ARRAY (or FX-GROUP) on the CALL.



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

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                              


 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                                                
          (1)                            00000.                                
          ...                            ...                                    
          CHAR(16)                       "                "                     
Introduction to Web Design

Develop a strong foundation and understanding of web design by learning HTML, CSS, and additional tools to help you develop your own website.

Got it to work!

After rereading your messages, I questioned, like you, how I "assumed" that it took the first parameter when I used FX(1).  In reality, I didn't know for sure.  So I changed the three failing tables to be FX (1), DX (1), and AY (1).  It compiled and ran!

I did have one additional problem after that, as I ended up with 2 print of my customer bill and one with the graphic table on it.  We had to change the OVRPRTF command with *JOB on the parameter OPNSCOPE.  That didi it.  We now get the graph on the customer bill.

Thank you for your help.  Larry Daszynski
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.



Provided info that help find the problem.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial