Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!csd4.milw.wisc.edu!leah!itsgw!rpi!batcomputer!cornell!rochester!pt.cs.cmu.edu!cadre!pitt!cisunx!cmf
From: cmf@cisunx.UUCP (Carl M. Fongheiser)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: FTP "STRU VMS" extension
Message-ID: <15746@cisunx.UUCP>
Date: 10 Feb 89 02:18:44 GMT
References: <602233186.0.KASHTAN@IU.AI.SRI.COM> <8902061636.AA13703@pinocchio.UUCP>
Reply-To: cmf@unix.cis.pittsburgh.edu (Carl M. Fongheiser)
Organization: Univ. of Pittsburgh, Comp & Info Sys
Lines: 67

In article <8902061636.AA13703@pinocchio.UUCP> bzs@pinocchio.UUCP (Barry Shein) writes:
>How does one transfer ISAM (eg.) files by tape between VMS systems?
>Why can't a similar mechanism be used?  The obvious advantage is that
>such representations should even work when one wants to push such
>files through third-party, non-VMS systems since all the info to
>re-create the file gets bundled into the transferred file itself
>rather than relying on wire transmission as server/client commands.

Not a terrific example.  Normally this is done using BACKUP, but
BACKUP adds all kinds of extra gunk (like CRC's and ECC blocks) that
shouldn't be necessary for FTP.  Also, BACKUP savesets happen to
be some of the hardest things to transfer using FTP, since BACKUP likes
to create giant records (32,258 bytes by default for disk savesets),
and unlike tar, can't deal with the file if it shows up with a smaller
record size on the other end.

Naturally, VMS users have ways of dealing with this, but they're ugly
(probably uglier than the code required to deal with STRU VMS!)

>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.

Sure, and it works fine and dandy.  But tar came with your system,
and you didn't need any extra gunk to make that all work, did you?
It just happens that Unix files are nice, simple, easy beasts to deal
with.  VMS files aren't.  BACKUP makes it a little easier, but it really
is a big hassle to do something like that, since you can't directly
FTP a BACKUP saveset either.

>At best I could imagine some sugar in the VMS server/clients which
>might say "Hmm, that's a MUMBLE file, I'll spawn off a FROTZ command,
>send the result of that, and if the other side is a VMS site he'll
>recognize the header and automatically do the opposite", but none of
>that needs a change in the protocol spec since it only affects the OS
>interface, not the network interface (the file would just be xferred
>binary I'd guess.) Personally I hate that kind of magic.

OK, I'll bite here.  What if the file I'm transferring contains that
magic string or number which tells the FTP server/client to go into
the magic mode, but doesn't need the interpretation.  How do I turn
that off?

>No FTP extensions should be needed (eg. something like embedding UNIX
>magic numbers should do it.) And again, if the other side wasn't a VMS
>site it would work also (that is, would store the file image but make
>no attempt to unpack it.) A good example of the utility of this
>approach is putting VMS files for Anonymous FTP onto a non-VMS system.

Sure, but as I said above, you'd need some out-of-band way to turn it
off.

>Isn't this the scheme that Unix tar, Macintosh PACKIT, MS/DOS ARC etc
>have been using for years?

Sure it is, but all of those operating systems have comparatively
simple file formats, and all of those programs write nice, simply
formatted files themselves.  VMS is blessed with neither, and unless
someone's volunteering to write a program to do something like that,
I'd rather let the VMS FTP's have a little private magic to themselves.

				Carl Fongheiser
				University of Pittsburgh
				cmf@unix.cis.pittsburgh.edu
				...!pitt!cisunx!cmf
				CMF@PITTVMS.BITNET