IBM Mainframe Forum

Hi,
When I try executing an IMS-COBOL program, the job abends with S0C1.

Program Details:
I have 4 programs in the setup as below.
p800(main program) - IMS
p810(sub module called by p800)
p820(sub module called by p800)
p830(sub module called by p810 and p820)

Note: all these programs were written using COBOL-I and we are using the same COBOL-I compiler to compile the programs now.

Compilation details:
Firstly i compile the submodules. All compilations end with RC=4. Secondly i compile the main module by including the references to the submodules. This compilation ends with RC=0.

PARMS in Compilation step:
PARM('NOADV,DUMP,MAP,LIST',
'NODYNAM,SXREF,DTECT,NOSTA,NOFLO,NOSYM,NOTRU',
'BUF=1024K','SIZE=2048K')

Options I use in LINK-EDIT step:
LPARM='LIST,AMODE=24,RMODE=24'
Now when i run the test setup using the load module of the main program, the jobs abends with S0C1.

I doubt there is some mistake with the options i use in LINK-EDIT in the compilation JCL.

Any help,suggestion is much appreciated.

Many thanks,
Karthick

PARMS in compilation step of Sub programs:

'BUF=1024K','SIZE=2048K','ENDJOB,NODYNAM,SXREF,DTECT,NOSTA,NOFLO,NOSYM,NOTRU'

Comparing the two PARMS that I use, can any of these parameters be the reason for the S0C1 abend?

Is there any material that i could refer to understand the meaning of these options that are in PARMS?

Thanks in advance,
Karthick

1. None of the data you posted is helpful.
2. There is almost ZERO chance that anything you posted is in any way related to the S0C1 ABEND.
3. The fact that you are trying to blame the system instead of looking at YOUR CODE is not a good indication of success.
4. The S0C1 is caused by something in your programs -- possibly mismatched CALLING / USING parameter / argument pairs, possibly a table index or subscript getting out of range, possibly by something else -- but there is something you have done to cause the problem. The system does not just generate the S0C1 ABEND because it wanted to.
5. The S0C1 is NOT caused by compile parameters, nor by linkage editor / binder parameters, so start debugging. Look at the output messages, find the offset into the program that got the ABEND, use the offset to fin the line of code, and start figuring out why your code is wrong.

Robert,
Thanks for responding..

The programs that I mentioned have been running in production for more than a decade. Now, we want to analyse the flow of the programs. So, we included some DISPLAY statements in the programs and compiled them(all jobs finished with satisfactory RC). Then we ran the test job. This abends with S0C1. The sysout and sysdump are as below.

SYSOUT:


SYSDUMP:



Anyway I'll check out the options that you mentioned.

what about investigating the DDfMdelt module and the S315 abend ???

If the sequence is the S315 occurs, then the S0C1 occurs -- you need to completely forget about the S0C1 and work on the S315 ABEND. The reason is that once the S315 has occurred, any abend after that will be due to the system attempting to handle / recover from the S315 and hence if you fix the S315, the S0C1 will not recur.