Unlike some other compilers, FTN95 does not open a file with a name such as FORTnn if I/O is attempted to unit-nn without a previous OPEN statement having been executed for the file. Does the file "test.out" already exist in the working directory?

If you wish to create a new file, add the clause STATUS='NEW' to the OPEN statement. If you are going to run your program several times, and you do not mind overwriting the file, should it already exist, you may use the STATUS='REPLACE' clause instead. See https://silverfrost.com/ftn95-help/inout/open.aspx .

By the way, please note that Plato is merely an IDE from which the FTN95 compiler, SLINK linker and SDBG debugger can be managed. Other IDEs such as MS Visual Studio can be used with the same development tools.

Last edited by mecej4 on Sun Apr 01, 2018 9:03 pm; edited 2 times in total

I didn't know this mecej4 ..... and it isn't clearly stated either in the documentation that you link to above, I don't think (unless I missed some subtelty, or more likely just missed something altogether)

Maybe the

Quote:

STATUS=<string>
<string> is a character expression which, when trailing spaces are removed, gives the value OLD, NEW, REPLACE, SCRATCH or UNKNOWN.

in the documentation needs to have something like the following appended to it ? ....

Quote:

If OPENing an output file then STATUS = NEW is obligatory

and maybe it should also be reflected in the first example given at the top of that documentation page which gives an example exactly like the one attempted by Helen, albeit for an input file.

This point is also worthy of being added to any section(s) of the documentation concerning conversion of programs from other compilers which , if I understand correctly, allow opening of ouput files without the STATUS = NEW present.

I presume that the FORTRAN standard is clear on this point ?[/quote]_________________''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... "

The standard leaves out the meanings of many I/O statement keywords as "implementation dependent".

If STATUS='NEW' is used, the I/O system will create the file on the first successful run of the program. A subsequent run will fail because the file already exists, unless the user remembers to delete the file before the second, etc., runs. This is where STATUS='REPLACE' comes in handy. If the output file does not exist, 'REPLACE' is equivalent to 'NEW'. For an existing file, 'REPLACE' causes the file to be deleted and then created.

After a file has been opened for writing with 'NEW' or 'REPLACE', the status of the file changes to 'OLD'.

According to the standard, if the STATUS= clause is omitted, it defaults to STATUS='UNKNOWN', and the status is processor dependent.

What this implies is that if you use OPEN with no STATUS= clause, some compilers may cause the OPEN to fail. If things are working and you don't switch compilers, your code will continue to work as before.

Ken, is that code you posted what you meant because it appears to be exactly the same as Helen's code ! (barring the initialisation of 'a' that is ) ?_________________''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... "

Ken, is that code you posted what you meant because it appears to be exactly the same as Helen's code ! (barring the initialisation of 'a' that is ) ?

No, Helen had "WRITE(10) ..." while Ken had "WRITE(10,*) ..."

Helen's write statement was wrong as it implied an unformatted binary write, while Ken's was a formatted write to a text file.

Helen,
FTN95 requires that you must open a file, before you can use it.
Some other compilers will open a default named file, if you don't provide a name. (Not sure what they do about FORM= etc)
I think it was previously the case that some compilers provided an automatic name to temporary files (STATUS='SCRATCH') but past compilers I have used have required a file-name to be provided with an OPEN statement.

The safest way is to specify:
Open (UNIT=.., FILE=.., STATUS=.., FORM=.., IOSTAT=..)

FORM='FORMATTED' is the default, so if you specify alternatives (UNFORMATTED), then you also need to provide further options.

I think the documentation for OPEN is the part of the language manual that I refer to most often. It copes with many different possible uses of files.

John, I did not put a literal interpretation on the two lines of code in the original post. Without a format specifier in the WRITE statement, the code shown would have failed with any compiler for the following reasons.

"WRITE(10)" implies an unformatted file connection, whereas the standard says "If this specifier is omitted, the default value is UNFORMATTED if the file is being connected for direct access, and the default value is FORMATTED if the file is being connected for sequential access."

It would be useful for Helen to post the actual code that generated the error message that she posted, along with details such as the compiler version, options in effect, etc.

According to the standard, if the STATUS= clause is omitted, it defaults to STATUS='UNKNOWN', and the status is processor dependent.

What this implies is that if you use OPEN with no STATUS= clause, some compilers may cause the OPEN to fail. If things are working and you don't switch compilers, your code will continue to work as before.

Thanks Mecej, it's been a very long time since I used another compiler and now that I've got to grips with Clearwin+ I have no plans to change. But I have made a note of this for future reference.

I'm getting the error at runtime "File access and properties are incomplete."
Any assistance greatly appreciated!

1) I wrote about this here many times. That was good example of Fortran punishing itself and losing market share by such cryptic error messages.

2) It might be worth to synchronize FTN95 with most other compilers which allow WRITE and READ without even OPENing any files. Fortran strict, complex and confusing rules for input/output often punish novices so much that they never use Fortran again.

0005) open(2,file='fort.2',status='replace',form='formatted')
WARNING - Opening unit 2 may affect the operation of output to the default unit '*' - are you sure you want to do this?
0012) close(2)
WARNING - Closing unit 2 may affect the operation of output to the default unit '*' - are you sure you want to do this?
NO ERRORS, 2 WARNINGS [<TST> FTN95 v8.10.0]
Creating executable: tstw.EXE

We can suggest more clear wording for the error message, but we should not fault the run time error message after we have ignored the compile time warnings.

In the actual application, the OPEN and WRITE statements contained LUT as the file unit number; the OPEN and WRITE occurred in separate source files, so the compiler could not have known that LUT = 2, and did not issue any warnings.

Last edited by mecej4 on Sun Apr 01, 2018 4:03 pm; edited 2 times in total

i am a novice so i can quite understand why i fell at the first hurdle, but I found your forum and being here is so great of you!
I was using Simply Fortran (just found it first) at first until I had to pay what was too much for me and on that program you don't have to to open the file first... you can just write. However it is swings and roundabouts (probably) as I never worked out how to write to a "specific" filename in that program... it always seemed that it had to be a number 100,101 etc. I'm probably still very ignorant, but I just wanted to add my novice experience! Happy Easter!

i am a novice so i can quite understand why i fell at the first hurdle, but I found your forum and being here is so great of you!
I was using Simply Fortran (just found it first) at first until I had to pay what was too much for me and on that program you don't have to to open the file first... you can just write. However it is swings and roundabouts (probably) as I never worked out how to write to a "specific" filename in that program... it always seemed that it had to be a number 100,101 etc. I'm probably still very ignorant, but I just wanted to add my novice experience! Happy Easter!

Helen, we are all ignorant in one way or another, but we are here to help one another, and this forum is very effective at that! FTN95 is a great compiler for use when learning Fortran. Your questions on using the compiler and Fortran programming are welcome.

I think that the other Fortran compiler that you used allowed you to use unit numbers (such as 100, 101, ..) for I/O without naming and OPENing the corresponding files, but that is a non-standard extension. I should be very surprised if that compiler did not accept OPEN -- if it did not, that compiler would be flouting the Fortran standard.