Access to write to file is denied

I have recently supplied a Silverfrost fortran exe to a student as part of his PhD work.

When running the program many thousands of times in a loop (see below)he OCCASIONALLY gets a runtime error - Win32 error detected in IO_open: Access is denied - this happening when an attempt is made to open and write the results file. I can stop this happening by using an err= in the open statement, looping back to try the open again, and I assume it is caused by the time taken to open/close files and wondered if others had experienced this? All on a W7 machine.

Student (Java) program calls fortran program 'SILVER.EXE' SILVER.EXE reads input data, calculates and writes results to file (quite a lot of output)- closes everything Student program reads results file, sets up new input data - closes everything. Student (Java) program calls 'SILVER.EXE' etc etc etc

Many Thanks

Bill

Bill,

I have seen reports of this problem, when re-opening the same file many times. It was claimed to be caused by a delay in releasing the file handling resources (or file unit?) by windows. The solution is to use the iostat= and check the type of error. It could be some other problem, especially security problems for writing. If the error is consistent with your problem, I'd recommend using call sleep1@ (0.1), say for 0.1 seconds to allow the file system to catch up. Count the loops and how many times are you prepared to cycle before you stop ? It's probably best making this a large number, rather than the hastles of restarting the test. It is probably worth reporting the error, when it is finally opened or you exceed the loop count. Are you opening the same file many times or many different files ?

John

Dear John,

Many thanks for your response - and I am dealing with the same file repeatedly - and the likely cause you suggest is exactly what I would guess without fully understanding what happens when files are closed.

When I originally wrote the code I was worried that the problem could occur for the reasons you suggest and I had put a sleep statement in from the start but of course the student complained that the calculations took too long and he needed to do many millions of runs so I removed it. Without err= he occasionally had problems - so the err= solution which does seem to work fine (he says! so far!).

Thanks again

Bill

Bill,

The call to sleep1@ only occurs if there is an error response, so slowness would only occur when the windows system is slow to respond. Are there any ideas on what could cause the problem? Networked files and libraries are a possible cause.

I would be keeping statistics on the number of open calls that occur and the number of opens that have an error state returned, plus some statistics on the distribution of the number of errors before the file is opened.

John