VMS text files and cu

[Guy Harris]

>>What is worse is when one wants to transfer text files to the VMS system.
>>Neither cu nor tip knows enough to convert the newslines in the file to
>>carriage returns.  This definitely should be an option to tip. There are

>actually, I believe that VMS text files are REALLY different, not just
>adding a CR to a LF, but rather are usually what is called variable
>length records, where there is NO CR,LF at all, but rather the first
>two characters of a "record" contain a count of the number of
>characters in the record.  It is then the function of the utility trying
>to read these suckers to figure out what the line really is.  That is
>why in Eunice there is a unixtovms and vmstounix command, since it
>is not really obvious how to do something intelligent when you have
>both flavors of text files around.  What does this have to do with cu?
>Well, it tries to point out that rather then mucking with cu on the
>Unix system, you really should use a utility on the destination system
>that knows how to create a file of the appropriate type!  toodles.....

The way one normally sends a file from machine X to machine Y, assuming
one is running a "cu"-type program on machine X to turn machine X into
an "expensive dial-up terminal" to machine Y, is to run the moral equivalent
of "cat" on machine Y and have the "cu"-type program simulate typing the
contents of the file which is on machine X at machine Y.  In the specific
case, one would do something like

	COPY TT: DBA0:FROBNITZ.TXT

on the VMS system; "COPY" will read the terminal (TT:) and dump its contents
into "DBA0:FROBNITZ.TXT".  Since a terminal normally sends ASCII stream
text to the host, the fact that a "cu"-type program on UNIX will send
ASCII stream text while the OS on machine Y assumes counted records doesn't
make any difference.  RMS understands the difference between a terminal and
a text file, and will convert the record read from the terminal into the
appropriate form to pass through the kidneys of "COPY" into the bowels of
"DBA0:FROBNITZ.TXT".  Twiddling "cu"/"tip" to understand that the remote
machine doesn't have a UNIX-style TTY driver is fairly straightforward and,
as Mr. Sebok says, should be done.  It will solve the mentioned problem
completely.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy