Named files and the NEWUNIT keyword

[John4]

Hi,

When I compile and run the code below, I get .FALSE. when I inquire if the just opened file has a name, and therefore when inquiring for name I get an empty string.

I'm almost sure that's the intended behavior (since gfortran returns both .TRUE. for fileIsNamed and the corresponding file name), but I just wanted to be sure that it's not yet another tricky feature in the Fortran standard.

Also, either the forum search feature is really bad, or I've spent the last 15 years or so searching for web stuff in the wrong way.

[fortran]implicit none

integer :: IU, ios
logical :: fileIsOpen, fileIsNamed
character(255) :: filename

open (NEWUNIT = IU, FILE = 'test.dat', STATUS = 'UNKNOWN', ACTION = 'WRITE', IOSTAT = ios)
    if (ios /= 0) stop 'error opening file'
    write (IU, '("whatever")')
    flush (IU)
    inquire (UNIT = IU, OPENED = fileIsOpen)
    inquire (UNIT = IU, NAMED = fileIsNamed)
    inquire (UNIT = IU, NAME = filename)

    print *, 'file is open =', fileIsOpen
    print *, 'file is named =', fileIsNamed
    print *, 'file name is =', TRIM(filename) 

close (IU)

end [/fortran]

[Steven_L_Intel1]

This is a bug in our implementation - I will report it. Issue ID is DPD200169563.

The forum search is not very good, I'll admit. The "Search Forum" link on the page works better than the search menu on the top of the page.

[Steven_L_Intel1]

This has been fixed for a future update after update 6.

[Steven_L_Intel1]

It turns out that only part of the problem was fixed in Update 7 - the file name is now returning correctly but NAMED= returns .FALSE. when it shouldn't. I have reopened the issue with the developers.

[John4]

I'm still stuck with Update 5, because of this regression... So I guess this is just one more reason to wait for Update 8+.

[Steven_L_Intel1]

The NEWUNIT issue has been fixed - I expect the fix to appear in Update 9.

[nvaneck]

I just tried to use NEWUNIT and it worked fine as long as I only opened one such file. When I added a second instance, the program bombs with a recursive I/O error at write statement directed to a different unit. When I use explicit unit numbers instead for the scratch files, everything works fine. Is this a known problemwith NEWUNITfixed in Update 9 as well?

[Steven_L_Intel1]

Haven't heard of that one. Test program?

[nvaneck]

I tried this again after testing a simple program with two files and got no problem. So I began using NEWUNIT throughout the project. No problem until I got to one routine that uses 4 scratch files.

All worked fine until I added the 4th one. Then I started getting the recursive I/O error in another routine when

it attempts an INQUIRE statement on an unopened file.

The INQUIRE statement is

INQUIRE (FILE=FILENAME,EXIST=IFEXIST,OPENED=IFOPEN)

and the error occurs when this or another routine is subsequently invoked. All NEWUNIT files are closed between runs, debug with all error checking, bounds, etc. are turned on.

The problem goes away if I replace the last NEWUNIT number installed with a fixed one in the open statement.

I doubt I can provide a simple example, as the project is complex. It is a set of routines/commands like SPSS annd SAS and uses a large set of common subroutines. It is when another command is used after the recently changed one that the problem arises, and occurs during the open routine on the same or a different dataset.

As it stands, I'll just avoid using NEWUNIT when it causes a problem, or switch back to fixed unit numbers. I've used NEWUNIT in other routines with fewer units with no other problems so far.