OPEN error inconsistent
in [Fortran]
|
Prev: Random_number
Next: UF file reading by Fortran
From: e p chandler on 12 Feb 2010 14:22 On Feb 12, 11:25 am, Jugoslav Dujic <jdu...(a)yahoo.com> wrote: > e p chandler wrote: > > >> In debugging I'd take the IOSTAT and ERR= error handling out and let the > >> runtime errors pop up and perhaps be more elucidating in their messages > >> as to what the problem actually is. > > > My follow up message seems to have disappeared, so I'll repeat the > > suggestion to take out the error handling code and let the run-time do > > its job. > >> -- > > > I'm going to be impolite and ask again, What is this program trying to > > do? > > > --- e > > Here's what happened: the last system upgrade installed a new > component. It saw the pointlessness of the program, and > deduced "when the author does not care to make a meaningful > program, why should I bother opening a file for him?". So it > didn't. Wow. So that's what the last service pack for dot NET does! --- e
From: e p chandler on 12 Feb 2010 14:27 On Feb 12, 11:27 am, nos...(a)see.signature (Richard Maine) wrote: > e p chandler <e...(a)juno.com> wrote: > > > Third, I thought that using ERR= and IOSTAT= toghther was not proper. > > I'll repeat (at a little more length) my reply to the other post where > you said this. > > There is certainly no prohibition against this in the standard, and I > can't imagine why there would be such an arbitrary prohibition. Having > both is perfectly sensible and has no potential for conflict. > > I don't happen to personlly like using err= at all, but that is purely a > personal style choice. That choice is not even hinted at by the standard > and doesn't merit a description as "not proper" unless one *HEAVILY* > qualifies that as being according to someone's particular notion of > style. Given that one uses err= to transfer control after an error, it > is quite reasonable that one might also want to inquire about what the > particular error was. > > Heck, if you have a compiler that supports the iomsg= specifier of > f2003, you can have all 3 of err=, iostat=, and iomsg=. THat stil makes > perfectly fine sense and is valid. Thanks. I should have just looked it up. [frown] --- e
From: Brian Watson on 12 Feb 2010 20:41 In article <Oc5dn.25505$aU4.20937(a)newsfe13.iad>, "SteveF" <stevefry(a)dslextreme.com> wrote: > A Fortran program that used to work now gives an error when > opening a file. The error is inconsistent in that it stops > at different times for different runs. This program is run > by many employees at work, on many different PCs, and it only > recently started crashing only on two machines, which have been > upgraded by "IT". I have tried four different compilers, > running in 'debug' mode, and they all produce OPEN errors when > attempting to open a file that has been deleted. > > > Here is the source code: Snip > > Does anybody have any ideas how to keep the program from failing? > Is there some compiler switch or operating system tweak (registry?) > that will allow my Fortran program to open the disk file it needs? > > -- Steve F. If you look carefully at the output, you can see that the error is coming from the CLOSE(STATUS='DELETE'). (There is no 'OPEN NEW FILE' message between the 'DELETE EXISTING FILE' and the 'ERROR OPENING NEW FILE' message.) I have encountered a similar problem before, where trying to delete a scratch file failed seemingly randomly. What I discovered is that Windows will not let a file be deleted if ANY process has the file open. In my case, there was a backup utility running in the background that was occasionally trying to backup a scratch file at the moment I was trying to delete it, causing the CLOSE to fail. Probably a background virus scanner or search indexer could also cause the problem. I suggest you look for some new background utility on the upgraded machines that may be opening your files. -Brian
From: Louis Krupp on 12 Feb 2010 21:04 Brian Watson wrote: > In article <Oc5dn.25505$aU4.20937(a)newsfe13.iad>, > "SteveF" <stevefry(a)dslextreme.com> wrote: > >> A Fortran program that used to work now gives an error when >> opening a file. The error is inconsistent in that it stops >> at different times for different runs. This program is run >> by many employees at work, on many different PCs, and it only >> recently started crashing only on two machines, which have been >> upgraded by "IT". I have tried four different compilers, >> running in 'debug' mode, and they all produce OPEN errors when >> attempting to open a file that has been deleted. >> >> >> Here is the source code: > Snip >> Does anybody have any ideas how to keep the program from failing? >> Is there some compiler switch or operating system tweak (registry?) >> that will allow my Fortran program to open the disk file it needs? >> >> -- Steve F. > > If you look carefully at the output, you can see that the error is > coming from the CLOSE(STATUS='DELETE'). (There is no > 'OPEN NEW FILE' message between the 'DELETE EXISTING FILE' and > the 'ERROR OPENING NEW FILE' message.) > > I have encountered a similar problem before, where trying to delete > a scratch file failed seemingly randomly. What I discovered is that > Windows will not let a file be deleted if ANY process has the file open. > In my case, there was a backup utility running in the background that > was occasionally trying to backup a scratch file at the moment I > was trying to delete it, causing the CLOSE to fail. > Probably a background virus scanner or search indexer could also > cause the problem. > > I suggest you look for some new background utility on the upgraded > machines that may be opening your files. Good catch. I didn't notice that it wasn't getting as far as the open. A one-second delay *before* the CLOSE(DELETE) would rule out a self-contained timing problem. Louis
From: SteveF on 13 Feb 2010 03:39
"e p chandler" writes: > > Is this a benchmark or a compiler test? It's just a compiler test to isolate the problem that is occurring in a much larger, more complex program. > > 2. You are using the same error trap for TWO different conditions. So your > error messages may not mean what you think they mean. Yes, both the OPEN and the CLOSE transfer to 50 on an error, but you can see from the output that it must be the CLOSE statement where the error is happening because it fails before printing "OPEN NEW FILE". > > 3. Why bother trapping these errors at all? If the program is going to halt > anyway, why not let the runtime system print its own message instead of > generating one yourself. It MIGHT be more informative. In the real-life program, I don't want the program to crash on the user. I want to be able to trap the condition and continue running. 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" * > > 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). > > Third, I thought that using ERR= and IOSTAT= toghther was not proper. > How else are you to process the error? The ERR=50 lets you go to 50 to process the error instead of crashing, and the IOSTAT=K lets you test the value of "K" to see what the error is. > > Last, enen though I expect the means and RMS value to be the same from > the original data and the re-read data, it's generally NOT a good idea > to compare floating point values for exact equality. Unless the > standard mandates such behavior here. If it does, I owe Richard Maine > a beer which he can collect upon visiting my home town! > Well, for me the program is just supposed to crunch some numbers and save them in an unformatted file, then try to delete the file before doing it again 1000 times. But for you, the program is trying to generate many random numbers and compare the mean and stdev from the floating point values in memory versus when they have been written to a disk file and read back into memory. 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.) 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? -- Steve F. |