IBM Mainframe Forum

A program has encountered an abend TELON SC07, here is the diagnosis given by Abend-Aid:

A data exception occurred during execution of program GSPTA1T2. The expected
completion code is S0C7.

Analysis of Error

The next sequential instruction to be executed in program GSPTA1T2 was at
displacement 0000B81E.


A Data Exception was caused by data referenced at displacement 44B from the start of TGT BLL cell 14 (X'000E'). The field contains
X'4040400000404040'. Refer to the data division map in the program listing
to locate the field name.

The field causing the exception is located in the linkage section of program
GSPTA1T2.

Analysis of Error
A Data Exception is caused when a computational-3 field has an invalid digit (not 0-9), or its last byte contains an invalid sign (not A, B, C, D, E, or F).

The IBM message that corresponds to the condition is:

CEE3207S The system detected a data exception (System Completion Code=0C7).


My question is:
How can I deduct the address of the problematic instruction from the information in fat, thank you for your help.

In the program listing...find where B81E fits between two lines of code. You probably won't find that exact address.

The format of the listing can change depending on options and versions of COBOL, but keep looking and you'll PROBABLY find something that shows the statements and their offset in the code. Something like:

Depending on compiler options, your compile listing may not include all this detail. In which case, the displacement that is the closest to but less than the Next Sequential Instruction.

You'll find that the line of code is dealing with something in the Linkage Section. Quite possibly something subscripted.

It will be a comp-3 field with 14 or 15 digits (numbers) including decimal places, unless the Cobol verb is a COMPUTE, where it might be considerably less.

Instead of containing a valid packed decimal value, your field contains three spaces, two bytes of binary zeros (or LOW-VALUES), then three more spaces. Maybe you can recognise the pattern space, binary zero, space already. If not, look in the dump and you'll be able to find out how many spaces there are before/after (remember, it might, but doesn't have to be, the same field repeating) to tell which table has gone "wild".

Looks like a "table-overrun" of some sort at first sight.

Look in you data division map, find BLL=14 and displacement 44B. That is the field which your program thinks is packed-decimal.