OPEN error inconsistent
in [Fortran]
|
Prev: Random_number
Next: UF file reading by Fortran
From: Richard Maine on 22 Feb 2010 19:19 Richard Maine <nospam(a)see.signature> wrote: > 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. Back now. (Mother-in-law had a run-in with a slick door-to-door salesman who pressed her into signing her up for a 3 year alarm system contract that she didn't need or really want. I needed to go over there to make sure it got cancelled before they came over and actually installed the system, which they were going to do just an hour later). In f77, 12.6, "Error and end-of-file conditions," last para "If an error condition occurs during execution of an input/output statement that contains neither an input/output status specifier (12.7) nor an error specifier (12.7.1), or an end-of-file condition occurs..., execution of the executable program is terminated." Note the "neither...nor". That is, having either one of them is sufficient to prevent this behavior. Admitedly, a vendor who was intent on finding excuses instead of on fixing their product might argue that this just says what happens when you don't have either one, but it doesn't explicitly cover the other cases, so the vendor could do whatever they wanted. That's a pretty bogus argument, though; see above comment about poor support. The intent is pretty clear. Without this condition, there isn't much justification for why the vendor could choose to terminate the program. One could just as well say that the standard doesn't explicitly say that execution doesn't terminate after the execution of any assignment statement. More recent versions of the standard are bulked up with what seem like redundancies to me probably to avoid bogus arguments like that. There are a lot of places where it says something like "If x, then y happens; otherwise it doesn't." To me, the "otherwise it doesn't" is largely redundant, but I suppose it keeps the bogus arguments down. If the vendor really wanted to find an excuse to get out of fixing their compiler, they missed the big ones in I/O. The legalistically defensible arguments for almost any I/O behavior a vendor wants are 1. The standard doesn't define what constitutes an error condition. The vendor can claim that whatever happened does not count as an error condition, but instead as an erroneous program, so the vendor can do anything. The distinction between an error condition and an erroneous program is subtle, but important. Once you say something is an error condition in Fortran, the standard says what has to happen. But an erroneous program could do anything. That is mostly to cover things that the compiler realistically can't handle "cleanly," but since the specifics are left to the vendor, it is potentially abusable. 2. The even "bigger hammer" is that it is vendor dependent what I/O is supported. It can be standard conforming to build a Fortran compiler that can't actually do any I/O; such things have even existed. I think that to be strictly legal, the compiler has to be able to handle the syntax enough to compile sucessfully, but not necessarily to be able to actually execute any I/O statements at all. A sufficiently perverse vendor could claim that they don't support any Fortran I/O and that any program that tried to execute any I/O statement was therefore erroneous. The claim would be that those things that look and act almost like the standard Fortran I/O statements are actually extensions to go with their compiler that doesn't support Fortran I/O. If the vendor really wanted to drag out the high-paid lawyers, they might be able to make arguments like the above stick. Doesn't seem like it is very compatible with a business model that includes convincing customers to buy your product, though. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Colin Watters on 23 Feb 2010 02:23 "Richard Maine" <nospam(a)see.signature> wrote in message news:1jeblts.1fymibm1cqutmoN%nospam(a)see.signature... > Richard Maine <nospam(a)see.signature> wrote: <...> > In f77, 12.6, "Error and end-of-file conditions," last para > > "If an error condition occurs during execution of an input/output > statement that contains neither an input/output status specifier > (12.7) nor an error specifier (12.7.1), or an end-of-file condition > occurs..., execution of the executable program is terminated." > > Note the "neither...nor". That is, having either one of them is > sufficient to prevent this behavior. > > Admitedly, a vendor who was intent on finding excuses instead of on > fixing their product might argue that this just says what happens when > you don't have either one, but it doesn't explicitly cover the other > cases, so the vendor could do whatever they wanted. ....Exactly what the support lady said. > That's a pretty bogus argument, though; see above comment about > poor support. The intent is pretty clear. ....Yes that was my view as well, but not the vendor's. I had a long argument about what purpose was served by allowing an IOSTAT= to set a value in a variable, if the program didn't get to actually look at its value whan that value might be of some use. > > Without this condition, there isn't much justification for why the > vendor could choose to terminate the program. One could just as well say > that the standard doesn't explicitly say that execution doesn't > terminate after the execution of any assignment statement. More recent > versions of the standard are bulked up with what seem like redundancies > to me probably to avoid bogus arguments like that. There are a lot of > places where it says something like "If x, then y happens; otherwise it > doesn't." To me, the "otherwise it doesn't" is largely redundant, but I > suppose it keeps the bogus arguments down. ....yes, the lack of something like this caused my problem, and IMO amply justifies its liberal use in later standards. -- Qolin Email: my qname at domain dot com Domain: qomputing
From: David Thompson on 23 Feb 2010 03:58
On Sat, 13 Feb 2010 10:01:03 -0600, dpb <none(a)non.net> wrote: > 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. > Right. And the errormsg says _process_. Process .NE. thread. > 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 agree those are likely; another would be 'file protection' aka undelete aka restore utilities. And Windows' 'Indexing' utility. > 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??? > I wouldn't call it quite the same type, but www.SysInternals.org (now actually part of M$) has ProcessExplorer (which I like a lot) which can display open files/handles for a process, and search for them (across *all* processes) quite easily. However if the conflicting open is only brief you might miss it. According to the website they also have (fairly new) ProcessMonitor, which I haven't tried but from the description looks like it logs and thus would catch even a transient. > 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. |