IBM Mainframe Forum

We've been getting an odd error in a report program...unfortunately, I don't have a current abend to give a better example. We are getting this error.

GZ0035S There was an unsuccessful OPEN or CLOSE of file REPORTC in program DOC0
Neither FILE STATUS nor an ERROR declarative were specified. The status
From compile unit DOC0001P at entry point DOC0001P at compile unit offs
at address 00009C86.

This program has 1 vsam file and 6 reports. The vsam has a file status but depending on the abend, it will show 1-2 of the reports in fault analyzer with the 90 file status (see bottom). I'm guessing its because the program closes all the files at once. I'm the z/os guy and it's been 20 years since I've written any type of code. I believe that at the time of this abend, the vsam file is opened by a cics application which I'm guessing is causing the 90. I just want to ignore the abend.

Before the "STOP RUN", can we do something in cobol to stop the program from abending?





Failing File Name . . . . . : REPORTC
Data Set Name . . . . . . : CHFP.CHFCMAIL
File Attributes . . . . . : ORGANIZATION=SEQUENTIAL, ACCESS MODE=SEQUENTIAL,
RECFM=FIXED BLOCKED ASA
Last I/O Function . . . . : CLOSE
Open Status . . . . . . . : NOT OPEN
File Status Code. . . . . : 90
Implementor-defined condition.

No record buffers available (file not open).

Failing File Name . . . . . : REPORTG
Data Set Name . . . . . . : CHFP.CHFGMAIL
File Attributes . . . . . : ORGANIZATION=SEQUENTIAL, ACCESS MODE=SEQUENTIAL,
RECFM=FIXED BLOCKED ASA
Last I/O Function . . . . : CLOSE
Open Status . . . . . . . : NOT OPEN
File Status Code. . . . . : 90
Implementor-defined condition.

For file status 90, the manual says:

For multithreading only: A CLOSE of a VSAM or QSAM file was attempted on a thread that did not open the file.
v
Without multithreading: For VSAM only: See the information about VSAM return codes in Using VSAM status codes (VSAM files only) in the Enterprise COBOL Programming Guide.
v
QSAM files: No further information available. See the DFSMS error message for more information.

The obvious solution would be to add the FILE STATUS clause to each SELECT statement and recompile the program. However, that does not resolve the problem -- possibly the program cannot close the file because some other task has the data set open? And if it is giving the error on the sequential COBOL file, what is the associated DFSMS error message in the job output?

Robert,

I'm pretty sure that a CICS region has the file open. This job is opening the vsam file INPUT only. My COBOL is a little rusty but I don't think there needs to be a file status on a report file?? The vsam in question is INPUT and in use so fails on the close. It's a timing thing cuz it works every day but Saturday. After the CLOSE, can you just move zeroes to FILE-STATUS (WS name) and get past this?

Thanks, Jeff

My COBOL is a little rusty but I don't think there needs to be a file status on a report file

Actually, EVERY file in a COBOL program should have a FILE STATUS specified. For example, if your program somehow winds up with the ADV option specified, your report file LRECL would be increased by a byte and you could wind up with a mismatch between the FD 01 length and the actual physical data set LRECL.

What is the difference between the rest of the week and Saturday? That should be a big clue as to what's going on with the code.

You can move zeroes to the FILE STATUS variable name, but COBOL will ignore that -- the file status is set during the CLOSE processing which happens under the covers; nothing you can do in your code will change that setting of the file status. And the error message tells you that the particular DD name referenced does NOT have a FILE STATUS clause -- hence the IGZ0035S message.