OPEN error inconsistent
in [Fortran]
|
Prev: Random_number
Next: UF file reading by Fortran
From: dpb on 14 Feb 2010 10:58 dpb wrote: > dpb wrote: > ... > >> ... 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. >> > ... > > Oh, these files aren't on a network share or somesuch mayhaps??? One other stray thought....possible somebody is looking at these files w/ an editor or viewing tool or is some other application building files for this app independently that could be the interfering app? Especially if there's somebody elsewhere on the network and these are shares got me thinking....??? Or, I don't suppose there's any possibility somebody started another copy of the app running in the background that you're competing with??? So many choices... :) --
From: robin on 15 Feb 2010 03:26 "SteveF" <stevefry(a)dslextreme.com> wrote in message news:8ytdn.7392$YR1.768(a)newsfe17.iad... | "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" Sounds like there's a background program running that is accessing that file. Could it be some automatic save?
From: e p chandler on 17 Feb 2010 15:58 On Feb 13, 3:39 am, "SteveF" <steve...(a)dslextreme.com> wrote: > "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. [snip] > 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. > OK. I get it. The reading and writing are just "filler" processes that do something and waste some time. The problem is why are you having trouble deleting the file after it is written?? That sounds more like some type of system problem - file contention between processes than a Fortran program. I do remember some old DOS programs which when migrated to XP left the files "in-use" as far as the OS was concerned even after those files were "closed", as far as the program was concernet. After exiting the program, I would still see (temp) files in the directory from the command prompt. Of course if you really are writing a program whose objective is to write data to a file, then re-read it, and then repeat the process a large number of times, the program below shows that it can re-write the output file without deleting it. ---- start text ---- do i=1,1000 open(18,file='foo.dat',form='unformatted') write(18) i close(18) open(18,file='foo.dat',form='unformatted') read(18) j if (j /= i) then write(*,*) i,j end if close(18) end do end ---- end text ---- ----- e
From: Colin Watters on 22 Feb 2010 15:37 "e p chandler" <epc8(a)juno.com> wrote in message news:189a0210-cf5b-4ba1-a18a-178db1bb0150(a)d37g2000yqa.googlegroups.com... 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. <...> > Thanks. I should have just looked it up. [frown] I once had the misfortune to cause my employer to buy a compiler that would only allow a non-zero IOSTAT= to be returned if the I/O statement in question ALSO contained an ERR= clause. If you supplied an IOSTAT= without ERR=, the result was a hard failure, essentially identical to that obtained if you had nither ERR= or IOSTAT=. I was almost apoplectic when I discovered this, and had a caustic conversation with the vendor's support staff wherein I was challenged to quote the part of the standard (alas, F77) that required IOSTAT= without ERR= to let execution continue. Alas I could not find it, despite several hours looking. Luckily that system was soon outdated and it hit the junk pile. -- Qolin Email: my qname at domain dot com Domain: qomputing --- e
From: Richard Maine on 22 Feb 2010 16:14
Colin Watters <boss(a)qomputing.com> wrote: > I was almost apoplectic when I > discovered this, and had a caustic conversation with the vendor's support > staff wherein I was challenged to quote the part of the standard (alas, > F77) that required IOSTAT= without ERR= to let execution continue. Alas I > could not find it, despite several hours looking. Luckily that system was > soon outdated and it hit the junk pile. I can. Pretty quickly in f90, and probably in f77 as well. But it sounds like past history now. Have to run at the moment. No time. Also sounds like darn poor vendor support. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |