- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have the following line of Fortran code early in my app:
OPEN(UNIT = FILDBGNUM, FILE = FILDBG, STATUS = 'REPLACE')
All arguments are appropriate. I am getting the error forrtl: severe (602): file not found.
Wait a second. The STATUS = 'REPLACE'. How could that error be generated?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some things to check:
- Does the run time error occur show the line number when it occurs, and is that the line number of the OPEN statement that you showed?
- Do you have other OPEN statements in your program?
- Do you have write permission for the directory in which the OPEN statement may attempt to create a new/replacement file?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Question 1: Yes.
Question 2: Yes.
Question 3: Yes.
The OPEN statement is the first one encountered in the executable. This app is QuickWin and the OPEN is coming as part of command-line processing. Here is its routine:
SUBROUTINE OPEN_DEBUG_FILE() INTEGER DOT_POS DOT_POS = SCAN(FILIN, '.', BACK = .TRUE.) FILDBG = FILIN(1:DOT_POS) // 'dbg' OPEN(UNIT = FILDBGNUM, FILE = FILDBG, STATUS = 'REPLACE') END SUBROUTINE OPEN_DEBUG_FILE
FILIN is input as part of the command line. FILIN (CHARACTER string), FILDBG (CHARACTER string) and FILDBGNUM (INTEGER) are MODULE level variables. When the code is run in the VS debugger, the error occurs which is "OKed" and then the cursor is left on the OPEN statement with the claim of an Exception.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please show the complete error message as displayed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have you checked the file name that is created by this code? It might result in an invalid name.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would like to respond to this request, but I would also like to protect myself from public viewing of the code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I take the opportunity of this thread about OPEN to add the following case/error experienced some weeks ago:
============================================================================
*** Process Simulation Program ***
INPUT LISTING P. 1
* NO DIAGNOSTICS GENERATED *
* PROCESS SIMULATION
'TAP STAFF WATER FLOW '
IS EXECUTING *
* INPUT PRINTOUT *
GENERAL DATA P. 5
ACTIVE COMPONENTS P. 6
CHEM/PHYS CALCULATION METHODS P. 7
STREAM 'S1 ' DATA P. 12
UNIT OPERATION 1 - 'V1 ' P. 12
UNIT OPERATION 2 - 'PL1 ' P. 13
UNIT OPERATION 3 - 'F1 ' P. 19
STREAM 'INAIR ' DATA P. 19
UNIT OPERATION 4 - 'PSD1 ' P. 19
STREAM DICTIONARY/CROSS REFERENCES P. 20
SIMULATION STATS/LOOPS DEFINITION P. 21
* CALCULATION SUMMARY PRINTOUT *
forrtl: severe (46): inconsistent OPEN/CLOSE parameters, unit -130, file C:\USERS\LUIGI\APPDATA\LOCAL\TEMP\XPSIMWIN 3.0\STRMPARA.WKF
Image PC Routine Line Source
XPSIMV30.EXE 00007FF64DBC25E8 Unknown Unknown Unknown
XPSIMV30.EXE 00007FF64DB89284 Unknown Unknown Unknown
XPSIMV30.EXE 00007FF64D934AAE Unknown Unknown Unknown
XPSIMV30.EXE 00007FF64D5713C7 DSTR_XREAD 357 v1sdlini.for
XPSIMV30.EXE 00007FF64DB59165 MAIN__ 497 V1XPSIM.FOR
XPSIMV30.EXE 00007FF64DC3521E Unknown Unknown Unknown
XPSIMV30.EXE 00007FF64DC35659 Unknown Unknown Unknown
KERNEL32.DLL 00007FFE73C83034 Unknown Unknown Unknown
ntdll.dll 00007FFE74891431 Unknown Unknown Unknown
============================================================================
The remark is that an OPEN statement (with the IOSTAT parameter defined) should never crash unless the memory was corrupted.
Undoubtedly such a case would be caught by the Microsoft C++ compiler.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>FILDBG (CHARACTER string) and FILDBGNUM (INTEGER) are MODULE level variables.
I do not see USE YourModuleName in the subroutine, nor do I see IMPLICIT NONE, therefore FILDBG, FILDBGNUM, ... are local implicit variables (undefined by the way).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The module where the SUBROUTINE lies is INPUTOUTPUTFILE. Within the module are the following definitions:
USE IFPORT, ONLY : MAXPATH IMPLICIT NONE CHARACTER (LEN = MAXPATH), PRIVATE :: FILIN CHARACTER (LEN = MAXPATH), PRIVATE :: FILDBG ! *.dbg INTEGER, PUBLIC, PARAMETER :: FILDBGNUM = 21 PRIVATE OPEN_DEBUG_FILE
Hope this clarifies.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Something is very weird here. The normal "file not found" error is 29, not 602, and the message includes the unit number and the name of the file it tried to open.
Can you put together a small, self-contained example that demonstrates the problem?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The first thing I'd try is putting a line like this ahead of the OPEN statement:
FILDBG = 'test'
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a discrepancy between the rather incomplete error reports in this thread and the full expansion of Error 602. The online documentation of the error, which you can see at https://software.intel.com/en-us/node/691978, is
602severe (602): File not foundFOR$IOS_F6416. An OPEN statement specified STATUS='OLD' for a specified file or a directory path that does not exist.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It would help if you provided a command line to execute this program.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The main program in the "reproducer" has no executable statements. How are any of the OPEN statements in the subroutines ever reached?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"The main program in the "reproducer" has no executable statements. How are any of the OPEN statements in the subroutines ever reached?"
I was wondering about that, but thought it was probably just my ignorance of Windozy Fortran.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The executable is QuickWin. The file open is happening as part of the INITIALSETTINGS FUNCTION call. No executable statements necessary.
Typical command line arguments are
0 0 "File_name"
I had this in the Debug command from Visual Studio. I assumed that was saved with the project, but I guess not. I suppose I should have saved my own user settings.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I created a text file called zzz.dbg containing a few text lines. When I invoke the program from the command line like this:
reproducer 0 0 zzz.dbg
or like this
reproducer 0 0 "zzz.dbg"
it immediately terminates with exit code 0. No window is displayed. The behaviour is the same with Debug and Release builds. Is this what is expected?
By the way I have a very old version of Intel Fortran, 11.0.075.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The program needs 4 arguments, not 3. With:
reproducer 0 0 zzz.dbg 0
a window is opened. If I write FILDBG to a log file, just before the OPEN statement in OPEN_DEBUG_FILE(), I see the correct file name in the log file. zzz.dbg is replaced as expected (it becomes an empty file.)
Presumably this is the desired behaviour.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry about that. Yes, there are four command line arguments. I stripped out so much from the original that I lost track of the last CL argument.
Again, when I run it using Visual Studio 2017 run "As Administrator" I get the enclosed crash. I am running the file in Debug mode with 4 CL arguments input with the VS IDE. If I run it in the same manner, but using Visual Studio 2017 not being run "As Administrator" the code runs precisely as you are seeing.
Somehow invoking the Visual Studio 2017 application as administrator, which then prompts you with a dialog saying, in essence, "Are you sure you want to manipulate the inner workings of this PC?" which you must OK, then causes the file OPEN crash. I guess this setting is making the OPEN call behave as if its STATUS = 'OLD'.
These are wild guesses on my part. The need to run VS 2017 as administrator is coming in my current development path. This stumbling block is unacceptable.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page