OPEN error inconsistent
in [Fortran]
|
Prev: Random_number
Next: UF file reading by Fortran
From: e p chandler on 12 Feb 2010 10:52 On Feb 12, 10:23 am, dpb <n...(a)non.net> wrote: > SteveF 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. > > Clues here are > > 1) "...started crashing only on two machines, which have been upgraded > by "IT"." > > 2) "...all produce OPEN errors when attempting to open a file that has > been deleted." > > ... > > > Now, when compiled with Intel Visual Fortran, Version 11, here is the > > beginning and ending part of the output: > > ... > > > DELETE EXISTING FILE > > ERROR OPENING NEW FILE. CODE= 28 > > > C ********************************************************************** > > > Here is the output from the executable made with the Compaq Visual > > Fortran compiler: > > ... > > > ITER NO. 578 AVG,RMS= 0.499086233E+00 0.288576170E+00 > > DELETE EXISTING FILE > > ERROR OPENING NEW FILE. CODE= 28 > > ... > > > 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. > > I've not downloaded the IVF compiler but have CVF and error 28 is > associated w/ OPEN statement in it so would presume there's a good > chance is with IVF as well. > > 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. Second, both subroutines use the same ERR= line for TWO different conditions. Both print the SAME message. So I'm not certain if it's the DELETE or the OPEN that is at fault. I don't know why the OP wants to delete the data file, if it exists. IMO over-writing it should be good enough. I'm even more uncertain why the OP wants to write the data to a file at all since it is read right back in to where it came from. Third, I thought that using ERR= and IOSTAT= toghther was not proper. 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! -- e > > But, given the above statement in 2) above, why are you trying to OPEN a > deleted file anyway? That seems to me to relate back to the root cause > that there's an OS interaction that wasn't obvious before but now shows > up. That it's variable in when it occurs makes the suggestion of timing > reasonable that internal resources haven't been freed by the time the > code is trying to reuse a name or some similar collision or starvation > problem. > > What if you made a new sequential name per iteration instead; does it > still abort? > > I also echo the sentiment it is not really a Fortran problem but related > to the OS and the use of resources and timing. I suspect there's a good > possibility if wrote the same logic in C could find/create the same problem. > > Since it's a Windows platform, perhaps a search of MSDN for problems w/ > repeated use of name for files causes a crash might uncover workarounds; > would seem unlikely you're the only person to have ever had the issue > despite the somewhat unusual code structure. > > -- I'm going to be impolite and ask again, What is this program trying to do? --- e
From: Richard Maine on 12 Feb 2010 11:20 e p chandler <epc8(a)juno.com> wrote: > 1. You have an ERR= and an IOSTAT= in the same statement. I thought that if > you use one, the other is meaningless. Not so, nor can I see any reason why it would be so. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Jugoslav Dujic on 12 Feb 2010 11:25 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. On a similar topic, see also the Sartre programming language: http://catseye.tc/projects/sartre/doc/sartre.html -- Jugoslav www.xeffort.com Please reply to the newsgroup. You can find my real e-mail on my home page above.
From: Richard Maine on 12 Feb 2010 11:27 e p chandler <epc8(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. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: James on 12 Feb 2010 13:13
I've had similar problems after an "IT upgrade". In my case, the program was periodically opening a log file, and would eventually fail because some other process had the file tied up. I eventually tracked the problem down to the virus scanning utility. The company had just switched brands. The program worked ok with the old software, but starting failing right after the new software was installed. The program would run just fine so long as I kept the machine busy doing other things while the problematic program was running. If I left for lunch, or to attend a meeting, the program would fail while I was gone. After some careful observation, I determined that the failure occurred as soon as the screen saver kicked in. Apparently the anti-virus software took this as an oportunity to look a little deeper into things, and was tying up the log file right at the time I needed to open it. The simplest cure is to have the directory where the program runs excluded from scanning. The fact that anti virus software programs provide an "exclude from scanning" feature suggests that this is a reasonably common problem. |