blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS294 x42854") (10/25/89)
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.
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.
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.
--
Brent L. Bates
NASA-Langley Research Center
M.S. 294
Hampton, Virginia 23665-5225
(804) 864-2854
E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.govmccalpin@masig3.masig3.ocean.fsu.edu (John D. McCalpin) (10/25/89)
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
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS294 x42854") (10/25/89)
I used a 4D/20, Personal Iris and with form='binary' I didn't get
any errors. The compiler took 'binary' to mean the same as 'unformatted'.
I wish it had given me an error, that would have made it easier to find
out what the problems was. What type of 4D were you using?
Thanks for the info, up till this point I hadn't see any use for
unformatted files.
--
Brent L. Bates
NASA-Langley Research Center
M.S. 294
Hampton, Virginia 23665-5225
(804) 864-2854
E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov