'binary' files

John D. McCalpin mccalpin at masig3.masig3.ocean.fsu.edu
Wed Oct 25 08:15:05 AEST 1989


In article <8910242343.AA05386 at aero4.larc.nasa.gov>
blbates at AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS294 x42854")
writes:

>    The problem is that it ISN'T a binary file.  It is an unformatted
>file.  The 3000's let you create BINARY files, I don't think any of the 4D
>machines will let you (in FORTRAN).  If you specify 'BINARY' as the
>form in a FORTRAN open statement, you don't get a binary file; you get
>an unformatted file that has record marks between each record.  A binary
>file created on a 3000 doesn't have these record marks.  The only bytes
>in the file are what you write there.

Let's get all of this straight:
	On the 3000, form='unformatted' gives a file with binary
			data separated by newline characters
	On the 3000, form='binary' gives a file with binary data
			with no record marks of _any_ type.

	On the 4D, form='unformatted' gives a file which is
		control-word-delimited (to borrow from CDC's
		notation). Each record is preceded by a 32-bit 
		integer giving the number of bytes in the record.
		The record is also followed by the same integer.

	On the 4D, form='binary' gives obscure error messages.

>    On the 4D's the only way to get a binary file from a FORTRAN program
>is to write a C routine that does the binary writes and call it from
>FORTRAN.

That is how we do it here....

>    I hope SGI changes this.  Binary writes from FORTRAN are a MUST in
>my work.  This is one of the things I will dread, if we get a 4D machine.
>I find unformatted files useless, they are also larger than binary
>files.

On the other hand, the control-word-delimited format is identical to
that used on Sun machines (at least the Sun-4's).  This makes it
trivial to copy binary data files between SGI and Sun machines.

The control-word-delimited format also makes it possible for the
run-time system to do some checking of whether or not you are reading
the data correctly, and it makes it easier to recover data from a
partially corrupted file.


--
John D. McCalpin - mccalpin at masig1.ocean.fsu.edu
		   mccalpin at scri1.scri.fsu.edu
		   mccalpin at delocn.udel.edu



More information about the Comp.sys.sgi mailing list