OPEN error inconsistent
in [Fortran]
|
Prev: Random_number
Next: UF file reading by Fortran
From: glen herrmannsfeldt on 12 Feb 2010 04:59 Phred Phungus <Phred(a)example.invalid> wrote: (snip) > It's fixed form. MM has a source converter that might help. > Others might contend that the problem is not that it's fixed form, > because that used to be good fortran. I would contend to the contrary, > claiming that if MM's source converter doesn't work, then the source > needs to be re-written to be minimally legible and embracing the last 2 > decades of improvements. Fixed form is still legal in Fortran 2003, and I believe also in Fortran 2008. No guarantees about Fortran 3000 or 4000, though. > I think the professor on Gilligan's Island could fix the open problems > with his coconut phone. So many things that you could make with coconuts. -- glen
From: robin on 12 Feb 2010 08:51 "SteveF" <stevefry(a)dslextreme.com> wrote in message news:Oc5dn.25505$aU4.20937(a)newsfe13.iad... | | 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. Have you checked out what the error codes signify? What did you find?
From: dpb on 12 Feb 2010 10:23 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. 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. --
From: e p chandler on 12 Feb 2010 04:02 "SteveF" <stevefry(a)dslextreme.com> wrote in message news:Oc5dn.25505$aU4.20937(a)newsfe13.iad... > > 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: > > C ********************************************************************** > PROGRAM TSTFILE > IMPLICIT REAL*8(A-H,O-Z) > C > PARAMETER (N= 200) > DIMENSION A(N,N) > C > UMB=DFLOAT(N*N) > M=0 > X=.87654321D0 > 5 Y=0.D0 > Z=0.D0 > DO 11 I=1,N > DO 10 J=1,N > X=X*997.D0 > X=X-DINT(X) > A(I,J)=X > Y=Y+X > Z=Z+X*X > 10 CONTINUE > 11 CONTINUE > AVG=Y/UMB > RMS=DSQRT(Z/UMB-AVG*AVG) > M=M+1 > WRITE(6,12)M,AVG,RMS > 12 FORMAT(/' ITER NO.',I9,' AVG,RMS=',2E18.9) > CALL OPENEW(18) > WRITE(18)N > DO 15 J=1,N > WRITE(18)(A(I,J),I=1,N) > 15 CONTINUE > CLOSE(18) > CALL OPEOLD(18) > READ(18)I > IF (I.NE.N) STOP 'ERROR ABORT' > DO 18 J=1,N > READ(18)(A(I,J),I=1,N) > 18 CONTINUE > CLOSE(18) > Y=0.D0 > Z=0.D0 > DO 21 I=1,N > DO 20 J=1,N > X=A(I,J) > Y=Y+X > Z=Z+X*X > 20 CONTINUE > 21 CONTINUE > AV1=Y/UMB > RM1=DSQRT(Z/UMB-AVG*AVG) > WRITE(6,22)AV1,RM1 > 22 FORMAT(' AFTER READING DATA AVG,RMS=',2E18.9) > IF (AV1.NE.AVG .OR. RM1.NE.RMS) > * WRITE(6,23)DABS(AVG-AV1),DABS(RMS-RM1) > 23 FORMAT(' ERROR: DIFFERENCES =',2E18.9) > X=A(N/2,N/2) > IF (M.LT.1000) GO TO 5 > C > STOP > END > C > C > SUBROUTINE OPENEW(IUNIT) > C > LOGICAL FXIST > CHARACTER*8 FNAM > C > DATA FNAM/'FORT.018'/ > C > 1 INQUIRE(FILE=FNAM,EXIST=FXIST) > IF (FXIST) THEN > WRITE(6,'('' DELETE EXISTING FILE'')') > OPEN(IUNIT,FILE=FNAM,FORM='UNFORMATTED',STATUS='OLD', > * ACCESS='SEQUENTIAL') > CLOSE(IUNIT,STATUS='DELETE',ERR=50,IOSTAT=K) > GO TO 1 > END IF > WRITE(6,'('' OPEN NEW FILE'')') > OPEN(IUNIT,FILE=FNAM,FORM='UNFORMATTED',STATUS='NEW', > * ACCESS='SEQUENTIAL',ERR=50,IOSTAT=K) > RETURN > C > 50 WRITE(6,51)K > 51 FORMAT(' ERROR OPENING NEW FILE. CODE=',I6) > STOP > C > END > C > C > SUBROUTINE OPEOLD(IUNIT) > C > LOGICAL FXIST > CHARACTER*8 FNAM > C > DATA FNAM/'FORT.018'/ > C > INQUIRE(UNIT=IUNIT,OPENED=FXIST) > IF (FXIST) THEN > K=-5 > GO TO 50 > END IF > INQUIRE(FILE=FNAM,EXIST=FXIST) > IF (.NOT.FXIST) THEN > K=-10 > GO TO 50 > END IF > OPEN(IUNIT,FILE=FNAM,FORM='UNFORMATTED',STATUS='OLD', > * ACCESS='SEQUENTIAL',ERR=50,IOSTAT=K) > RETURN > C > 50 WRITE(6,51)K > 51 FORMAT(' ERROR OPENING OLD FILE. CODE=',I6) > STOP > C > END > C ********************************************************************** > > This program is just a big loop that iterates for 1000 times, opening > and closing the same unit number and same file name at each iteration. > When this program is run on almost any PC, Here is the beginning and > ending portion of the output: > > C ********************************************************************** > > ITER NO. 1 AVG,RMS= 0.500417743E+00 0.289480862E+00 > OPEN NEW FILE > AFTER READING DATA AVG,RMS= 0.500417743E+00 0.289480862E+00 > > ITER NO. 2 AVG,RMS= 0.496925439E+00 0.289664551E+00 > DELETE EXISTING FILE > OPEN NEW FILE > AFTER READING DATA AVG,RMS= 0.496925439E+00 0.289664551E+00 > . > . > . > ITER NO. 999 AVG,RMS= 0.500234166E+00 0.289335165E+00 > DELETE EXISTING FILE > OPEN NEW FILE > AFTER READING DATA AVG,RMS= 0.500234166E+00 0.289335165E+00 > > ITER NO. 1000 AVG,RMS= 0.496594096E+00 0.288361712E+00 > DELETE EXISTING FILE > OPEN NEW FILE > AFTER READING DATA AVG,RMS= 0.496594096E+00 0.288361712E+00 > > C ********************************************************************** > > Now, when compiled with Intel Visual Fortran, Version 11, here is the > beginning and ending part of the output: > > C ********************************************************************** > > ITER NO. 1 AVG,RMS= 0.500417743E+00 0.289480862E+00 > OPEN NEW FILE > AFTER READING DATA AVG,RMS= 0.500417743E+00 0.289480862E+00 > . > . > . > ITER NO. 281 AVG,RMS= 0.501976899E+00 0.287597412E+00 > DELETE EXISTING FILE > OPEN NEW FILE > AFTER READING DATA AVG,RMS= 0.501976899E+00 0.287597412E+00 > > ITER NO. 282 AVG,RMS= 0.501186971E+00 0.287591033E+00 > DELETE EXISTING FILE > ERROR OPENING NEW FILE. CODE= 28 > [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. I wish I understood the actual purpose of this program. It generates some data, computes a mean and s.d., writes the data out to a file, re-reads the same data, computes a mean and s.d. from the newly read data, then compares to old and new statistics. After updating the "seed value", it repeats until it has run 1000 times. Is this a benchmark or a compiler test? Several problems come to mind. I don't think the fixed source form, the non-standard REAL*8 and the implicit double precision cause your problem. 1. You have an ERR= and an IOSTAT= in the same statement. I thought that if you use one, the other is meaningless. 2. You are using the same error trap for TWO different conditions. So your error messages may not mean what you think they mean. 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. 4. You are comparing two different floating point numbers for exact equality. It is possible that re-computing the mean and s.d. from the checkpointed data may not give the same results as on the original data. I do not think that the language standard requires that they be the same. 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? 6. Again, I fail to see what the point of this program actually is. --- e
From: user1 on 12 Feb 2010 10:47
e p chandler wrote: > [snip] > FWIW, your program runs to completion on 32 bit Vista using the most > recent MinGW ports of both gfortran and g95. That, of course, does not > prove that the program is properly written. > > Time to read a printed copy of the source listing .... again. > > ---- e It also ran to a normal finish for me on 32 bit Vista when compiled with OpenWatcom F77. OP says Watcom F77 did not work for him. The problem seems something other than a Fortran problem. OP also mentioned recent upgrades to two machines by IT people. Shudder. I wonder what they did ? |