|
View previous topic :: View next topic
|
| Author |
Message |
Maddipatla Rajasekhar
New User
Joined: 10 Mar 2009
Posts: 16
Location: Hyderabad
|
|
|
|
Hi
I am getting strange behavior from my COBOL program.
The job which executes the program is giving return code 12, when i investigated thru debugger, the program is ending up with return code 0, but the job is giving return code 12
In the dump it is saying that the saytem abend SC03 (Not S0C3)has occurred because of the undetermined module
please refer the below dump which is attached in the attachment section
and help me to get rid of this problem
thank you in advance |
|
| Back to top |
|
 |
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
| Do you have any datasets still open when you exit from the program? |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| SC03 - A DATA SET COULD NOT BE CLOSED BY THE CONTROL PROGRAM, BECAUSE THE DCB HAD BEEN ERRONEOUSLY MODIFIED. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
I do not think that anything is telling you an "undertermined module" is the cause of your problem.
The "undetermined" bit is a symptom. If you have a Cobol program but any abend tools cannot determine the name, then you very, very, likely have trashed your program, overwritten significant parts of it by accident. The SC03 is pointing that way as well. You are trying to close a file while supplying different DCB information (internally, not from the JCL) than when it was opened.
Likely subscript/index gone wild, or sub-program problem. Are you using compiler option SSRANGE? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| PeterHolland wrote: |
| SC03 - A DATA SET COULD NOT BE CLOSED BY THE CONTROL PROGRAM, BECAUSE THE DCB HAD BEEN ERRONEOUSLY MODIFIED. |
That's a lot of shouting for so early in the week, Peter? |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Bill,
you are totally right. Didnt realize CAPS means shouting. copy/paste is still not translating uppercase to lowercase, have to talk with steve balmer about that. |
|
| Back to top |
|
|
nigelosberry
New User
Joined: 06 Jan 2009
Posts: 88
Location: Ggn, IN
|
|
|
|
Not sure if TS is near to resolution(or already resolved this).
I am wondering how a cobol program can corrupt the DCB of a dataset? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
A catalogued file has a DCB.
You can code a DCB in the JCL.
But, on top of that, when you open a file from a program, you have to supply a DCB.
In a high-level compiled language, this process is hidden from you, the information supplied to the DCB being from the file definitions in the program.
However, there is an amount of storage sitting there with the DCB for the file. If you manage to blat that piece of storage, or part of it even, then you will have problems. If you set out to blat it, you'd have to do some research to find where it is. If you're happy to just let the subscripts/indexes rip, then you can squish it (or any number of other things) without ever having to know anything about it.
The TS also probably squished his "save area", or possibily the front of the program (or both) thus getting the "Undetermined Module". You can still determine the module (in a multi-module system) more-or-less easily, depending on whether static/dynamic call, validity of PSW (can be up-the-creek if a corrupted save area has been restored) and other exiting things.
It's a pity the TS failed to attach the dump. Would probably have been fun to look at.
As to the TS, he's probably noticed he did something extremely stupid and won't be back, for a while at least. |
|
| Back to top |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
| Why are we assuming it is a DCB problem? Any nonzero RC from DFP can cause this. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| nevilh wrote: |
| Why are we assuming it is a DCB problem? Any nonzero RC from DFP can cause this. |
Right, but then the return code was set because of DCB problems. |
|
| Back to top |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
| Quote: |
| Right, but then the return code was set because of DCB problems. |
How do we know that ? |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Because of this ?
| Quote: |
A task tried to end normally by issuing a RETURN macro or by branching to the return address in register 14. The task was not ready to end processing because the task had opened one or more data sets that had not been closed.
The system received a nonzero return code from Data Facility Product (DFP) indicating one of the following:
DFP returned a nonzero return code.
DFP could not successfully close one or more data sets still open because a previous error or abend had been ignored by a recovery routine or a data control block (DCB) abend exit routine.
DFP could not successfully close one or more of the task's data sets that was still open because the DCB for the data set had been incorrectly modified.
Examples of how the DCB could be incorrectly modified are:
A program containing an open DCB issued an XCTL(X) macro.
A program freed virtual storage that contained an open DCB.
The program modified the DCB incorrectly |
And if there was the following message IEC999I :
| Quote: |
IEC999I text
Explanation: text is one of the following:
mod,sub,debaddr=xxxxxx
mod,sub,workarea=xxxxxx
mod,jjj,sss[,dev,volser,dsname,nnn LOST BLOCKS]
mod,jjj,sss[,errtext]
This message is issued due to a failure during OPEN/CLOSE/EOV, DADSM, or task close processing.
In the message text:
mod
The name of the module in which the error occurred.
sub
The subroutine of the CSECT within the module in error.
debaddr
The address of a DEB that could not be properly closed. The DEB has been removed from the TCB DEB chain
xxxxxx
A text string.
workarea
The address of the work area for the module in error, which should appear in an SDUMP.
jjj
The job name.
sss
The step name.
dev
The device number.
volser
The volume serial number.
dsname
The data set name.
nnn
The number of blocks written to the hardware buffer but not written to the tape medium.
errtext
Text which describes the error which will result in O/C/EOV issuing the following ABEND0C1.
The error message includes the unit address, volume serial number, and data set name only if the error occurred during DADSM processing.
System Action: The task is ended. If errtext is specified an ABEND0C1 will be issued.
Operator Response: None
Application Programmer Response: Check previous messages or abends to help determine the reason for the failure.
If debaddr= is specified, the failure occurred during task close. The problem is probably with the program that opened the data set. The most common problem is the program modifying or freeing the storage that contains an open DCB. A '-1' after the DEB address means the open DCB or ACB storage is not accessible. Correct the problem and run the job again.
If workarea= is specified, a system problem was encountered. Prior to contacting hardware support personnel for help, make the SDUMP and failing job available. For ISO/ANSI tape labels, the system might have detected an incorrect IECIEPRM parameter list passed by an MVS routine.
If job name (jjj) and step name (sss) are specified, an indeterminate error (a program check or a machine check) was encountered during OPEN/CLOSE/EOV or DADSM processing.
If this message is accompanied by a CO3 abend and a slip dump is obtained, searching the system trace table for the DEB address and corresponding DCB address might help determine the cause of the problem. For this to be effective, the system trace table might need to be enlarged and branch tracing turned off. A trace table size of 256K should be sufficient.
If errtext is specified, a system problem was encountered during O/C/EOV processing. Before calling the IBM Support Center make the 0C1 dump and failing job available.
System Programmer Response: None
Source: DFSMSdfp
|
|
|
| Back to top |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
| Quote: |
| DFP returned a nonzero return code |
This can be caused by a close error and does not necessarily relate to a DCB problem a DEB problem could just as well be the root cause as could an error in any of the ISV DFP interfaces |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Getting Ooops all day...
I guess we'll never know for sure. I was starting from the "undetermined module" and assuming that the actual abend code wasn't going to matter too much, due to whatever had been overwritten. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| I was starting from the "undetermined module" |
When i read the initial post, i read this as an undetermined error in a module rather than an undetermined module. . .
Maybe Maddipatla Rajasekhar will post what has been learned on that system. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
| Back to top |
|
|
|
|
