Warning 7951 on open statement

[van_der_merwe__ben]

For the following code:

      INTEGER UNIT,RECL,IOSTAT,iu
      CHARACTER FILE*(*),STATUS*(*),ACCESS*(*),FORMAT*(*),CSTAT*20

...
         ELSEIF ( CSTAT.EQ.'NEW' ) THEN
            OPEN(UNIT=UNIT,STATUS=CSTAT,FILE=FILE,ACCESS=ACCESS,
     +      FORM=FORMAT,SHARE='DENYWR',IOSTAT=IOSTAT)
         ELSEIF ( CSTAT.EQ.'UNKNOWN' .OR. CSTAT.EQ.'MODIFY') THEN
            OPEN(UNIT=UNIT,STATUS=CSTAT,FILE=FILE,ACCESS=ACCESS,
     +      FORM=FORMAT,SHARE='DENYWR',IOSTAT=IOSTAT,
     +      BUFFERED='YES',BLOCKSIZE=8192,BUFFERCOUNT=500)

The compiler says:

warning #7951: The STATUS= specifier has the value SCRATCH, the FILE= specifier will be ignored in the OPEN statement.   [FILE]
            OPEN(UNIT=UNIT,STATUS=CSTAT,FILE=FILE,ACCESS=ACCESS,
---------------------------------------------^
warning #7951: The STATUS= specifier has the value SCRATCH, the FILE= specifier will be ignored in the OPEN statement.   [FILE]
            OPEN(UNIT=UNIT,STATUS=CSTAT,FILE=FILE,ACCESS=ACCESS,
---------------------------------------------^

So that makes me think I can fix this by simply removing the ", FILE=FILE" portion since it will be ignored, but then all sort of runtime errors ensue that do not happen otherwise?

So what is the proper way of fixing the code to not have this warning?

[FortranFan]

andrew_4619 wrote:

Workarounds are easy, but not withstanding any issues with the OP's code (not least the considering that fixed format makes my eyes bleed) primary issue is a bug in the compiler. 

I don't think warkarounds are always easy - often input from independent, disinterested peers is necessary to come up with the workarounds - it's not always the case forum threads such as this one has readers offering reasonable, actionable workarounds.  But that's an aside.

Re: "primary issue is a bug in the compiler. " - I doubt there will be acceptance from Intel team this is a "compiler bug" - perhaps they might agree the compiler is issuing a needless warning, the processor being overeager and pedantic in this case with poor handling of context (in an IF branch where CSTAT can be known to either 2 specific values, it's treating an instruction as if it can have a 3rd value).

But what are the chances the vendor will rush this incident to top priority given all the other bugs and ICEs and work toward issuing a compiler update to suppress this spurious warning?

That's why a workaround is the better bet for OP for a considerable amount of time.

[van_der_merwe__ben]

I switched to a work around, using explicit STATUS string values in the OPEN calls. The issue has been logged with Intel. But I understand it much better now, thank you!