use of CLOSE UNIT FOR REMOVAL

From: Frank Swarbrick (Frank.Swarbrick_at_efirstbank.com)
Date: 03/04/04 

Date: Thu, 4 Mar 2004 11:27:05 -0700

First, the COBOL in question here is COBOL for VSE/ESA. I'm guessing it
also applies to other IBM mainframe COBOLs such as Enterprise COBOL (for
z/OS), but perhaps not.

History: We have several COBOL jobs that read 1 or more tapes that are in
the same format (NACHA format, Visa Base II format, etc.). On some days
there is only one tape, some days two, some days three etc. Most of our
program do something like this (some of this is pseudo-COBOL):

OPEN INPUT TAPE-FILE
READ AND PROCESS TAPE-FILE UNTIL END OF FILE
CLOSE TAPE-FILE
ASK OPERATOR "Is there another tape?"
if YES, tell operator "eject tape and then answer 'yes' to continue. when
operator answers we loop back to the top.
if NO end program

I (and the operators) have long wished that COBOL itself could eject the
tape.

Somewhere (and it's been a while so I don't recall where) I came upon the
knowledge that using the statement "CLOSE file-name UNIT FOR REMOVAL" will
eject the tape *without* actually closing the file. See the following
example:

OPEN INPUT TAPE-FILE
READ TAPE-FILE
CLOSE TAPE-FILE UNIT FOR REMOVAL
READ TAPE-FILE
CLOSE TAPE-FILE UNIT FOR REMOVAL
READ TAPE-FILE
CLOSE TAPE-FILE WITH LOCK

What this would do is open tape 1, read a record on tape 1, eject tape 1,
read a record on tape 2 (once tape 2 is loaded), eject tape 2, read a record
on tape 3 (once tape 3 is loaded), eject tape 3 and quit.

This seems to work fine. The problem is reading the tape until the
end-of-file condition is met. Once the EOF condition is met, while I can
close it for removal and it ejects the tape my next read returns with status
code '46' ("preceding READ statement caused an at end condition").

This both does and does not make sense. It makes sense in that the error
it's giving is accurate. However I still want to be able to do what I want
to do, which is reach the end of 1 tape, eject that tape, have a new tape
loaded and continue processing.

Now in the case of the file formats I am looking at there is a trailer
record. I am able to set an EOF field to true once I've read the trailer
record but prior to attempting another read. By doing this I can avoid
triggering the actual "at end" condition. This allows my program to work as
desired. But it still bugs me! It seems to me that doing the CLOSE UNIT
FOR REMOVAL should reset the "at end" condition to no longer be true.

Any thoughts? Do other COBOLs work this way? Am I just being anal, since I
already know a work-around?

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

Relevant Pages

  • Re: use of CLOSE UNIT FOR REMOVAL
    ... and REWIND with COBOL on VSE (differences between DOS/VS COBOL and - I think ... > there is only one tape, some days two, some days three etc. ... > READ AND PROCESS TAPE-FILE UNTIL END OF FILE ... tell operator "eject tape and then answer 'yes' to continue. ...
    (comp.lang.cobol)
  • Re: use of CLOSE UNIT FOR REMOVAL
    ... I know just enough about VSE to get myself in trouble. ... and REWIND with COBOL on VSE (differences between DOS/VS COBOL and - I think - ... > there is only one tape, some days two, some days three etc. ... > READ AND PROCESS TAPE-FILE UNTIL END OF FILE ...
    (comp.lang.cobol)
  • Re: [OT] EBCDIC to ASCII OPTCD=Q? (JCL)
    ... I *think* that if you use BOTH CODESET clause and OPTCD=Q, ... SHOULD be able to produce an ASCII TAPE output. ... utilities/JCL and I hope to avoid a dedicated COBOL program... ... If you want a DFSort answer, ...
    (comp.lang.cobol)
  • Re: Is VIO mandatory?
    ... The mention of COBOL and its work files brought to mind a little exercise ... COBOL of the installation to innovate by assigning the work files to scratch ... Having first started programming in a TOS (TAPE Operating System) environment, I can agree that watching the work tapes was interesting. ...
    (bit.listserv.ibm-main)