IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

How to fix S0C7 Abend?


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
jajularamesh

New User


Joined: 21 Nov 2005
Posts: 8

PostPosted: Mon Nov 21, 2005 5:41 pm
Reply with quote

Wrote a Cobol program and i am able to compile it and when i tried to run it i got a SOC7 error how to handle it.


plz any one tell the systematic procedure to handle those kind of errors
Back to top
View user's profile Send private message
Phantom

New User


Joined: 04 Sep 2005
Posts: 25

PostPosted: Mon Nov 21, 2005 5:54 pm
Reply with quote

jajularamesh,

SOC7 is called Data Exception Error. It occurs because of the following reasons.

Code:

S0C7 A numeric field contained non-numeric data.
1. Numeric data was not initialized.
2. A subscript or index contained an invalid value.
3. A comp-3 field had an invalid sign.
4. A group move overlaid a numeric field with non-numeric data.


Resolution:
1. Go to SYSOUT and check the line which says that the program has ended in S0C7.
2. It will have a Hex Offset - something like +00A12D.
3. Now, go to your compile JCL sysout and search for the keyword HEXLOC.

You will get something like this.
Code:

CHARS 'HEXLOC
 COMMAND INPUT ===>                                            SCROLL
LINE #  HEXLOC  VERB                        LINE #  HEXLOC  VERB     
003741 00163A PERFORM                       003765 00163A EXIT       
003775 001642 INITIALIZE                    003777 001660 OPEN       
003779 001692 SET                           003780 001696 DISPLAY     
003785 0016B8 PERFORM                       003864 0016B8 OPEN       
003867 0016E6 SET                           003868 0016EA DISPLAY     
003873 001736 IF                            003874 001762 SET         


Now search for the Hex value displayed in step 2 in this list. You may not find the exact match. In this case you need to go for the closest hex number. For example, if you get SOC7 at Hex 001662, the closest match you have is 001660. Now you can get the line number corresponding to this Hex loc (line num for Hex 1660 is 3777). Now search for first occurance of 3777 in the compile listing.

This statement or the statements that immediately precede / follow this statement will be the one which caused the SOC7.

Please let me know if you need more information.

Hope this helps,

Thanks,
Phantom
Back to top
View user's profile Send private message
iknow

Active User


Joined: 22 Aug 2005
Posts: 411
Location: Colarado, US

PostPosted: Tue Nov 22, 2005 9:53 am
Reply with quote

Hi jajularamesh,

I suggest you to go for a search wherein you can get many more information on SOC7 abend plus articles realted to it.

Please use the "search" option before posting any query.
Back to top
View user's profile Send private message
Kavitha Palani

New User


Joined: 16 Nov 2005
Posts: 8

PostPosted: Tue Nov 22, 2005 4:08 pm
Reply with quote

Basically you need to correcting the offending data. Many times the reason for SOC7 is an un-initialized numeric item.
Examine that possibility first. Many installations provide you a dump for run time abend?s ( it can be generated also
by calling some subroutines or OS services thru assembly language). These dumps provide the offset of the last
instruction at which the abend occurred. Examine the compilation output XREF listing to get the verb and the line
number of the source code at this offset. Then you can look at the source code to find the bug. To get capture the
runtime dumps, you will have to define some datasets (SYSABOUT etc ) in the JCL. If none of these are helpful, use
judgement and DISPLAY to localize the source of error. Some installation might have batch program debugging
tools. Use them.
Back to top
View user's profile Send private message
Prasanthhere

Active User


Joined: 03 Aug 2005
Posts: 306

PostPosted: Tue Nov 22, 2005 4:45 pm
Reply with quote

Best thing is For resloving this type of error is to find the offset address using the expeditor or anyother tools and check the corresponding moves whether a numeric field has been moved to an alphabetic field......
Thanks
Back to top
View user's profile Send private message
kanak

Moderator


Joined: 12 Mar 2005
Posts: 252
Location: India

PostPosted: Tue Nov 22, 2005 5:48 pm
Reply with quote

check here

How to find the S0C7 Error
Back to top
View user's profile Send private message
rahulsingh

New User


Joined: 22 Nov 2005
Posts: 1
Location: Mysore

PostPosted: Tue Nov 22, 2005 7:18 pm
Reply with quote

SOC7 error is caused as a result of "DATA TYPE MISMATCH".
Ex- if a dataname is coded to hold an integer value and if you try to insert any other value to that say string etc...you will get a SOC7 error.
just check the datatype which a dataname can hold and the entries you r making to it.

Explanation of S0C7 Error:

Data Exception:
The "S0" prefix indicates a data exception error.
The "C7" suffix specifies that the error occurred during a decimal arithmetic operation.

Decimal Data Error:
The error typically occurs when there is an issue with packed-decimal or zoned-decimal data fields in the COBOL program.
Common Causes of S0C7 Error:

Invalid Numeric Data:
Attempting to perform arithmetic operations on data that is not in a valid numeric format.
Invalid or non-numeric characters in numeric data fields.

Packed-Decimal or Zoned-Decimal Issues:
Mishandling or incorrect processing of packed-decimal (COMP-3) or zoned-decimal (COMP) data types.

Data Conversion Errors:
Problems converting data between different numeric formats or between character and numeric data types.

Steps to Resolve S0C7 Error:

Review Abend Message and Dump:
Examine the abend message and associated dump to identify the specific data field and instruction causing the error.

Check Data Fields:
Verify the data fields involved in the arithmetic operation for valid numeric values and formats.
Ensure that packed-decimal and zoned-decimal fields are properly initialized and contain valid data.

Inspect Arithmetic Operations:
Review the COBOL code to ensure that arithmetic operations are performed correctly and that data types are handled appropriately.

Data Validation and Error Handling:
Implement data validation checks to ensure that only valid numeric data is processed.
Include error handling routines to gracefully handle data exceptions and prevent program abends.

Debugging and Testing:
Use debugging tools and test cases to simulate different data scenarios and validate the program's behavior.
Test with various input data to identify edge cases or data anomalies that may trigger the S0C7 error.
Back to top
View user's profile Send private message
Phantom

New User


Joined: 04 Sep 2005
Posts: 25

PostPosted: Wed Nov 23, 2005 11:04 am
Reply with quote

rahulsingh,

Quote:

"DATA TYPE MISMATCH".


Partially true. This happens especially if the receiving field is Packed Decimal. Since MVS checks the sign bit of Packed decimal field after move and it is has a invalid bit then throws up S0C7. It doesn't happen for other numeric picture clauses.

Thanks,
Phantom
Back to top
View user's profile Send private message
lundbomj

New User


Joined: 22 Sep 2005
Posts: 1

PostPosted: Fri Feb 10, 2006 4:53 pm
Reply with quote

Hi Phantom, and thanks for a very structured and comprehenive explanation.

It does assume that you know how to go to your compile sysout - but when you are as new at this as I am, it aint necessarily so. icon_redface.gif So, though embarrassed as I may be, I simply must know.

I have no problem identifying the offset, and I understand clearly what to do with it once I have entered the blasted compile sysout - I just don't know how to find that. You see, I am so new, I don't even know this.

If you, or any other kind soul would explain this one step, I will be eternally greatful.

Thanx,
the Wee1
Back to top
View user's profile Send private message
iknow

Active User


Joined: 22 Aug 2005
Posts: 411
Location: Colarado, US

PostPosted: Fri Feb 10, 2006 5:34 pm
Reply with quote

Team,

One small clarification,

How to use XREF complier option at the time of compilation?
Back to top
View user's profile Send private message
P.RAJESH
Currently Banned

New User


Joined: 20 Mar 2008
Posts: 54
Location: chennai

PostPosted: Tue Jul 22, 2008 10:12 am
Reply with quote

hi all,

iknow wrote :

How to use XREF compiter option at the time of comilation ?

Please clarify this.
Back to top
View user's profile Send private message
mambopras

New User


Joined: 11 Nov 2008
Posts: 52
Location: Hyderabad

PostPosted: Tue Nov 18, 2008 5:47 pm
Reply with quote

Hi friends,
I have a question regarding the SOC7, if i move an x(9) variable to a 9(9) variable...would i get a SOC7?

Regards,
Mambo
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Tue Nov 18, 2008 6:10 pm
Reply with quote

Quote:
I have a question regarding the SOC7, if i move an x(9) variable to a 9(9) variable...would i get a SOC7?
You won't automatically get an S0C7. For example, if the X(9) variable value is '123456789' and the receiving field is 9(09) then the move is fine and you'd NEVER get a S0C7 from it. If the value is 'ABCDEFGHI' then when you do the move you won't get a S0C7 until you try to use the numeric field for arithmetic. Of course, if the receiving field is S9(09) COMP then you get a S0C7 quickly.

Compile a program with LIST option and look at the generated assembler code -- it can clarify things greatly.
Back to top
View user's profile Send private message
mambopras

New User


Joined: 11 Nov 2008
Posts: 52
Location: Hyderabad

PostPosted: Wed Nov 19, 2008 10:16 am
Reply with quote

Thanks a lot Robert!
Back to top
View user's profile Send private message
raghuxpert

New User


Joined: 13 Oct 2010
Posts: 1
Location: Pune

PostPosted: Mon May 23, 2011 1:49 am
Reply with quote

Thanks a Lot
Back to top
View user's profile Send private message
nigelosberry

New User


Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN

PostPosted: Sat May 28, 2011 1:39 am
Reply with quote

mambopras wrote:
Hi friends,
I have a question regarding the SOC7, if i move an x(9) variable to a 9(9) variable...would i get a SOC7?

Regards,
Mambo


A S0C7 error will be raised if and only if a packed decimal is involved.

An arithmetic operation on a corrupt zoned decimal used in a cobol program may result in a S0C7. But the error is raised because behind the scenes the zoned decimal would have converted into packed decimal and the arithmetic operation would be performed on that.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat May 28, 2011 12:30 pm
Reply with quote

nihalansari wrote:
mambopras wrote:
Hi friends,
I have a question regarding the SOC7, if i move an x(9) variable to a 9(9) variable...would i get a SOC7?

Regards,
Mambo


A S0C7 error will be raised if and only if a packed decimal is involved.

An arithmetic operation on a corrupt zoned decimal used in a cobol program may result in a S0C7. But the error is raised because behind the scenes the zoned decimal would have converted into packed decimal and the arithmetic operation would be performed on that.


Why drag up an old question?

What is a "corrupt zoned decimal"? Is it a bit of storage that will "go down in the third" or give you a government contract for inflated values?

If I just wrote my code in another language, would I avoid the S0C7?

Why "may" it give a S0C7? Does it depend on the position of the moon? Whether the operations staff had a good dinner? Or what?

And what if you just test it? Or just move it? Are either of those "arithmetic", and if so, which?
Back to top
View user's profile Send private message
Phrzby Phil

Senior Member


Joined: 31 Oct 2006
Posts: 1049
Location: Richmond, Virginia

PostPosted: Sun May 29, 2011 3:33 am
Reply with quote

Bill - don't get too irked - its the weekend.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sun May 29, 2011 4:02 am
Reply with quote

It's the trouble with typing. If you forget the smileys, sorry, "emoticons", it can be difficult to get the intent.

I was in a bit of a rush. Off to a kids' party. Now that I look at it, it does seem like one of those rants, I have to admit. Exactly like one.

Sorry, nihalansari, I didn't mean it the way I left it looking. I was trying to, humorously, point out some of the shortcomings in what you said. Since the original, or the latest original (topic seems to have been restarted a number of times), was a bit old, and a very basic question, it didn't seem to need more than that.

Of course, you can still say, Bill, lay off the "humour", it is the weekend.

:-)

Thanks Phil, I'd not have noticed otherwise.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts Call an hlasm from REXX in batch and ... CLIST & REXX 4
No new posts What is the most complex abend you've... Mainframe Interview Questions 8
No new posts ISAM and abend S03B JCL & VSAM 10
No new posts Abend S0C4 11 (Page Translation Excep... PL/I & Assembler 16
No new posts S0C7 - Field getting overlayed COBOL Programming 2
Search our Forums:

Back to Top