why learn UNIX

[levy at ttrdc.UUCP]

In article <408 at nitrex.UUCP>, rbl at nitrex.UUCP writes:
>Also, there are some things that just seem to be impossible with VMS.  We
>often deal with data files of long (2K bytes +++) lines.  We would like
>to transmit them via a terminal emulation (say, cu) into a VMS file.
>1.  It is not easy (read "baroque") to create a file on VMS that has
>a long line length.
>2.  You can't create the file via a terminal login.  VMS just won't take
>lines longer than some "small" limit (as I recall, 232 bytes) via a port
>it thinks is a terminal.

To be fair to VMS, the garden variety ~%put in cu also won't work for lines >
the UNIX terminal buffer size; neither will it work for files which don't
end with the eol character.  One has to play tricks with the tty settings.
Under the UNIX system, one would likely use UUCP to transfer such files
between machines.

>The "pure" byte stream philosophy of UNIX has been very nice to deal with.
>The DECShell under VMS can do no better in dealing with this problem than
>DCL does.

Recently (a couple of years ago?), a "stream-LF file format" was added to
VMS's endless repertory of file formats.  This format lets you have your
cake and eat it too with respect to byte-stream I/O, arbitrary seeking,
arbitrary "line length", and other things part of the byte stream philosophy
of the UNIX system, while still being acceptable as input to all other VMS
utilities that expect text files.  There is still the nuisance of having to
convert other text file formats to the stream-LF format to get full benefits
of the byte-stream philosophy when using them with VMS C programs.  The
implementation of stream IO and seeking under VMS C also leaves a LOT to be
desired efficiency-wise (I've seen a 3B2/400 do far better on a CDC WREN than
an unloaded VMS VAX 8650 does on an RA81 in applications requiring heavy
seeking).

>Disclaimer:  This reflects only my own opinion and not that of my employer.
>Rob Lake
>decvax!cwruecmp!nitrex!rbl
>ihnp4!cbatt!nitrex!rbl
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|            dan levy            |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
                                        allegra,ulysses,vax135}!ttrdc!levy