🚀 go-pugleaf

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

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"

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.

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.