From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 14-AUG-1990 23:09:42.26
To:	MRGATE::"ARISIA::EVERHART"
CC:	
Subj:	Re: PBMPLUS problems with PCX and GIF files (STREAM files)

Received:  by crdgw1.ge.com (5.57/GE 1.70)
	 id AA27864; Tue, 14 Aug 90 22:57:16 EDT
Received: From EQL.CALTECH.EDU by CRVAX.SRI.COM with TCP; Tue, 14 AUG 90 18:56:07 PDT
Date:     Tue, 14 Aug 90 18:53:11 PDT
From: rankin@EQL.Caltech.Edu (Pat Rankin)
Message-Id: <900814184908.43c000a9@EQL.Caltech.Edu>
Subject:  Re: PBMPLUS problems with PCX and GIF files (STREAM files)
To: info-vax@sri.com

[ PC->VAX graphics problem due to PCSA, digressing into RMS internals :-]

>>      ...The default file type for PCSA is STREAM. The VAX C run-time
>>      library does not handle STREAM files correctly (it uses STREAM_LF).
>
> There is no such thing in VMS as a STREAM file.  A stream format is one in
> which records are delimited by certain particular characters or character
> sequences.  VMS supports three variations of stream format:  STREAM_LF (the
> most common, terminator is a LINEFEED); STREAM_CR (terminator is CARRIAGE
> RETURN); and STREAM_CRLF (terminator is a CARRIAGE RETURN/LINEFEED sequence).

     It's just stream, not stream-crlf, and stream format is a bit more
general than that.  Form-feeds are also terminators.  The RMS manual
lists FF, VT, LF, and CR/LF.  The Guide_to_File_Applications contains
conflicting info:  FF, CR, and CR/LF.  I haven't bothered to figure out
which--if either--is correct.  Neither is complete, since CR/FF is valid
and delimits a single record.

[...]
> Note that all three stream formats write the data to the file in exactly the
> same format:

      This is somewhat misleading, since the record terminators differ.
The internal format may be the same, but the file contents won't be.

>              All the bytes are there, and there are no extra bytes, as there
> are in a variable-length record file, for example, which contains record
> lengths.

     I'll stress a key point:  the line-feed and/or carriage-return is
_part_ of the data in the stream format files (and there is nothing
extra added).  For record format files, these control characters are not
[ordinarily] stored in the file, but other control information is.  That
control information is normally out-of-band; you don't see it if you let
RMS process the records.

>           This is also the same format as a fixed-length record file.

     This is incorrect (half the time :-).  Fixed-length records always
have word alignment; odd-length records are padded by a NUL byte.  If you
create a file with fixed-length 1-byte records, it will end up twice as
big as you expected ;-).

>                                                                        The
> differences among the four are entirely in how they are interpreted by RMS,
> which in turn is determined by the type, as stored in the file header.

     The file header can be modified, which will change the way that
the file is intrepreted without actually altering the file contents at
all.  I consider this a last-resort measure though.

     In the case at hand, you can read STM (cr/lf) files in as if they
were STM_LF, but your input data will include an explicit carriage-return
character at the end of each record so the program(s) must be prepared to
deal with it.  As an alternative, the following will copy the file into
stream-lf format:
 |$ CONVERT/FDL=SYS$INPUT: original.file converted.file
 |file
 |        organization    sequential
 |record
 |        format          stream_lf
 |^Z
This will work for converting either stream (cr/lf) or normal text files
(variable records w/ implied carriage control) into stream-lf copies.

                Pat Rankin, rankin@eql.caltech.edu