OPEN() statement with FILE='NUL' does not seems to work

[Ibrahim_K_]

I am trying to stop debug output which were being written to files. I changed the statements to:

OPEN(6,FILE='NUL',IOSTAT=IERR1,ERR=110)
OPEN(7,FILE='NUL',IOSTAT=IERR2,ERR=210)

It seems that some of the output is still being written and more importantly empty files with updated time and date shows up where the files are stored.

Is there any other way to suppress output done with like WRITE(6,100)?

I. Konuk

[Steve_Lionel · Accepted solution]

I can't reproduce a problem with this - if I open 'NUL' and write to it, no file gets created. Please post a small but complete program that demonstrates the issue.

[Ibrahim_K_]

Thank you all for very helpful comments and suggestions.

I took some time to realize that my problem was bigger than an OPEN statement!

I am almost at the end of a long development. I have been doing my project incrementally. Every time I add a new library or project, I typically make a complete copy of my Visual Studio (2017) solution to somewhere else to make sure my last point is secure. Although I had inkling this is not true, but O always believed all directories in the VS solution and project files are relative. Unfortunately, I discovered that there are few exceptions. Some of the linker paths is not relative. Not only that, these paths do not show up VS property sheets. Luckily, I knew how to edit [unload project, edit project file] the project file.

Basically, I was linking my old Fortran project library. So, any changes I made to my program code did not get it to my final exe. Once I edited the main project project file, everything works. Apologies for the long message. I though it may help somebody in the future.

Thank you again very much for all replies. In this case I am just going to tag Steve's response as solution as I can not tag more than one message.

I. Konuk

[Steve_Lionel]

I am glad to hear that you figured it out. In the future, when you think you have identified a problem, it is always a good idea to create a separate test case to verify that the problem is what you think it is. I have found that the majority of programmers think a problem is one thing, and they show us only that bit, when it is actually somewhere else. This is why I always ask for a minimum reproducible example. Often in the process of doing so, you'll figure out what really happened.

Paths can be relative or absolute.

[mecej4]

Please check your code to see if this OPEN statement is being superseded by subsequent OPEN statements to the same unit number, CLOSE statements for that connection to NUL or by subsequent WRITE statements to unit-6 without that unit having been explicitly opened.

[GVautier]

Are you sure that all "debug outputs" are written to unit 6/7?

Search for those messages in the code to find to which unit they are written.

It is a good practice to write all debug messages to a specific debug unit (999 for example). Connect the debug unit to the desired output (file, console) in debug mode and to nul in release mode.