S0C7 is the most simple cause of abend I can imagine.

The only problem is to find the position in the program (that is: the source line) where the error occured. If you have this, you know the name of the variable causing
the error, and the rest is a piece of cake.

To get this, you need no tool.

Simply look at reg 13 at the time of abend. This is the address of the current
save area. The word 2 after the word at which reg 13 points to contains the
address of the higher save area. There at position 16 (word 5) you find the
address of the entry of the current procedure or function (which should be
a little lower than the content of the current PSW at the time of error).

Subtracting this from the PSW, you get the error offset - related to the beginning of the procedure or function. And, by looking at the PPA1 control block (which you can find by adding the content of EPA + 12 to the EPA address), you will get
the name of the procedure (at PPA1 + X'38'), at least this is true for the
current PL/1 and C compilers (maybe COBOL, too).

Then you have the function name and the offset; now it's time to look at
the compile listing. Of course you have it at hand, because it's production run,
so the compile listing must have been archived during the deployment of the
program.

If you need classes for your mainframe developers to do dump analysis
in Germany, Austria or Switzerland (or other countries), please contact me offline.

Kind regards

Bernd




Am 03.07.2013 20:11, schrieb Kirk Talman:
There have been several various good answers to this problem.

As a certified alte kacker, I would like to comment on what this tells us
about the state of mainframe IT.

- Apparently one can be in "Operating Systems Support" w/o having been an
application programmer.  One of the advantages many of us older persons on
this list and in the industry have is that we have "seen it before".  The
idea that a person working in any technical job on a mainframe would not
know what a S0C7 is and how to go after it is amazing to me.  At one time
there were machines w/o packed arithmetic, but now, apparently, training
in system administration functions is considered adequate.  Who on this
list learned the majority of what they know via instruction?  Most people
learned most things by doing.  The work we do is a craft, part art, part
science.

- The idea in this day and age of not having a tool to give diagnostic
information when an abend occurs may indicate a lack of understanding by
management, but is still amazing.  IBMs Fault Analuzer is not, I think,
expensive but is quite adequate to the task even in complex
CICS/DB2/IMS/MQ environments.  If I were told there were less expensive
products available, I would not be surprised.

- On the other hand, I recently had to modify a program older than the
company.  In code and macros I saw names of persons now high level
managers.  The code had a S0C7 recovery section that was miscoded because
invalid assumptions were made about the effect of ignoring records causing
the abend.  And the people who "own' the code were reluctant to fix the
root cause even when the fix was spelled out for them.  They finally did
so only when embarrassed publicly.

- The best education comes while acquiring scars and observing same in
ones peers.

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on
07/03/2013 07:10:18 AM:

From: "Mowry, Norma E CIV DISA ESB (US)" <norma.e.mowry....@mail.mil>
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 07/03/2013 07:11 AM
Subject: Question on how to debug S0C7 (data exception) abend
Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>

We have a production job that is abending with S0C7 reason 00000007.
I set a slip to capture a dump but I can't seem to find the input
record that is causing the S0C7 in this dump.  I also have a CEEDUMP
but that's not real helpful in diagnosing the issue.  I looked a
setting a slip with a trace but don't think that will do any good to
get to the problem record.

Norma Mowry


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to