View previous topic :: View next topic
|
Author |
Message |
jajularamesh
New User
Joined: 21 Nov 2005 Posts: 8
|
|
|
|
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 |
|
|
Phantom
New User
Joined: 04 Sep 2005 Posts: 25
|
|
|
|
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 |
|
|
iknow
Active User
Joined: 22 Aug 2005 Posts: 411 Location: Colarado, US
|
|
|
|
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 |
|
|
Kavitha Palani
New User
Joined: 16 Nov 2005 Posts: 8
|
|
|
|
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 |
|
|
Prasanthhere
Active User
Joined: 03 Aug 2005 Posts: 306
|
|
|
|
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 |
|
|
kanak
Moderator
Joined: 12 Mar 2005 Posts: 252 Location: India
|
|
Back to top |
|
|
rahulsingh
New User
Joined: 22 Nov 2005 Posts: 1 Location: Mysore
|
|
|
|
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 |
|
|
Phantom
New User
Joined: 04 Sep 2005 Posts: 25
|
|
|
|
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 |
|
|
lundbomj
New User
Joined: 22 Sep 2005 Posts: 1
|
|
|
|
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. 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 |
|
|
iknow
Active User
Joined: 22 Aug 2005 Posts: 411 Location: Colarado, US
|
|
|
|
Team,
One small clarification,
How to use XREF complier option at the time of compilation? |
|
Back to top |
|
|
P.RAJESH Currently Banned New User
Joined: 20 Mar 2008 Posts: 54 Location: chennai
|
|
|
|
hi all,
iknow wrote :
How to use XREF compiter option at the time of comilation ?
Please clarify this. |
|
Back to top |
|
|
mambopras
New User
Joined: 11 Nov 2008 Posts: 52 Location: Hyderabad
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
mambopras
New User
Joined: 11 Nov 2008 Posts: 52 Location: Hyderabad
|
|
|
|
Thanks a lot Robert! |
|
Back to top |
|
|
raghuxpert
New User
Joined: 13 Oct 2010 Posts: 1 Location: Pune
|
|
|
|
Thanks a Lot |
|
Back to top |
|
|
nigelosberry
New User
Joined: 06 Jan 2009 Posts: 88 Location: Ggn, IN
|
|
|
|
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 |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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 |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006 Posts: 1050 Location: Richmond, Virginia
|
|
|
|
Bill - don't get too irked - its the weekend. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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 |
|
|
|