PRINT and WRITE to a common file

[longden_loo]

I have a large legacy app with a mixture of PRINT and WRITE statements, the latter in different forms, sometimes WRITE(*,*) and other times the unit number is given (ie, WRITE(6,*)).

Previously these messages were displayed in a console window and the order of the output was as expected ... in the order of occurrence during execution.

However, when the app was converted to a DLL, the output needed to be rerouted to a file for use as a runtime log, so I initialized units 6 and -1 to a file of the same name using OPEN. This resulted in a jumbled output with all "WRITE(*" and PRINT states first, followed by the WRITEs to unit 6 ... sometimes with the unit -1 output overwriting the initial ones for unit 6.

I fussed with all the various OPEN specifiers with no better results.

Is there an obvious way to direct the outputs to a single file in the order of execution? The DLL is being called from a Java app via C, so a simple redirection may not be available. And the number of WRITE/PRINT statements makes for more editing work than I'd like, if there's an easier way.

Thanks for any suggestions or pointers to references on this topic.

- Longden

[Paul_Curtis]

Add FLUSH statements following each WRITE to ensure that the output buffer is immediately written to the file. There may be a compiler option to specify FLUSH behavior (easier than going over your code), but I can't find it.

[longden_loo]

Quoting - Paul Curtis

Add FLUSH statements following each WRITE to ensure that the output buffer is immediately written to the file. There may be a compiler option to specify FLUSH behavior (easier than going over your code), but I can't find it.

Yeah I was hoping for some kind of auto-flush option vs manually editing 2000+ WRITE/PRINT lines.

[jimdempseyatthecove]

On the OPEN statement try adding BUFFERED='NO'

Jim Dempsey

[Steven_L_Intel1]

Don't try to open unit -1. Do compile with /assume:noold_def_unit_56. (I think this is the default in 11.1 but I'm away from my references to check.) This should cause both PRINT and WRITE (6) to be merged to unit 6.

[longden_loo]

Quoting - jimdempseyatthecove

On the OPEN statement try adding BUFFERED='NO'

Jim Dempsey

Should've mentioned I tried that already with no effect on the order. Thx.

[longden_loo]

Quoting - Steve Lionel (Intel)

Don't try to open unit -1. Do compile with /assume:noold_def_unit_56. (I think this is the default in 11.1 but I'm away from my references to check.) This should cause both PRINT and WRITE (6) to be merged to unit 6.

I get compile errors:
ifort command line error: Unrecognized keyword 'noold_def_unit_56' for option '/assume'

... also we noted some time ago that when we switched from IVF-9 to IVF-10, a compile option changed from:

/switch:fe_defunit_56 [ in IVF-9 ]

to

/switch:_disabled_fe_defunit_56 [ in IVF-10 ]

Looking at the IVF-11 projects that were converted from IVF-10, I see that the latter option is still set and since it vague resembles what you're suggesting, I'm wondering if this setting is relevant to my issues as well.

I can't find information on any of these (ie, "_disabled_fe_defunit_56") in the Help screens searches so I'm pretty clueless about what they're trying to do.

[Kevin_D_Intel · Accepted solution]

With IVF 11.1, try the option: /assume:noold_unit_star

[longden_loo]

Quoting - Kevin Davis (Intel)

With IVF 11.1, try the option: /assume:noold_unit_star

That did the trick, thx!

Now my "Command Line" enry for Fortran projects show:

/switch:_disabled_fe_defunit_56 /assume:noold_unit_star

... am I correct in leaving in the "/switch" setting? (and what does it mean?)

[Kevin_D_Intel]

No, remove it. Both /switch forms are old internalspellings from earlier releases.