Table overflow in COBOL question.

[Shruti Yadav]

Hi,

Today we got an abend in production. It was for a COBOL IMS program. It calls a DB2 sub-program and some date routines also. Abend was S0C1. When we analyzed it came to the point that IMS was giving the status-code 'AD'. We looked for it and below are the details:

https://www.ibm.com/docs/en/ims/13.1.0? ... nations-ad

AD
Explanation
For call-level programs: Either the function parameter on the call is invalid or the function is not supported for the type of PCB specified in the call. Only applies to full-function DEQ calls. Some possible reasons are:

The function parameter is invalid.
A system service call used a PCB that is not the I/O PCB.
A call issued in a DCCTL environment referred to an unsupported PCB or database.
A message GU or GN call used an alternate PCB instead of the I/O PCB.
A database call used a PCB that is not a DB PCB.
A message GU used the I/O PCB without specifying IN=trancode in the BMP JCL.
A SETS or ROLS call included the I/O area but omitted the token.
A CPI Communications driven program issued the SETO call on the I/O PCB.
A call was issued from an IFP region on an I/O PCB.
Invalid subsystem level for spool API processing.
A DL/I call was made against a DEDB or MSDB PCB in a non-Fast Path system.

But it does not make any sense that it can abend with wrong "function parameter". Because it comes from a COBOL 'fix copybook', which is like this. I mean this is a common copybbok for so many programs, so it can not pass a wrong function-parameter as the above explanation says:

Code: Select all

|++++| 01  DLI-FUNCTIONS.                                       
|++++|*                                                         
|++++|     05  GU                      PIC X(4)  VALUE 'GU  '.  
|++++|     05  GN                      PIC X(4)  VALUE 'GN  '.  
|++++|     05  GNP                     PIC X(4)  VALUE 'GNP '.  
|++++|     05  GHU                     PIC X(4)  VALUE 'GHU '.  
|++++|     05  GHN                     PIC X(4)  VALUE 'GHN '.  
|++++|     05  GHNP                    PIC X(4)  VALUE 'GHNP'.  
|++++|     05  ISRT                    PIC X(4)  VALUE 'ISRT'.  
|++++|     05  DLET                    PIC X(4)  VALUE 'DLET'.  
|++++|     05  REPL                    PIC X(4)  VALUE 'REPL'.  
|++++|     05  PCB                     PIC X(4)  VALUE 'PCB '.  
|++++|     05  TERM                    PIC X(4)  VALUE 'TERM'.  
|++++|     05  CHKP                    PIC X(4)  VALUE 'CHKP'.  
|++++|     05  XRST                    PIC X(4)  VALUE 'XRST'.  

Now, we analyzed further. There was a table in COBOL program:

Code: Select all

01  WS-VATID-COUNTRY-CODE-ENTRIES.                   
     05 WS-VATID-COUNTRY-CODE-TABLE OCCURS 10 TIMES. 
         10 WS-VATID-COUNTRY-CODE   PIC X(02).       

The input file using which this internal COBOL table was populated had 41 entries but the table was only able to accommodate 10 entries and that made I think data to overflow to "IMS function" and abedn happeend. I have two questions now:

1. Why the program did not abend in the COBOL Table itself?
2. When such 'overflow' of data happens, how do we know it happened? How would we know which another COBOL variable has got the wrong data, is there an easy way than doing like we did with multiple iterations?

Thanks

[Robert Sample]

1. Why the program did not abend in the COBOL Table itself?
2. When such 'overflow' of data happens, how do we know it happened? How would we know which another COBOL variable has got the wrong data, is there an easy way than doing like we did with multiple iterations?

1. The program did not abend because table overflow is not an abend condition. It is not good programming practice, but COBOL allows table overflows without any messages.
2. In general, you won't know when a table overflow occurs, nor will you know when any COBOL variable is affected by the overflow. HOWEVER, you can use the SSRANGE compiler option to force COBOL to do subscript range checking (along with reference modification checking and checking variable length variables). There is a run-time impact to using SSRANGE, so CPU usage will go up if you specify it. And since it is a compiler option, you must recompile the program to be able to use the SSRANGE option.

[Shruti Yadav]

Thank you Robert.

I have asked about using SSRANGE but it's not allowed in production. I looked at about it online too but looks like most of companies don't use it in production. Then how do we solve the table-overflow problem in COBOL, is there a way?

[Robert Sample]

IBM recommends using SSRANGE. It is the first and best way to resolve table overflows in COBOL.

If you're not able to use SSRANGE due to site standards, you really have only 3 options:
1. Use SSRANGE in test and turn it off for the production compile. This will not guarantee all possible instances of table overflow will be prevented, but it will prevent many of them. If a table is loaded from a data set, then it is possible for a table overflow to occur only in production so this will not resolve every table overflow.
2. Modify your code to ensure that every reference to a table element is preceded with code to validate that the table limits are not exceeded.
OR
3. Accept that you're going to have some table overflows in production and be prepared to handle them.

[Shruti Yadav]

Thanks Robert.

Can a DEPENDING ON CLAUSE be of better choice in this case? My original table does not have that definition.

[Robert Sample]

As far as table overflow, a table with OCCURS DEPENDING ON can still overflow because you specify the maximum number of occurrences of the table and the program can still exceed that count.

[Shruti Yadav]

hmm...Thanks Robert.