Conference noted::hackers_v1

284.0. "Cobol close of an unopened file fails, sometimes" by BARAKA::LASTOVICA (Norm Lastovica) Mon Aug 11 1986 15:52

	This has also been entered in the COBOL notes file.
        
    	I have a large-ish Cobol application that has the ability to
    be called as a function.  This has worked for years when the object
    was linked with the calling program.  What I am now trying to do
    link this beast as a shareable image so that I can
    LIB$FIND_IMAGE_SYMBOL to activate it only when I need it.  After 
    getting all the psects figured out (write and no share as needed), 
    it seems to work very well.

       	Except (of course), the code has an internal check for some 
    errors, and if they occur, it jumps down to a clean up routine.  This 
    routine closes all the files, terminates FMS and then exits.  Problem 
    is, that when closing files that have not been opened, it dies with either
    an access violation or a runtime library internal fatal error (or
    something like this).
    
    	Via the generated machine code listing and the debugger
    I've tracked it down to where the $CLOSE fails (invalid XAB error
    from RMS) and then the program calls COB$IOEXCEPTION (to handle
    the error section I presume).  Anyhow, COB$IOEXCEPTION gets passed
    a number of paramters including the RAB for the file.  As it starts
    checking the RAB for goodness, it checks for the FAB and either 
    finds none (zero pointer and complains with the internal error) 
    or finds garbage pointer and access violates.
    
    	The book makes it sound like it is OK to close and unopened
    file.  And in fact, this works all the time when the program is
    linked either as an executable or in with another program.  How 
    does COB$IOEXCEPTION handle this?  Are the RAB and FAB
    prebuilt with "file closed" information to start?  If so, where
    would I have gone wrong with the shared copy?
    
    	All of this code seems to work just fine in the case where the
    program is linked with other code (ie, not a shared image).  The
    LIB$FIND_IMAGE_SYMBOL does not seem to change things any (as opposed
    to linking against the shared image).  The pointers to the rab and
    fab are coming out the $PDATA psect and look like they want to referance
    other places in the same psect.
    
    	So, why does this fail?  Comments?  Where do I go next?
    

    The problem is that COBOL uses .ADDRESS to initialize fields in the
    overlaid Psect that is used for COBOL EXTERNAL files.  Thus, if
    five modules declare the FD, there will be four too many .ADDRESS
    fixups made to that longword.

    This is normally no problem -- COBOL copies in a static version of
    what should be there before OPENing the file (the static version
    also has .ADDRESS data, but is not in an overlaid Psect).  However,
    if some I/O is attempted before that file is *ever* OPENed, then
    the bogus .ADDRESSes cause COBOL trouble in reporting the error.