Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!ucbvax!pinocchio.UUCP!bzs
From: bzs@pinocchio.UUCP (Barry Shein)
Newsgroups: comp.protocols.tcp-ip
Subject: FTP "STRU VMS" extension
Message-ID: <8902082217.AA08143@pinocchio.UUCP>
Date: 8 Feb 89 22:17:30 GMT
References: <602892098.0.KASHTAN@IU.AI.SRI.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 55


From: David L. Kashtan <IU.AI.SRI.COM!KASHTAN@talcott.harvard.edu>
>That has, in fact, been the solution for a LONG time.  Make a program that
>can PACK/UNPACK VMS Backup Savesets using files that can be transferred in
>FTP IMAGE mode.  Aside from various the system administration problems that
>have already been enumerated there is also a psychological implication.  The
>fewer steps you have to go through to get a file transfered the happier you
>are (witness the preference of "rcp" over FTP when available).  There have
>been many times that I have used slower file transfer methods just because
>it was less work for me (the difference in transfer times has to be pretty
>significant for me to prefer the more laborious method).  There is also the
>issue of ensuring that EVERYBODY you might want to exchange VMS files with
>has all the appropriate tools (isn't this what standards are for?).  As a
>TCP vendor we are very concerned about providing MAXIMUM functionality to our
>customers -- and this issue is of pretty serious concern to us.  So, rather
>than just DO something so that machines running our software can communicate
>in this fashion we have asked the TCP community to discuss the best way to set
>a standard so that we can interoperate with other VMS TCPs for this "extended"
>service yet still interoperate with the rest of the TCPs in the world.  I
>feel that Ken's suggestions are a good solution to the problem (but I am
>obviously biased).

(what's wrong with biased :-)

If it's a matter of saving steps why not just build a DCL wrapper
which does the job? Heck, Interlisp-D had what amounted to a very good
NFS based on vanilla FTP, required no changes to the server (eg. UNIX
or VMS) system as I remember.

>>It wouldn't really occur to me to ask for an extension to FTP to
>>transfer an arbitrary file tree between Unix's (for example), I'd just
>>bundle it up with tar and send *that* (possibly compressing and/or
>>uuencoding if need be.) In fact, that's SOP.
>
>But that is just the point -- UNIX files and FTP IMAGE transfer are a good
>match (i.e. they give you the functionality that you need).  We are looking
>to do something equivalent for VMS, where IMAGE transfers are not sufficient.

You missed my point. Unix directory trees and FTP IMAGE are *not* a
good match. You have to bundle it up with tar (or equivalent) first.

And saving/restoring file modes requires this even for a single file.

Maybe this gets closer to the heart of the matter, perhaps what VMS
really needs is an analog of Unix's RCP which can transfer directory
trees and preserve file modes. Why not a separate VMSCP utility for
VMS? At least that idea extrapolates cleanly to any number of OS's and
we can leave FTP alone to do what it was designed to, zap the bytes
from point A to point B with a minimum of interpretation (I'd be more
in favor of dropping TENEX mode from FTP.)

Just out of curiosity, how does DECNET handle all this (and, to go one
step further, is FTAM powerful enough to satisfy this requirement?)?

	-Barry Shein, ||Encore||