B37s.
--- bernd.oppol...@t-online.de wrote: From: Bernd Oppolzer <bernd.oppol...@t-online.de> To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Question on how to debug S0C7 (data exception) abend Date: Thu, 4 Jul 2013 17:01:29 +0200 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 _____________________________________________________________ Netscape. Just the Net You Need. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
