Can't Find Path

[Brebrick__Robert]

Using Compaq Visual fortran. Have a fortran program with input from the command line. Everything works. Then while inworkspaceI change the name of the input file. When I try to run the program againI get a message can't find input file. Recompile and construct new workspace. Same error. How do I straighten this out?

[joerg_kuthe]

>Using Compaq Visual fortran. Have a fortran program with input from the command line. Everything works. Then while inworkspaceI change the name of the input file. When I try to run the program againI get a message can't find input file. Recompile and construct new workspace. Same error. How do I straighten this out?

When running your program in workspace, the working directory is the project directory (where the .dsp file is located) and not directory where the .exe is located (usually debug or elease directory). Can this be the cause of your problem?

[Brebrick__Robert]

Don't think so. Let me say at once that I am a number cruncher and somewhat ignorant of the subleties underlying programing. I am using Compaq Visual fortran 6.5 on Windows XP Home edn. My program was working when while I was in the workspace I changed the name of the input file and reran the program. I use input from the command line and when I entered the input file name I got a message: forrtl: severe<29>: file not found followed by the complete path to the desired input file. So somebody knows. I tried to fool the program by erasing all the (project) files except the fortran and input. Compiled again, an active projectworkspacewas built, rebuild all, and rerun. Same error. Moved the program to another computer, also Windows XP home edn, and it works. Somehow I have the stain of Cain stamped somewhere. Anyone have an idea?

[Steven_L_Intel1]

I have seen users report complaints similar to yours in the past. Each time, the clue was there in the error message which showed a filespec that was just slightly different from what was correct. I suggest you examine the message again carefully and compare against the path and exact full name of the file.

[jimdempseyatthecove]

As a confirmation of path, immediately prior to the open that fails insert an OPEN that creates a new output file of unique name "HokusPokus" using the same method to derive the path that you use for the file on the open that fails. Then after the open (creation) of the bogus file, look for it. You may have current drive and/or current directory issues and the creation of the file will help to resolve this.

Jim

[Brebrick__Robert]

Thank you Steve. The file spec appears to be correct. Problem persists

[Brebrick__Robert]

Thanks Jim. I usually use a dummy's approach. Under Project settings I select Fortan then Compatibility then input from the command line. So connecting the named input and output files is done behind the scenes with no further intervention from me. I can then use any name for the input or output file without going into the fortran program itself.I did try compiling without that choice of input from the command line and opened a file for input and outputwithin the program.. Program still couldn't find the input file. Even specified the complete path from C: onwards in the name of the file to be opened.

[jimdempseyatthecove]

Are you enquoting the file name if it hasdelimiting characters?

Have you verified the working directory?

The "Use Filenames from Command Line (PowerStation)" will hide from you what it uses (selects) from the command line. So you do not know what is being used in the OPEN.

I do not think there is an INQUIRE-like function that returns the file specification of a failing OPEN (that uses the Use Filenames from Command Line) . If there were you could find out what is being used.

What does a call to GET_COMMAND_ARGUMENT return for each argument in the list of arguments? (get more than one argument to ensure you don't have an empty arg)

Hmm... the first argument is number 0 and is the program name (command name). If the OPEN with blank name begins at argument 0 (instead of 1) then your OPEN with blank ("Use Filenames from Command Line")will (attempt to) open the program, and depending on the mode would get a file in use. If you ignore the 1st open error, does the second open get the first file?

Can you independently open the problem file using the return from GET_COMMAND_ARGUMENT? If so, then file an incident showing "Use Filenames from Command Line" is not picking up the (same) argument from the command line in the same manner as does GET_COMMAND_ARGUMENT.

Also call GETWD to get the current working directory

Jim Dempsey