figuei@arakis.rutgers.edu (Francisco Figueirido) (06/05/91)
I am trying to write a program (in C) which needs to read data from a file which was created by a Fortran-written program. The file in question consists of unformatted (i.e., binary) data. I know that the CRAY (I am using the one at PSC) writes, as most Fortran compilers, some sort of count (word count?) before the records, but cannot make sense of everything I see in the octal dump. Can someone direct me to where can I get more information about the format of unformatted (no pun intended!) files? Thanks for the help. Francisco Figueirido email: figuei@lutece.rutgers.edu
djh@xipe.osc.edu (David Heisterberg) (06/05/91)
In article <Jun.4.16.30.17.1991.306@arakis.rutgers.edu> figuei@arakis.rutgers.edu (Francisco Figueirido) writes: > Can someone direct me to >where can I get more information about the format of unformatted (no >pun intended!) files? Thanks for the help. If you have it, check out SR-2014, "Unicos File Formats and Special Files Reference Manual", or try "man 4f blocked". There is also an include file that defines structs and macros for handling the control words. It will be referenced in the man page, but you may need to ask one of your systems people to let you at it (it's under /usr/src). -- David J. Heisterberg djh@osc.edu We are NOT all The Ohio Supercomputer Center djh@ohstpy.bitnet Keynesians now. Columbus, Ohio 43212 ohstpy::djh
sgombosi@isis.cs.du.edu (Stephen O. Gombosi) (06/05/91)
In article <Jun.4.16.30.17.1991.306@arakis.rutgers.edu> figuei@arakis.rutgers.edu (Francisco Figueirido) writes: > >I am trying to write a program (in C) which needs to read data from a >file which was created by a Fortran-written program. The file in >question consists of unformatted (i.e., binary) data. I know that the >CRAY (I am using the one at PSC) writes, as most Fortran compilers, >some sort of count (word count?) before the records, but cannot make >sense of everything I see in the octal dump. Can someone direct me to >where can I get more information about the format of unformatted (no >pun intended!) files? Thanks for the help. The file is a "Cray Blocked" file. This was the standard file format on the COS operating system. The file consists of 512 word (4KB) blocks, each of which is headed by a "block control word" or BCW. In addition, records within the file are delimited by "record control words", or, you guessed it, RCWs. The format of these control words should be contained in the header file: /usr/lib/libio/cos/cosio.h Unless they've moved them since I last needed them. I'd just look around for "cosio.h". Here is a quick synopsis: BCW: Field Bits (high-order==0) Meaning m 0 - 3 CW type (0 == BCW) bdf 11 "bad data flag" (should be unused) bn 31-54 Block number (modulo 2**24) fwi 55-63 Forward Index (# words to next CW) RCW: RCWs come in three flavors: End-Of-Record (EOR), End-Of-File (EOF), and End-Of-Data (EOD). A COS dataset (which corresponds to a UNICOS "file") may contain more than one COS "file" (this is sort of like a "partition" on some other operating systems. Don't worry about it - terminology doesn't transfer... Field Bits (high-order==0) Meaning m 0-3 CW type (octal 010==EOR, 016==EOF, 017 ==EOD) ubc 4-9 Unused bit count (number of unused low order bits in the last word of the record) tran 10 Don't worry about this one bdf 11 See above srs 12 Ditto pfi 20-39 Previous file index (may be unused) pri 40-54 Previous record index; offset modulo 2**15 to block where current record starts (intended to allow fast backspacing) fwi 55-63 forward index; # of words to next CW. Every "full-record" binary write or buffer out produces an EOR-delimited record. A FORTRAN ENDFILE produces an empty record followed by an EOF. All this should look familiar if you ever worked on a 7600, or used Cyber Record Mangler (so what if the words are a LITTLE bigger?). If you need more help, let me know... -Steve Gombosi sgombosi@isis.cs.du.edu "Just another ex-Crayon"
gstiehl@convex.convex.COM (Greg Stiehl) (06/06/91)
figuei@arakis.rutgers.edu (Francisco Figueirido) writes: > > I am trying to write a program (in C) which needs to read data from a > file which was created by a Fortran-written program. The file in > question consists of unformatted (i.e., binary) data. I know that the > CRAY (I am using the one at PSC) writes, as most Fortran compilers, > some sort of count (word count?) before the records, but cannot make > sense of everything I see in the octal dump. Can someone direct me to > where can I get more information about the format of unformatted (no > pun intended!) files? Thanks for the help. I would just write a small fortran function to read in the file, then link the fortran funtion into your C program. You will have to worry about differences in argument passing, but that seems much easier than decoding the fortran file format. Why re-invent the wheel? -greg. ---- Greg Stiehl (gstiehl@convex.com) Graphics Software Convex Computer Corp.
glover@sequoia.cray.com (Roger Glover) (06/11/91)
figuei@arakis.rutgers.edu (Francisco Figueirido) writes: :> I am trying to write a program (in C) which needs to read data from a :> file which was created by a Fortran-written program. The file in :> question consists of unformatted (i.e., binary) data. I know that the :> CRAY (I am using the one at PSC) writes, as most Fortran compilers, :> some sort of count (word count?) before the records, but cannot make :> sense of everything I see in the octal dump. Can someone direct me to :> where can I get more information about the format of unformatted (no :> pun intended!) files? Thanks for the help. In article <1991Jun06.133409.125@convex.com> gstiehl@convex.com responds: :>I would just write a small fortran function to read in the file, then link :>the fortran funtion into your C program. You will have to worry about :>differences in argument passing, but that seems much easier than decoding :>the fortran file format. Why re-invent the wheel? Writing a C-callable Fortran function to accomplish this would not be too hard for someone fairly conversant with both languages, but there is an easier way. The CRI-specific "ff" functions allow you to do Fortran-like record-based I/O in C. To take advantage of these functions you must use the command "asgcmd" before you run your executable. To handle a COS-blocked file, such as the one you described you should a UNICOS command sequence something like this: $ eval `asgcmd -F cos datafile` $ a.out The "asgcmd" command line looks so weird because it is actually setting an "environment variable" which the "ff" routines loaded into "a.out" will interpret. The man page for "asgcmd" suggests alias/function settings to make the command line more UNIXy. Those of you who run X windows should find this familiar, since the "resize" command uses a similar technique. "datafile" should be the filename you use with the "ffopen" routine. I would suggest, as a first step, that Mr. Figueirido read the man pages on "asgcmd", "ffopen", "ffread" and "ffclose". After that, if you still have questions, feel free to e-mail me. PS: I would have responded to the original posting, but I have been too busy lately to follow newsgroups. ------------------------------------------------------------------ Roger Glover DISCLAIMER: CRI does not necessarily share my Cray Research, Inc. opinions, but that is not my fault. glover@earth.cray.com TECHNICAL DISCLAIMER: The command sequence shown was not taken from any verifiable working example. It is based only on my experience with the commands and functions described.