Page 1 of 1

S0C1 abend when running a COBOL-IMS program

PostPosted: Mon Aug 27, 2012 11:29 am
by karthick-quest
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

Re: S0C1 abend when running a COBOL-IMS program

PostPosted: Mon Aug 27, 2012 12:01 pm
by karthick-quest
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

Re: S0C1 abend when running a COBOL-IMS program

PostPosted: Mon Aug 27, 2012 2:39 pm
by Robert Sample
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.

Re: S0C1 abend when running a COBOL-IMS program

PostPosted: Mon Aug 27, 2012 6:47 pm
by karthick-quest
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:
CEE3250C The system or user abend S315  R=NULL     was issued.                 
         From entry point DDfMdelt at compile unit offset +000000C4 at entry offset +000000C4 at address 06750C04.


SYSDUMP:

COMPLETION CODE      SYSTEM = 0C1      REASON CODE = 00000001             
                                                                           
   PSW AT ENTRY TO ABEND   078D1000  00000706  ILC  02  INTC  0001         
0PSW ADDRESS 00000706 AT TIME OF ERROR DOES NOT POINT TO AN ACTIVE MODULE   


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

Re: S0C1 abend when running a COBOL-IMS program

PostPosted: Mon Aug 27, 2012 6:51 pm
by enrico-sorichetti
what about investigating the DDfMdelt module and the S315 abend ???

Re: S0C1 abend when running a COBOL-IMS program

PostPosted: Mon Aug 27, 2012 7:18 pm
by Robert Sample
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.