Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!ogicse!milton!whit
From: whit@milton.u.washington.edu (John Whitmore)
Newsgroups: comp.lang.fortran
Subject: Re: WRITE don't do that too me!
Message-ID: <7449@milton.u.washington.edu>
Date: 13 Sep 90 01:06:47 GMT
References: <quan.653053983@sol> <7396@milton.u.washington.edu> <MAINE.90Sep12075420@altair.dfrf.nasa.gov>
Distribution: comp
Organization: University of Washington, Seattle
Lines: 31

In article <MAINE.90Sep12075420@altair.dfrf.nasa.gov> maine@elxsi.dfrf.nasa.gov (Richard Maine) writes:
>On 12 Sep 90 01:08:38 GMT, whit@milton.u.washington.edu (John Whitmore) said:
>
>John> 	As nearly as I can determine, unformatted output does NOT
>John> add any <CR> or <LF>; you might run into some other record terminations,
>                                ^^^^^
>
>You are *guaranteed* to run into some form of record termination or
>record header or some other machine-dependent record structure in most
>cases.
	
	Well, I read the original post as inquiring how output could
be created that would properly tweak a smart (graphics) terminal
with the correct bytes (and not pad it with extraneous fluff).
At least on VMS, the 'record structure' is entirely subsumed
in some header information, and WRITEing records, or COPYing a file, to 
a terminal port doesn't bother with any transferrence of that header
material.  Yes, there was record-length information in a
permanent file created; no, that record-length information did NOT
show up in the byte stream to the terminal.  The I/O driver
for the serial port is apparently smart in this regard.  As
you say, this may not be universally true.
>
>The only cases where the standard allows any hope of avoiding record
>terminators is with access='direct', in which case the records are
>fixed length.

	Thanks for pointing this out; I had thought RECORDTYPE='FIXED'
was a standard feature of OPEN, which I now see is not the case.

                 	John Whitmore