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?

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.

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.