How to resolve the SOC4 abend
Narasa Reddy
Please help me out, how to resolve the SOC4 abend? This abend i got when i was running the IMSDB/COBOL program's
Thanks
Naras...@maintec.com
Maintec Technologies Pvt. Ltd.,
303a, 100 Feet Road,
Indiranagar 1st Stage,
Bangalore - 560 038
Tel:5274410-13(4 Lines)
Fax:5274414
Maintec Inc,
5540 Centerview Dr
Suite 200
Raleigh, NC 27606
USA
Phone: (919)424-6323
Fax: (919)424-3866
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Charles Mills
Seriously, S0C4 is a low-level "machine level" error that does not have
a single high-level cause (like, for example, "DD statement missing"
does). It is caused by a machine instruction that attempts to reference
main storage at an address that is "invalid" at the time for the program
in question.
S0C4's are sometimes caused by some sort of low-level mis-match -
perhaps your COBOL compiler and your level of LE is mis-matched, or your
IMS routines and your level of IMS is mis-matched. Were there any errors
on the linkedit of the program? Did the program ever work? What changed
between when it worked and when it failed?
Charles
Gerry....@ibm-main.lst
S0C4 is issued when the program tries to access storage that does not
belong to it, known generally as a "storage violation". There are many
scenarios that lead to S0C4. The abend should be accompanied by a dump,
possibly an abendaid dump, if there is no dump, rerun with dd cards for
SYSUDUMP and ABENDAID. Use the dump to get the offset of the currently
executing instruction within the load module. use this figure in
conjunction with with condensed listing for the program, this will tell you
what line of code the program was on when the abend occurred. This should
give you some idea of what data was being referred to at the time, that
data, for whatever reason, is not present.
Note: make sure the program listig you uses matches the date and time of
the failing program.
This is a general description to point you in the right direction.
GA
Narasa Reddy
<narasareddy@MAIN To: IBM-...@BAMA.UA.EDU
TEC.COM> cc:
Sent by: IBM Subject: How to resolve the SOC4 abend
Mainframe
Discussion List
<IBM-...@BAMA.UA
.EDU>
09/08/04 14:19
Please respond to
IBM Mainframe
Discussion List
Hi,
Please help me out, how to resolve the SOC4 abend? This abend i got when
i was running the IMSDB/COBOL program's
Thanks
Naras...@maintec.com
----------------------------------------------------------------------
Knutson, Sam
Landmark was simply
HAVE ABEND. SEND FIX.
We did:-)
All joking aside Narasa you need to provide a lot more details to get
assistance on IBM-MAIN but you really probably need to work to resolve this
yourself using local resources.
A S0C4 is very common abend others have already described.
You likely want to seek the assistance of someone in your organization who
is already familiar
with dump reading and problem determination. There is likely a bug with
either the application program, your IBM software, or your ISV software.
Start with the most obvious assumption a flaw in the application program and
work your way up. The application programmer should be looking into this
with a listing at hand.
Best Regards,
Sam Knutson, GEICO
Performance and Availability Management
(office) 301.986.3574
Some days you are the bug, some days you are the windshield.
.
====================
This email/fax message is for the sole use of the intended recipient(s) and
may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution of this email/fax is prohibited. If
you are not the intended recipient, please destroy all paper and electronic
copies of the original message.
McKown, John
look at the last record read into an FD _after_ closing the file.
Unfortunately, closing the file in COBOL invalidates the buffer, but the
address remains. So you get: (1) an S0C4; (2) bad data; (3) the data you
wanted. It seems to be a crap shoot as to which happens.
--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and its' content is
protected by law. If you are not the intended recipient, you should delete
this message and are hereby notified that any disclosure, copying, or
distribution of this transmission, or taking any action based on it, is
strictly prohibited.
Greg Smith
> The "best" fax I ever saw come into the International service desk at
> Landmark was simply
>
> HAVE ABEND. SEND FIX.
>
>
> We did:-)
I had an auditor ask me the other day what was a s0c4.
I started to explain about how it could be a page or
segment fault or a storage key mismatch, etc, and he
said `No, you're wrong... It's to keep your foot warm'.
Greg Smith
Phil Payne
> look at the last record read into an FD _after_ closing the file.
> Unfortunately, closing the file in COBOL invalidates the buffer, but the
> address remains. So you get: (1) an S0C4; (2) bad data; (3) the data you
> wanted. It seems to be a crap shoot as to which happens.
Worked just fine in ICL 1900 COBOL. I've often thought IBM COBOL implementations were rather
perverse in mapping FDs onto buffers when _many_ other COBOLs reserve storage.
--
Phil Payne
http://www.isham-research.com
+44 7785 302 803
Neal Eckhardt
>Knutson, Sam wrote:
>> The "best" fax I ever saw come into the International service desk at
>> Landmark was simply
>>
>> HAVE ABEND. SEND FIX.
>>
>>
>> We did:-)
>
>I had an auditor ask me the other day what was a s0c4.
>I started to explain about how it could be a page or
>segment fault or a storage key mismatch, etc, and he
>said `No, you're wrong... It's to keep your foot warm'.
>
>Greg Smith
OK, We had that joke in the early 60's when I worked at Blue
Cross/Blue Shield in Rochester, NY.
It's still not funny.
Neal