Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!stat!stat.fsu.edu!mccalpin
From: mccalpin@masig3.masig3.ocean.fsu.edu (John D. McCalpin)
Newsgroups: comp.sys.sgi
Subject: Re: 'binary' files
Message-ID: <MCCALPIN.89Oct24181505@masig3.masig3.ocean.fsu.edu>
Date: 24 Oct 89 22:15:05 GMT
References: <8910242343.AA05386@aero4.larc.nasa.gov>
Sender: news@stat.fsu.edu
Organization: Supercomputer Computations Research Institute
Lines: 51
In-reply-to: blbates@AERO4.LARC.NASA.GOV's message of 24 Oct 89 20:43:32 GMT

In article <8910242343.AA05386@aero4.larc.nasa.gov>
blbates@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@masig1.ocean.fsu.edu
		   mccalpin@scri1.scri.fsu.edu
		   mccalpin@delocn.udel.edu