Mainframe, MVS and zOS Discussion

Hi,

I'm trying to figure out what line of code is cause a SOC4. In my job output, I see the address from the sdsf outout. This shop does not have anything like IBM debugger/dumpmaster so I'm not sure what to do with the address and offset. When I do a find on this in the output there is no displayable data and that makes to just make a guess.

I've put in display and can verify that it reads exactly 100 records and then abends . With this in mind, I tried running with the same input reccord (101th)- a made up file with 100 copies of the same record. And it processes this record okay. And again, it abended on the 100th record.

So how do I go about it?

Hi,

With the address that is displayed in the SDSF .. You need to look at the compilation listing... It would point you to the failing statement..

The consistent ABEND is a clue.

S0C4 is one of those codes that can be caused by MANY things, so it can be particularly difficult to debug. If you are getting a dump, there will be the starting (load) address of your program (in hexadecimal). Subtract this from the address of the abending statement to get the offset. The compile listing will give you the offsets for the various COBOL statements. Locate the offset in the compile listing (if the offset is between two statements, use the first statement). This gives you the statement where the ABEND occurred. This should give you some idea about why the ABEND occurred.

Is this just a simple COBOL program or does it use DB2 or some other database, interface to some other serice, etc?

If this is a straight program, I suspect the 0c4 is "the victim". My guess is that something "walked on storage" due to a table overflow or other operation that caused trying to go "out of boubds". Suggest you put some "eye-catchers" in the ws as well as a spot for the "last set" eye-catcher and periodically move a new value there. The last value should be visable when the abend is reached.

Adding CEEDUMP in JCL would come handy as well