Help with severe (9): permission to access file denied error

[João_A_]

0 down vote favorite

I doing a job using Simulia Abaqus finite element software with a user subroutine done in fortran (.for file).

The computer I'm working has Intel Visual Fortran 11 and VS2010 installed as prerequisites to run Abaqus with user subroutines.

To be able to take advantage of the parallel processing of the CPU I'm using I had to use temporary .txt files to write/read the values of some variables during the analysis.

Unfortunately I'm come up with an annoying error related to the OPEN/READ/WRITE statements I have in .for file of the user subroutine I'm using.

The error is the following:

forrtl: severe (9): permission to access file denied, unit 900, file C:\Abaqus_JOBS\mEFT.txt

The error occurs with other units as well and at random runtimes. So the error can occur in the beginning of the analysis or at a later stage although without accomplishing to finish the analysis.

Based on crude debugging of the .for file (asking to write text to a results file before and after certain statements) I'm able to relate the error with a OPEN statement when I try to open and simultaneously create the file C:\Abaqus_JOBS\mEFT.txt:

OPEN(900, FILE = "C:/Abaqus_JOBS/mEFT.txt", action = "READWRITE", status = "UNKNOWN")

The error occurs and the file is not created. When the error occurs the file has already been created and deleted at least two (sometimes 100) times.

I've debugged the error more thouroughly by step by step method in one analysis and in this ocasion it seems that after the first time some data is written into C:\Abaqus_JOBS\mEFT.txt I get the severe (9) error.

The file is created and the data is well written. It is when the program is called once again (Abaqus uses an incremental solver, so the .for file is called multiple times during runtime) that the error occurs.

In VS2010 when the error occurs I get a Disassembly, saying

No source available. No symbols are loaded for any call stack frame. The source code cannot be displayed

The call stack location is

ABQSMAStaCore.dll!00000001804a2e60()

When I ask VS to Show Disassembly another tab opens with lots of lines and data. The line to which a pointer is activated reads:

00000001804a2e5e 85 C0 test eax,eax.

Any ideas about the origin of the error and ways to solve it? Thanks

Some lines of code:

      SUBROUTINE del_file(uFile, stat, flag)
C
      IMPLICIT NONE
      INTEGER uFile, stat, flag

      IF (stat.NE.0 .OR. flag.EQ.1) THEN
C If the unit is not open, stat will be non-zero
        CLOSE(unit=uFile, status='delete', iostat=stat)
      ELSE
        CLOSE(unit=uFile, iostat=stat)
      ENDIF
C
      END SUBROUTINE

    OPEN(700, FILE = "C:/Abaqus_JOBS/mELF.txt",  
   1 action = "READWRITE", status = "UNKNOWN")
      OPEN(800, FILE = "C:/Abaqus_JOBS/mELFT.txt",  
   1 action = "READWRITE", status = "UNKNOWN")
      OPEN(900, FILE = "C:/Abaqus_JOBS/mEFT.txt",  
   1 action = "READWRITE", status = "UNKNOWN")

C
      READ(700, *, iostat=stat) mELF
      CALL del_file(700, stat, flag)
      READ(800, *, iostat=stat) mELFT
      CALL del_file(800, stat, flag)
      READ(900, *, iostat=stat) mEFT
      CALL del_file(900, stat, flag)

C do some stuff

    OPEN(700, FILE = "C:/Abaqus_JOBS/mELF.txt",
   1 action = "READWRITE", status = "UNKNOWN")
      OPEN(800, FILE = "C:/Abaqus_JOBS/mELFT.txt",
   1 action = "READWRITE", status = "UNKNOWN")
      OPEN(900, FILE = "C:/Abaqus_JOBS/mEFT.txt",
   1 action = "READWRITE", status = "UNKNOWN")
C
      DO I = 1,cLines
        WRITE(700,*) mELF(I)
        WRITE(800,*) mELFT(I)
        WRITE(900,*) mEFT(I)
      END DO
C
      CLOSE(700)
      CLOSE(800)
      CLOSE(900)

[Steven_L_Intel1]

The disassembly isn't interesting. The error is fairly simple - you've asked to open a file for writing which Windows is forbidding you to do. If this file is already open somewhere else, your trying to open it for write access is likely to fail. One thing I keep seeing on Window systems is that a CLOSE of a file doesn't completely close it until "some time later", even though Windows returned from the system routine used to close the file. In general, applications which try to open and close the same file many times often run into a problem like this. You could try adding a call to SLEEPQQ(500) to sleep for half a second before doing the open - that is often enough time to let the close finish.

[João_A_]

Hi Steve and thanks for your reply!

I've read in another post (http://software.intel.com/en-us/forums/topic/288511) that the a possible solution is to rename the file before closing it or deleting it.

Is there a direct way to rename a file in fortran? Thanks!

[Steven_L_Intel1]

Not in the Fortran language. We provide a RENAMEFILEQQ library routine that will do it.

[João_A_]

Ok! Thanks

[andrew_4619 · Accepted solution]

I always use the IOSTAT option in file open then if the return value is non-zero you have trapped the error and can do something better than crashing, e.g.  SLEEPQQ(500) and then try again (assuming the file is temporaraly locked)

[João_A_]

@app4619: Best answer. Somehow adding IOSTAT and a IF loop next to the OPEN did the trick...... strange but it works!