binary unix files

I have always tried to avoid this topic, but now finally have to. I am to read an unformatted binary file that has been written by a fortran 90 program on a unix machine. I expect the format is both big-endian and also sequential access binary, so I want to convert it to little-endian and Salford unformatted binary. It contains integers, reals and complex numbers.

From the info I have read, I am assuming I need to: Record length : account for the difference between the unix and salford binary format, so cope with 2-byte or 4-byte record length headers. big-endian : convert all integer formats from big-endian to little endian, including the record headers.
( an FTN95 OPEN option something like RECORD_HEADER=('4' or '2/4') or RECORD_LENGTH=('BYTES' or 'WORDS') could solve this problem when creating a file to be read by programs compiled by other compilers )

My understanding is that reals and complex are little-endian in a unix binary file format (sourse Wikipedia), so do not need to be changed (?)

Is anyone familiar with this and could advise if my expectations are correct or not.

John

I have progressed my conversion of the unix based binary files and now have binary files as Salford format with little-endian (windows) values.

I am surprised to report that, contrary to my interpretation of Wikipedia, both integers and reals are stored as big-endian in unix and need to be reversed. (works very easily with the use of an EQUIVALENCE statement) Character strings remain unchanged. It is not often I find problems with Wikipedia for technical info, but it shows you should be careful. I best read it again in case I have mis-interpreted their description.

By reading from unix binary, all record length headers and trailers were 4 bytes long and reported the record length as bytes, so no need to worry about the Salford record length syntax. A portability option of always recording the length as 4_bytes could be useful.

John

Perhaps even better would be 'COMPATIBILITY'='UNIX'/'WINDOWS' or whatever else there is out there?

Eddie

What is desirable is impossible. There are just too many data formats to consider for a general purpose binary file configuration. Taking the most elementary, there are at least 5 floating point formats not counting their 'byte' lengths. There are 2 fixed point formats that I know of and that is not counting their byte lengths. Then you have character formats of either 7 or 8 bits. This is not counting the so-called streaming data types. Perhaps the toughest of these are from microphones, called geophones in the oil business, such that there is a file for each phone. Each of these has to be syncronized with the others to participate in crating a video for representation. And, so on.....