Receiving a S0C7 abend in my CA Easytrieve program: How do I find the statement that caused the S0C7 data exception?

Document ID : KB000056406
Last Modified Date : 14/02/2018
Show Technical Document Details
An S0C7 data exception occurs in CA Easytrieve programs when non-numeric data is placed in a numeric field. The following program contains a deliberate data exception:
 1 PARM LINK(EZTEST10 R) DEBUG (STATE FLOW)
2 FILE PERSNL1 FB (150 1800)
3 NAME-LAST 17 8 A HEADING('LAST' 'NAME')
4 NAME-FIRST 25 8 A HEADING('FIRST' 'NAME')
5 PAY-GROSS 94 4 P 2 HEADING('GROSS' 'PAY')
6 *
7 WS-DATA-EXCEPTION W 5 A
8 WS-NUMBER WS-DATA-EXCEPTION 5 P 0
9 *
10 JOB INPUT PERSNL1
11 WS-DATA-EXCEPTION = ' '
12 WS-NUMBER = WS-NUMBER + 1
13 PRINT RPT1
14 REPORT RPT1 LINESIZE 80
15 TITLE 01 'EZTEST10 - CONTROL BREAK ON DEPT'
16 LINE 01 PERSNL1:NAME-FIRST +
PERSNL1:NAME-LAST +
PERSNL1:NAME-LAST +
PERSNL1:PAY-GROSS +
WS-NUMBER

WS-DATA-EXCEPTION is a 5-byte alphabetic field that is redefined by the packed numeric field WS-NUMBER. WS-DATA-EXCEPTION is set to 5 hex '40' blanks and then WS-NUMBER is computed by adding 1. This is a classic formula for an S0C7 data exception. If this happened to be a very large program with pages and pages of code you may need to review the following two methods to determine which instruction caused the S0C7.

  1. One method to discover the statement number and the statements that were executed prior to the S0C7 is to include in the PARM statement, the sub-parameter DEBUG (STATE FLOW). STATE saves the statement number of the statement currently being executed. The statement number is then printed in the associated abnormal termination messages. FLOW activates a trace of the statements being executed. The statement numbers are printed in the associated analysis report. STATE caused the following to print:

12 *******A006 PROGRAM INTERRUPT - CODE 7 (DATA EXCP)

This indicates that the error occurred at statement number 12 and that the error was an S0C7 data exception.

FLOW caused the following to print:

FLOW TABLE - MAXIMUM ENTRIES 100

10 11 12

This indicates that statements 10, 11, and 12 were executed just prior to the S0C7.

  1. If the program abends and the PARM does not include DEBUG (STATE FLOW) you can do the following:
    1. Find the contents of register 3.
    2. Add hex '4E' to the contents of register 3.
    3. The contents of register 3 plus hex '4E' contains the statement number in hex.
    4. Convert the statement number in hex to decimal to find the problem statement in the compiled output listing.

Register 3 in the sample program dump is 7D80, as the following illustrates:

R0 0000000C R1 00000006 R2 00007C95 R3 00007D80

R8 00000000 R9 000069B0 R10 80015636 R11 00008D70

Add 7D80 to hex '4E' and you get 7DCE. Go to hex 7DCE in the dump

00007DC0 00009A8E 00010000 00000000 0000000C

The value at 7DCE is hex C. Convert hex C to decimal and you get 12. Statement 12 is the statement number that caused the S0C7 data exception.