I am wondering how people can get along not being able to go through
a dump. Maybe I am way off base here but this would seem pretty straight
forward to me. You have the entry point to the abend and you have the entry
point of the problem program. Subtract one from the other and you have the
instruction that was being executed at the time of the abend (another way of
saying the line of code in the Cobol program). My initial guess is it is
going to be a F8 instruction (zero and add packed could be wrong my memory
is old and fails from time to time). Being a Cobol program there are easy
ways to find what is in the data without looking for it in a dump. If you
have access to the source code add a display command of the fields in use by
the instruction failing. But that does not lead to why is it abending is it
poor coding or is it bad data? If bad data you need to go address why bad
data got to this point.
Maybe I am just o old, but I would have assisted the applications
programmer in this manner before setting a slip trap. Just maybe application
programmers do not debug there dumps any longer.
Carl Swanson
Mobile:215.688.1459
Email: [email protected]
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Steve Comstock
Sent: Wednesday, July 03, 2013 2:45 PM
To: [email protected]
Subject: Re: Question on how to debug S0C7 (data exception) abend
On 7/3/2013 12:11 PM, Kirk Talman wrote:
> 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.
Hmmm. Well, the education with the biggest impact on memory and behavior
comes that way. But 'best'?
It might be better if one were educated to create applications that worked
correctly, how to use the avialable tools most effectively, how to find and
fix errors.
The best way to get that is being taught by an excellent mentor who knows
the way the company's code works and who can explain things clearly and
patiently.
After that, ahem, I would suggest a well-designed class that demonstrates
techniques for design, coding, testing, debugging and maintenance. Such a
class might even be designed to almost force the students into making errors
along the way - fixing problems in the context of a training environment
instead of production. At least a little bit like 'real life'.
But, of course, I'm biased that way.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
>
> IBM Mainframe Discussion List <[email protected]> wrote on
> 07/03/2013 07:10:18 AM:
>
>> From: "Mowry, Norma E CIV DISA ESB (US)" <[email protected]>
>> To: [email protected],
>> Date: 07/03/2013 07:11 AM
>> Subject: Question on how to debug S0C7 (data exception) abend Sent
>> by: IBM Mainframe Discussion List <[email protected]>
>>
>> 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 [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
