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

daszynskiAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Member_2_276102Commented:
...it 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:
   CALL "GDDM" USING CHBATT      
                     FRAME-COUNT
                     FX (1). 

Open in new window

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

Tom
Member_2_276102Commented:
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.

Tom
daszynskiAuthor Commented:
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)                       "                "                     
                                         "00000000000000000000000000000000"X    
                 
Angular Fundamentals

Learn the fundamentals of Angular 2, a JavaScript framework for developing dynamic single page applications.

daszynskiAuthor Commented:
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 files....one 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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Member_2_276102Commented:
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
daszynskiAuthor Commented:
Provided info that help find the problem.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Operating Systems

From novice to tech pro — start learning today.