Mainframe, MVS and zOS Discussion

hiii all,

A production job is abended with soc7 error and with user return code u0999,abend occured in ps080 step, we know soc7 is arised because of bad data ,so to know in which position of cobol member problem occurred , i copied the member(pgm in ps080 step) in to my test pds, and did cobtarce on and kept displays in the program,and compile and link it successfully.with that test load lib and i am ran again the production abended job, this time job rans successfully with out any error and i wondered why it is hapend like this, and in the second case i just copied that cobol member in to my test and this time am not did any cobtrace ,and compile and link it successfully and ran the abended production job with that test laod lib and this time i got the error soc7 and u0999 like in production, and i am not able to know where problem occurs actulally,and my files doesn't support for compile listing to know the code in which abbednd hapend through offset code,and i dnt have any tools, i have only cobtarce on(displays) technique to know in which position cobol code abended, but when i did cobtrace on ,job rans successfuuly...can any one help me on this issue????

You were already advised against posting the same question on multiple forums on the 23rd

anyway ...

... this time job rans successfully with out any error and i wondered why it is hapend like this...

because this time the program was processing different data

to reproduce an error all the conditions and data should be the same

sorry to post again same issue...but i ddn't change any thing in both the cases in first case did cobtrace on in second case i did cobtrace off...i dnt think so that cobtrace made data changes....???

can u tell me another way of resolve soc7 error ?...with out using compile listing ,offset approach method.

cobtrace, whatever it is (you haven't said, it is not a standard product so who knows what it really does?) almost certainly won't change your data. However, as has already been explained, if the problem relates to code or compiler areas being overwritten, then banging in different code can change the outcome of your run. You have a compile listing for your failure in development. Use that to solve that dump.

can u tell me another way of resolve soc7 error ?...with out using compile listing ,offset approach method.

If your site has Abend Aid installed, use it.
If your site has IBM's Debugging Facility installed, use it.
If your site has another debug tool installed, use it.

Otherwise, a S0C7 ABEND pretty much REQUIRES that you have a compiler listing to determine offsets. If your site does not store production compile listings, this is a process flaw with your site. A programmer with experience in the application probably could use the dump to find the program WORKING-STORAGE and determine the reason for the S0C7 from that but this skill is not one that you have, obviously. You might talk to your senior team members and get their assistance with your S0C7.