How can I set READ file share flags on OPEN OUTPUT file?

During my debug session I want to follow what's written to an OUTPUT file in Visual Studio.

To do this, I step into my code, shortly after the OPEN OUTPUT statement, and try to open the file in Visual Studio.

But Visual Studio refuses to open the file. It reports that the file is "in use by another process". Same does every other application being able to open a file with read-only access.

I don't seem to be able to give correct parameters to the OPEN OUTPUT statement. I tried "OPEN OUTPUT SHARING WITH READ ONLY". However, whenever the file is created, it it's never created with FileShare.Read access (see screen recording attached to this message).

What am I doing wrong?

Your help is appreciated.

Micro Focus COBOL - No file sharing on output
  • Files opened for OUTPUT are always opened as exclusive and therefore cannot be shared. If you look at table 2 in the documentation for the OPEN statement here you will see that when the file is opened for output with any of the sharing modes another open of the file will be unsuccessful.

    You could open the file as extend or i-o after opening the file for output to create it and then you can share it.

    select test-file assign to "testfile.txt" organization is sequential lock mode is manual file status is file-status. data division. file section. fd test-file. 01 test-rec pic x(20). working-storage section. 01 file-status pic x(2) value spaces. procedure division. open output test-file close test-file open extend sharing with all other test-file display file-status move all "1" to test-rec write test-rec ...


  • Thank you for providing me with the workaround. I'll try that. Yet, let me share my concerns with you:

    To me, the table in the documentation was, or is, not clear on what the expected behavior outside of the COBOL language is (i.e. it doesn't give OS file API relevant information).

    Let's examine the table:

    In the table, I would expect the OPEN OUTPUT clause to be the "Existing Sharing Mode and Open Mode" part on the right.

    Given that the other programs open the same file using (basically):

    I would expect the OPEN OUTPUT clause with SHARING WITH READ ONLY added to allow for reading the file, because GENERIC_READ should be equivalent to OPEN INPUT:

    File sharing.png



    Am I wrong with this assumption?

    How should I read the table correctly if I'm reading it wrong now?

  • May I ask what is the semantic locking difference between OUTPUT and EXTEND for line sequential files? Is such difference defined in a COBOL standard?

    As far as I can see, the only difference between the two options is that the file handle pointer is set to EOF by EXTEND, while it isn't by OUTPUT. I'm not able to comprehend why the first option requires an exclusive lock whereas the other doesn't. Particularly when there is a dedicated locking option available, both for the SELECT statement as well as the OPEN statement.


    From the OPEN documentation:

    5. (MF) - If the WITH LOCK phrase is specified, the OPEN statement acquires a lock on the whole file. (This is equivalent to specifying LOCK MODE IS EXCLUSIVE in the SELECT statement for the file. See the topic The File Control Entry in the chapter Environment Division.)

    16. (MF) - When LOCK MODE IS EXCLUSIVE is specified in the SELECT/ ASSIGN statement of a file, successful execution of an OPEN statement of that file locks the file exclusively to that run unit. 

    17. (MF) - When LOCK MODE IS AUTOMATIC or LOCK MODE IS MANUAL is specified in the SELECT/ASSIGN statement of a file, the file that is referred to is shareable. More than one run unit can successfully open such a file.

    18. (MF) - A file opened for OUTPUT, and relative and indexed files opened EXTEND, are implicitly defined as files with an exclusive lock, that is, they are not shareable.


    Does this make sense?

    Or shouldn't the behaviour described in 18. rather be reconsidered?

  • In Windows, UNIX, and Linux, opening a file in append mode - which I assume is what EXTEND does - doesn't simply set the writing position to the current end of the file. It guarantees that all writes will be appended to the data in the file.

    If there are multiple append-mode writers to the file, their outputs may be interleaved, but none of the data will be overwritten.

    For Windows, see the semantics of FILE_APPEND_DATA; for UNIX (and Linux, which does not claim conformance but conforms in most respects) see the semantics of O_APPEND in the Single UNIX Specification.

    So in append mode it's not necessary to prohibit sharing, because data will not be lost. When a file is opened in normal writing mode, however, no guarantees can be made regarding overwriting and data loss, nor can consistent reads be guaranteed.

    Now, I've neither checked how EXTEND is implemented nor tested this, so this may not be the reason for the difference in sharing modes. But at the OS level there's a significant difference between opening a file for general writing and opening it for append.

  • Hi Michael,

    thank your for taking the time.

    The implications and differences of update/delete vs. insert are understood. And, of course, default is, and should be, exclusive access.

    However, I don't understand why it's impossible to say: "Yes, I know the implications. And, yes, I know it may be causing issues in production. Yet, I also know what I'm doing, so I'd like to open the file for now with SHARING WITH READ ONLY or SHARING WITH ALL OTHER.

    It would be a great help during debugging to see what the file's contents are.

  • I'm no fan of Windows file-sharing semantics either, and if it were up to me I'd disable the lot of 'em. I was merely pointing out that there's a significant difference between opening a file for arbitrary writes and opening one for append.

    Requests for changes to COBOL file handling would have to be made through the enhancement request process, via Customer Care. I don't have any influence over that aspect of the product.
  • Another difference between OPEN OUTPUT and OPEN EXTEND is that OPEN OUTPUT always creates a new file containing zero records and OPEN EXTEND does not (unless the OPTIONAL phrase is used and the file does not exist).

    I believe that this is why OPEN OUTPUT requires an exclusive lock. If a file currently existed and was being read by a program that had it opened for SHARING WITH ALL OTHERS, this would allow the OPEN OUTPUT to delete the file that was currently opened in this different program.

    When OPEN OUTPUT is issued it must therefore ensure that no other program has the file open before it creates a new file and it does this by obtaining an exclusive lock on the file.


  • Interesting thought.

    Yet, I suspect OPEN OUTPUT to rather truncate an existing file than to delete it. Because otherwise the user would be required to have DELETE rights on a file.

    Actually, I just tested OPEN EXTEND in conjunction with DELETE FILE with no issues at all (see screencast below).

    So, at this time, I don't see an advantage in prohibiting any kind of shared read access using OPEN OUTPUT.

    Micro Focus COBOL - No file sharing on output file - 2.gif


    Having such option would ease debugging a lot. Imagine a long time calculation, creating a large report. You'd be able to eliminate layout mistakes or errors in edited pictures right at the beginning while debugging, instead of having to wait for a report to be fully generated first.