Backwards incompatibility with unformatted file records?

[dboggs]

I need to create data files that can be read by several legacy programs, created using a very old F77 compiler (MS Fortran 5.1). Some of the files used "unformatted sequential" records. Although this appears to still be supported by F90, I don't believe they are compatible, and I need a solution.

In the old F77 (and as far as I can tell this was an actual standard) these records were composed of "blocks" each containing UP TO 128 bytes, and delimited by bytes indicating the actual length of each block; if the record needed to hold more than 128 bytes then these would spill over into additional blocks.

In the current compiler (F90 standard?), a sequential unformatted record consists of a single block, delimited by blocks of 4 bytes indicating the length of the block.

Understanding these formats, I could "force" the new compiler to write a file in the old format, but it is quite an awkward coding procedure. Seems there should be a better way. Seems there should be a compiler switch, for example, that would automatically create these legacy files.

Am I right about this? Whatever happened to the famous Fortran backwards compatibility? Can someone suggest a good solution to this problem?

[bmchenry]

have you tried variations on Unformaatted files
/assume:byterecl
Config->Properties->Data->
and are your legacy files created with a program you can also modify the options and recompile?

[Steven_L_Intel1]

The Fortran standard has never specified the on-disk structure of unformatted (or formatted) records. MS Fortran used a unique layout. Intel Fortran uses a layout common to most Windows and UNIX/Linux compilers (not specified in the standard), but also supports the old Microsoft format with the /fpscomp:ioformat option.

So there is no such "famous Fortran backwards compatibility" when it comes to unformatted files. There is the new STREAM recordtype which mimics C's byte-stream I/O. However, most modern Fortran compilers support what Intel Fortran does, at least as long as records are shorter than 2GB or so.

[dboggs]

Thanks for these very quick responses.

The compiler switch has solved my immediate problem. Ultimately I will need something different, since (suprise to me) my program will have to offer output in the user's choice of a current unformatted file, or a legacy unformatted file, or both. I had no idea these would be different, but now I realize I will have to code for both. The option, of course, cannot be handled by a compiler switch. But now I understand both formats sufficiently to support them with real-time code.

[Steven_L_Intel1]

You can have a subroutine in one source file for one format, with the option set for that source only, and another for the default format without the switch, etc. It's the OPEN that cares about the switch.

[dboggs]

Good news. Thanks.