Re: Attempted to run EMPIRE-II compiled with gfortran

[Richard E Maine <Richard dot Maine at nasa dot gov>]

On May 21, 2006, at 4:11 AM, Paul Thomas wrote:

> Fortran77: 12.10.1.1 Open of a connected unit
...
> If the file to be connected to the unit is the same as the file to  
> which the unit is connected, only the BLANK= specifier may have a  
> value different from the one currently in effect. Execution of the  
> OPEN statement causes the new value of the BLANK= specifier to be  
> in effect. The position of the file is unaffected.
>
> If a file is connected to a unit, execution of an OPEN statement on  
> that file and a different unit is not permitted.
>
> Fortran 95 9.3.4 is acopy of this, except that the third paragraph  
> is extended to cover other specifiers.

F95 also adds some important relevant material. Partly it amounts to  
interpretation of the requirement above that specifiers other than  
blank= may not have a value "different from the one currently in  
effect". In particular, it is unclear what "the value currently in  
effect" is for the status= specifier in some situations. In f95, the  
status= specifier is spelled out in detail in order to avoid this  
ambiguity. In essence, the treatment is as though the value currently  
in effect for the status= specifier were old, even though it avoids  
that wording.

This stuff has gone through multiple passes of interpretation/ 
revision to get all the fine points consistent. The status= specifier  
is one of the fine points. Oh yes, and position= is another. (What is  
the "value currently in effect for position= if the file has been  
repositioned after the first open?) But the position= question isn't  
relevant to the code here.

> It seems to me to standard conforming; ie. the file connected is  
> the same as the file to which the unit is connected - the second  
> open is a "do-nothing".

For scratch files, with f77, I can't give a definitive interpretation  
of whether or not the code is allowed. That depends on whether you  
consider the status='scratch' on the reopen to be the same as the  
value "currently in effect".

In f95, such a reopen requires either status='old' or an omitted  
status=; a status='scratch' as in the sample, is not allowed. From  
f95 [140:2-3]:

  "If the STATUS= specifier is included in such an OPEN statement,  
it shall be specified with a value of OLD."

F77 effectively disallows status='OLD' in a reopen of a scratch file.  
Namely because under status=, it says

  "If OLD or NEW is specified, a FILE= specifier must be given."

In f77, it is a question of interpretation whether status='scratch'  
is ok or not on such a reopen. SInce allowing it would mean that f95  
had an unstated incompatibility (f95 explicitly disallows that case),  
I might take that as argument for it being invalid in f77, but that's  
certainly not an official f77 interpretation (and you can no longer  
get official f77 interpretations).

Omitting the status= would seem "safe", as in clearly allowed in both  
f77 and f90.

In summary,

F95 - status omitted or OLD is ok. Status scratch is invalid.

F77 - status omitted is ok. Status OLD is invalid. Status scratch is  
unclear to me.

Unfortunately, the code in question has the case that is unclear to me.

--
Richard Maine                |  Good judgment comes from experience;
Richard.Maine@nasa.gov       |  experience comes from bad judgment.
                            |        -- Mark Twain