View previous topic :: View next topic
|
Author |
Message |
Purnendu.it
New User
Joined: 11 May 2007 Posts: 57 Location: chennai
|
|
|
|
Hi,
I have a job abended due to s0c7.Its a production job stream.We
removed the error record and ran the job and it went fine.Job
was abended with s0c7.Now my question is how can i solve this
problem.What approach i should take so that this error will again
not occur in the next run?
without expediting the program is there is any other way to find the
reason
suggetions are welcome. |
|
Back to top |
|
|
sudhakar84
New User
Joined: 20 Jun 2008 Posts: 25 Location: chennai
|
|
|
|
Hi,
Get the offset address from the spool and look for the variable belongs to that offset address in the ecompiler listing.To get the compiler listing either u can look into the listing that u got while compiling or recompile and get the same.
The compiler listing will have the mapping between the variable and the address location.Since we have got the address already we can easily figure out the variable causing the S0c7.There after u can analyse the reason for the Soc7. |
|
Back to top |
|
|
Aaru
Senior Member
Joined: 03 Jul 2007 Posts: 1287 Location: Chennai, India
|
|
|
|
Pur,
Quote: |
Now my question is how can i solve this
problem.What approach i should take so that this error will again
not occur in the next run? |
First analyse and find out the reason for the abend. The topic of SOC7 has been debated before and you can search the forum for examples. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
For my $.02, a more important issue is the "error record".
If it is in some file that was created by the system, the code that creates "the records" needs to be fixed so this cannot happen again.
If the "bad record" is in some un-edited input file, the program processing that data for the first time needs to be corrected to identify the bad data so there will be no later abend.
Learning how to "debug" an 0c7 from a dump is very valuable for a developer, but it is far more important to prevent them (0c7's) in production. |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
Agree with Dick. Finding the field in error is usually a lot easier than determining when that "bad" field entered the system. It could have been many jobs/days ago. Preventing future occurrences is the big issue. The long-standing phrase "garbage in, garbage out" still holds true even today. |
|
Back to top |
|
|
|