Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tank!ncar!asuvax!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!decwrl!sgi!shinobu!odin!dinkum!calvin
From: calvin@dinkum.sgi.com (Calvin H. Vu)
Newsgroups: comp.lang.fortran
Subject: Re: Question on unformatted i/o - SOLUTION
Message-ID: <5207@odin.SGI.COM>
Date: 13 Mar 90 20:31:33 GMT
References: <14409@phoenix.Princeton.EDU> <14439@phoenix.Princeton.EDU>
Sender: news@odin.SGI.COM
Distribution: comp.lang.fortran,comp.sys.super,comp.unix.cray
Lines: 46

In article <14439@phoenix.Princeton.EDU> ej@gauss.Princeton.EDU (Eric Jackson) writes:

>In article <14409@phoenix.Princeton.EDU> ej@acm.Princeton.EDU I wrote:
>>When an unformatted write is done...two control words are written at the
>>beginning and end of the write with the number of bytes written...
>>...Does anyone know how to suppress the writing of these control words?

>As pointed out by John Fisher and Dan Whipple, writing without record
>separators can be accomplished using direct access i/o. A further
>portability problem does arise here, however: a record length must be
>given in the open statement, but whether the length is given in words
>or bytes depends on the implementation (bytes on a sun, words on sgi).
>Anyway, there is a code fragment at the end of this post illustrating
>the solution on a Silicon Graphics.
    Unless all of your records are of comparable sizes this solution can
    be just as bad as using ascii data since all records have to be zero-
    padded to the length of the longest records.  
    On SGI 3000 series machines you can do exactly what you want
    by opening the file with FORM='BINARY'.  On the SGI 4D machines, 
    in the next release of the compiler, you can do the same thing by 
    opening the file as an unformatted direct access file with record 
    length equal to 1 _byte_, e.g:
	OPEN(999, file='binarysystemfile', access='direct',recl=1,
	form='unformatted')
    and then do sequential I/O on the file.  In this way, the file will 
    be treated like an ordinary system file (as byte string in which each 
    byte is addressable).   A READ or WRITE request on such files will 
    comsume bytes until satisfied, rather than restricting itself to a 
    single record.
    One correction on your statement above, on SGI 4D machines we change
    the record length interpretation from byte to word in the 3.2 release
    to conform to the ANSI standard.   However if you prefer to have your
    record length interpreted as bytes you can do that by compiling your
    program with -old_rl option.



>Eric Jackson
>ej@acm.princeton.edu
>Princeton University

- calvin
--------------------------------------------------------------------------
Calvin H. Vu			   | "We are each of us angels with
Silicon Graphics Computer Systems  | only one wing.  And we can only
calvin@sgi.com   (415) 962-3679	   | fly embracing each other."