Argument order in open statement

[maartenb]

We have a Fortran program that opens many files for reading and writing. Some of the latter are temporary and deleted at a later stage (NB these are opened with status 'new', not 'scratch').

We ran into an issue when running multiple concurrent instances, which all read from the same input file (i.e. opened with status 'old'). Sometimes this input file would somehow be deleted, even though there's no statement in the code for this.

We suspected there was a mixup with unit numbers: a statement intended to delete a temporary file would actually result in deletion of the input file. Upon further investigation we found that the statement for opening the input file that is deleted differs from that for other (input/output) files. Specifically, the order of the 'iostat' and 'status' arguments differs. The input file that is deleted is opened with:

open(<unitnumber>,file=<filename>,status=<status>,iostat=<iosvar>)

while all other files are opened as:

open(<unitnumber>,file=<filename>,iostat=<iosvar>,status=<status>)

Changing the open statement for the input file to the second format (i.e. 'iostat' first) seems to resolve the issue (it's difficult to reproduce the error).

I checked the language reference for the open statement. The specified syntax of open is:

OPEN([UNIT=]io-unit[,FILE=name] [,ERR=label] [,IOMSG=msg-var] [,IOSTAT=i-var],slist)
Where:
slist Is one or more of the following OPEN specifiers in the form specifier = value or specifier (each specifier can appear only once)

This includes 'status'. This suggests that 'status' should come after 'iostat' and the statement for the input file is wrong. However further down (under 'Description') it is written:

The control specifiers ([UNIT=] io-unit, ERR= label, and IOSTAT= i-var) and OPEN specifiers can appear anywhere within the parentheses following OPEN.

This suggests that the order does not matter.

Is it correct that the argument order for open is important? Can this explain our issue?

[mecej4]

Only the specifier keyword UNIT= is optional. If it is left out, the unit number must be the first argument. The remaining specifiers may appear in any order, and the keywords are required.

I suspect that you are opening the same file for reading in one process and for writing in another process, without exerting control and synchronization on the I/O by the use of the SHARE and other applicable arguments available for such control. 

Please do not make up rules (such as "IOSTAT first...") based on observations of the behavior of a faulty program.

[maartenb]

Thanks for your reply.

---

@mecej4 wrote:

I suspect that you are opening the same file for reading in one process and for writing in another process, without exerting control and synchronization on the I/O by the use of the SHARE and other applicable arguments available for such control. 

---

This is unlikely since the concerning file is only opened for reading; never for writing. Unless (as I wrote before) there's a mixup with the unit numbers.

---

Please do not make up rules (such as "IOSTAT first...") based on observations of the behavior of a faulty program.

---

I don't think I was "making up rules". I was merely inquiring as to the usage of open. It's very well possible that there's an error in our program. Nevertheless, it's very strange that our issue is (apparently) resolved simply by changing the order of the arguments of the open statement.

[Arjen_Markus]

Well, you did indicate that it is difficult to reproduce the error, so the behaviour may be coincidental anyway. As for "making up rules", @mecej4 means that it is too easy to deduce "rules" like that and then let them live on.

[maartenb]

Thanks Arjen Markus. I also think that it would be quite strange if the argument order would matter. Hence my post. We'll keep investigating. If we find the cause or can come up with an MWE, I'll post it here.

[jimdempseyatthecove]

Are your unit numbers hard wired? (literal or parameter)

Or variable? (perhaps using newunit)

Notes: There were(are) issues with using newunit and large numbers of file opens. 

Changing the order of iostat= and status= should not have affected the outcome.

N.B. Your open statement sketches do not state if the file is shared or not. On Linux 'OLD' defaults to shared, on Windows it defaults to not shared.

Suggestion: After creating the shared input file, set the attributes of the file to read-only (deny delete/modify). After this, run the problematic program (multi-instance such that to expect the error) and see if/where the program errors out. Hopefully this is in a different location from file not found.

Jim Dempsey

[maartenb]

---

@jimdempseyatthecove wrote:

Are your unit numbers hard wired? (literal or parameter)

Or variable? (perhaps using newunit)

---

We use a function to determine a free unit number based on inquire(..., opened=...); so not newunit.

---

N.B. Your open statement sketches do not state if the file is shared or not. On Linux 'OLD' defaults to shared, on Windows it defaults to not shared.

---

We're on Windows but we haven't been using the shared specifier. I guess we should fix that; even though we haven't had problems mostly. Aside from the file being deleted every now and then, of course, but it seems unlikely to me that this could be related, right?

---

Suggestion: After creating the shared input file, set the attributes of the file to read-only (deny delete/modify). After this, run the problematic program (multi-instance such that to expect the error) and see if/where the program errors out. Hopefully this is in a different location from file not found.

That's a great suggestion, thanks!

[andrew_4619]

You don't show ACTION= if read only is desired ACTION='READ' would be a good idea as this "Indicates that only READ statements can refer to this connection."

[jimdempseyatthecove]

Good point Andrew however ACTION='READ' may not inhibit a CLOSE with STATUS='DELETE'

Suggest using OPEN with READONLY instead (which is similar to ACTION='READ' but in addition inhibits deletion).

Jim Dempsey

[maartenb]

---

@jimdempseyatthecove wrote:

Suggest using OPEN with READONLY instead (which is similar to ACTION='READ' but in addition inhibits deletion).

Yes, I'll try that (together with changing the file attribute), thanks!

[Barbara_P_Intel]

@maartenb  What version of the Intel compiler are you using?  

[maartenb]

---

@Barbara_P_Intel wrote:

@maartenb  What version of the Intel compiler are you using?  

---

Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on IA-32, Version 19.0.3.203 Build 20190206

After speaking with a colleague I can now add that the problem is reproducible; i.e. it always occurs in a specific configuration, unless the argument order in the open statement is changed. I hope to come up with minimal example soon.

[Barbara_P_Intel]

Can you try the current compiler release? ifort 2021.5.0 is part of oneAPI 2022.1.  I remember filing a bug or two for developers with similar symptoms that have been fixed.