Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!TGV.COM!adelman
From: adelman@TGV.COM (Kenneth Adelman)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  FTP "STRU VMS" extension
Message-ID: <890130182846.dd@TGV.COM>
Date: 31 Jan 89 02:28:46 GMT
References: <8901301937.AA00273@braden.isi.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Adelman@TGV.COM (Kenneth Adelman)
Organization: The Internet
Lines: 53


    I was hoping that I wouldn't have to defend the need for a "STRU VMS"
but here goes...

> The aproach you suggest works against interoperability and therefore must
> be approached with suspicion.  If STRU VMS, then also STRU MVS?  What if
> you want to FTP an ISAM file from a VMS to an MVS system? Is this
> infeasible?

    The idea is to provide a 'standard' way of transfering an arbitrary
VMS file UNINTERPRETED through the network. There are two reasons for this:

    1) Performance. Take your nearest VMS FTP and look at the ASCII mode
       performance as compared to the BINARY mode performance. Any
       transformation between VMS disk blocks and something like STRU Page
       is going to have a similar impact. The extra pass you have to make
       at the data can really matter on a small VAX.

    2) The need for such an extension to FTP is already recognized by
       many VMS TCP vendors. What I want is a 'standard' which will
       allow each of these different *VMS* FTP implementations to
       speak the same language.

    There is also another advantages to my proposal:

       Implementation of it is already very close to what most vendors
       provide in a non-interoperable fashion. Hopefully the small
       amount of work required to convert to the standard would
       encourage other vendors to adopt it as well. A standard without
       any implementations isn't any good to the community at large.

    This is *NOT* an attempt to solve a very difference problem such
as FTPing beasts like ISAM files between VMS and MVS. Even if FTP
contained a specification to allow any of today's VMS file types to be
FTPed, we're back in the same boat when DEC adds a NEW file type.

> Rather than extend the STRU command of ftp to add "STRU VMS", how
> about doing it through the SITE command instead?  From RFC959, pg 33:

    I'm aware of the SITE command, but my understanding was that
the SITE command was reserved for `non-standards', whereas this
proposal would only be useful as an extension to the protocol. As I
said above, I'm looking for more than just us to implement this.

    Perhaps what we need to add to FTP is a "STRU O VMS", where O is
short for operating system, and the resulting structure is the
VMS-specific one defined...

    I'm not sure this is appropriate to involve the entire TCP-IP list
in this discussion.  Anyone interested receiving copies of future
correspondance, please send mail to stru-vms-request@tgv.com.

							    Ken