OPEN error inconsistent
in [Fortran]
|
Prev: Random_number
Next: UF file reading by Fortran
From: Louis Krupp on 13 Feb 2010 03:54 SteveF wrote: <snip> > When I remove the transfer on an error, here is the result: > > * forrtl: The process cannot access the file because it is being used by > * another process. > * forrtl: severe (28): CLOSE error, unit 18, file "Unknown" > * This is potentially helpful information, especially if it turns out that the problem is due to another user process using the file. > >> >> 5. I am not sure why you keep opening and closing files. Why not just >> open a >> scratch file and then re-wind it to read? Then re-wind it to write? >> > > In the real-life program these are not scratch files, and the low-level > routine that opens a new file needs to delete the old one first, if it > exists, because the old file may have been used for a completely > different purpose (e.g. Formatted vs. Unformatted). <snip> My understanding is that if you open a file with status='new' then it will delete the old file if it exists, and it won't matter if the old file was formatted or not. But I may be misunderstanding what you're saying. Louis
From: dpb on 13 Feb 2010 11:01 SteveF wrote: .... > When I remove the transfer on an error, here is the result: > > * forrtl: The process cannot access the file because it is being used by > * another process. > * forrtl: severe (28): CLOSE error, unit 18, file "Unknown" > * .... > I'm going to try putting in a one-second delay (as someone suggested) > then try to delete the file again. I suspect there is some kind of > multi-threaded processing going on by the operating system such that > my main program thread cannot delete the file because another thread > is still using it. Is there any kind of FLUSH command to clear out > other processes? .... It's not multi-threading _your_ program unless you are compiling w/ an option to do so. As others noted and I noted earlier in response to your first observation that the boxen on which it fails have been updated by IT, look for what was installed/upgraded thereon that isn't on the others. Antivirus, backup, other system monitoring tools, etc., are the likely culprits. I don't have a specific utility/link but I think there are tools of the "dependency walker" type that can find what process has a file open as well as the static linkage dependencies??? If the sample app actually has the error as well as the the production one it's not this app that is the other process I think is clear. That it's something like the anti-virus or somesuch is likely why it appears intermittent as it does. The kludge of a delay/retry loop probably will work but it's simply a masking of the actual problem. Of course, IT may not be helpful in fixing the real problem ime... But, if you have any control over the boxes to set any conditions on those tools, you could look at trying to disable such scanning on your working directories or files of the extension of your data files, etc., and see if it goes away. --
From: Richard Maine on 13 Feb 2010 11:08 Louis Krupp <lkrupp_nospam(a)indra.com.invalid> wrote: > My understanding is that if you open a file with status='new' then it > will delete the old file if it exists, No. There seem to be multiple misunderstandings posted to his thread. From the standard: "If NEW is specified the file shall not exist." That is, it is a programming error to specify NEW if the file exists. The usual behavior is for that to be an error condition (except for the niggly detail about the standard not specifying error conditions). What you are describing is the behavior of status='replace', which is a very different thing - also a very useful thing for exactly the reason mentioned. The replace option was added in f90. Prior to that, it was nontrivial to handle this kind of issue robustly. The closest one could do was something like what the OPs code does, but that wasn't really what I would call robust; there were multiple ways it could fail to work as intended. In particular, doing a close with status='delete' requires that you first be able to open the old file. There exist operating systems where you have to know things about the file in order to be able to do that. For another example, it would be possible for another process to create a file during the time between the deete and the open. That's a classic "race condition." If you want to program robustly, you avoid counting on things like that. For reasons like this, I was quite pleased to see status='replace' added in f90. It allowed me to change some of my system dependent and non-robust code into standard-conforming, robust code. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Ron Shepard on 13 Feb 2010 11:19 In article <8ytdn.7392$YR1.768(a)newsfe17.iad>, "SteveF" <stevefry(a)dslextreme.com> wrote: > I don't know why you think it is NOT a good idea, for you can > see after 1000 iterations the means and standard deviations were always > exactly equal (because the error message was never printed.) It is possibly an error waiting to happen. There is nothing that guarantees the computed floating point numbers will be the same. You can get slightly different values for a variety of reasons, including rounding modes, compiler optimization levels, whether or not some register is written to memory or used directly, whether a multiply-add sequence is done with a single instruction or as separate operations, whether loop unrolling is enabled, or whether gradual underflow is active or not. In a parallel environment, even the order in which some operations are performed is not the same from run to run. These kinds of things are not necessarily errors, but they might appear so if you expect exact bit-by-bit values to be computed by different processors, different programs, different runs of the same program, or even the same code in two different environments within the same program. $.02 -Ron Shepard
From: Ron Shepard on 13 Feb 2010 13:05
In article <1jdudxw.15hopxm1j6ya9sN%nospam(a)see.signature>, nospam(a)see.signature (Richard Maine) wrote: > > My understanding is that if you open a file with status='new' then it > > will delete the old file if it exists, > > No. There seem to be multiple misunderstandings posted to his thread. > > From the standard: "If NEW is specified the file shall not exist." That > is, it is a programming error to specify NEW if the file exists. The > usual behavior is for that to be an error condition (except for the > niggly detail about the standard not specifying error conditions). If I remember correctly, in f77 on VMS machines, an open with status='new' would create a new file with a new version number even if an old version existed. That is, it would not delete the old version and it would not generate an error condition. An open with status='old' would open an existing file if it existed (or err if it did not). An open with status='unknown' would open the old file if it existed, or open the file with version number 1 if it did not exist. An open with status='new' was the only way to create a new file with a new version number when an old version already existed. I did not use any of the later OpenVMS machines with an f90 compiler, so I don't know if any of this changed by then. From your sentence above, it looks like it did. (Or maybe my memory if off about the details of status='new' in the first place.) $.02 -Ron Shepard |