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.

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.

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):
CreateFileW(L"FileName", GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, ...);

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:

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.

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.