Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!proteon.com!jas
From: jas@proteon.com (John A. Shriver)
Newsgroups: comp.protocols.tcp-ip
Subject: FTP "STRU VMS" extension
Message-ID: <8902231555.AA23173@monk.proteon.com>
Date: 23 Feb 89 15:55:02 GMT
References: <38267@oliveb.olivetti.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 28

First, there is no /tmp in VMS.  Face it, /tmp is an arcane leftover
from when UNIX ran on machines that did not have virtual memory.

There is nothing really like pipes in VMS, especially at the command
level.  The syntax of the BACKUP command is also very awkward and
restrictive. 

ALso, a pipe would fail to solve the same basic VMS problem.  Files
are not just a sequence of bytes in VMS.  They have a lot of
attributes, attributes that must be preserved or the file is useless.
(It is better than OS/360, since the system always keeps track of the
attributes for you.)  Thus, the output of BACKUP, when sent throught a
pipe (or transferred via FTP) loses a key attribute: it's
extraordinary block size.

Also, as noted before, the output of the BACKUP program is not an
efficient format.  It has a very high degree of redundnacy.  You can
punch a 1/4" hole in a BACKUP tape and still restore from it.
Overkill for what will be transferred over FTP, which we trust more
than a tape drive.

The VMS folks have a real problem.  The binary abstraction of FTP just
does not hack it for their files.  You will find that they are not the
only OS that has addresses this, I think the UCLA MVS TCP/IP FTP
allows you to specify a bit of (moral) JCL before writing a file.

Let's let them agree on something to solve this problem.  Anything to
make the VMS users less anti-TCP.