Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!zpovc.DEC.COM!hwchoy
From: hwchoy@zpovc.DEC.COM (Heng-Wah Choy DEC Singapore SWS)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: FTP "STRU VMS" extension
Message-ID: <8902070655.AA02355@decwrl.dec.com>
Date: 7 Feb 89 06:55:40 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 104

> From:	DECWRL::"encore!pinocchio!bzs@talcott.harvard.edu" "Barry Shein  6-Feb-89 1136 EST"  7-FEB-1989 08:50
> To:	KASHTAN@IU.AI.SRI.COM
> Subj:	 FTP "STRU VMS" extension
> 
> Cc: braden@venera.isi.edu, tcp-ip@sri-nic.arpa
>  
>  
> What I don't understand is why this isn't taken care of extra-FTP by
> some sort of archiving utility like tar.
>  
	There certainly is. Its known as BACKUP.

> 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.
>  
	It does work.

> 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.
>  
	The reason is UNIX (I'm sorry) has a very simple file system and
structure. Correct me if I'm wrong but a UNIX file can be safely treated 
as a binary byte stream, isn't that so?

> 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.
>  
> 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.
>  
> Isn't this the scheme that Unix tar, Macintosh PACKIT, MS/DOS ARC etc
> have been using for years?
>  
> 	-Barry Shein, ||Encore||

	What Kenneth was asking for is an intelligent option where a VMS 
implementation of FTP will attempt to establish that fact to its 
counterpart. And if both parties are VAX/VMS then hey we can do things a 
lot faster and cheaper since we have some "mutual understanding". If 
not, then too bad, its back to the "standard FTP". Ken is trying to 
establish a standard for this "mutual understanding" among VMS/FTP ONLY. 

Your suggestion regarding the use of archival facility (ie BACKUP) as a 
pre-post processor is of course valid. But as some one else has 
mentioned, that pre-post processor takes time (cpu) and resources (read 
disk space). On VMS systems, disk quota are tightly controlled and if 
you don't have enough, its No Can Do. Eg if you retrieve a 1000 blocks 
archive file (in VMS its called a backup saveset), you need to have 2500 
blocks (1000 to keep the saveset, at least temporarily, and another 
1000+ for the files that will be extracted from the save set). 

For a long time, I was using Kermit to transfer files between 2 VAXes 
that weren't on the same DECnet. Now to transfer an indexed (read ISAM) 
file or a directory tree, I had to back it up then send it through 
Kermit in binary, and then restore it on my end. As I said, diskquota 
control can be a real restriction. (Most of the place wouldn't simply 
give you more disk space you know, you have to ask and justify for it). 
Besides there's the hassle of backing up the files and then restoring 
it. Not only that, efficiency on the wire suffers because BACKUP 
(unlike TAR) impose substantial overhead as it will keep lots of extra 
information about the files. This is to allow the recovery of data even 
when the saveset has some corruptions. Although I don't use much of 
UNIX, I know TAR's internal very well. It is nowhere compared to BACKUP, 
sort of comparing a Toyota to a Jaguar.

Ken, I am in favour of your STRU O VMS option. In which case, all OS can 
have such an option .. STRU O MVS, STRU O U43, STRU O EMBOS...

It does nothing to harm interoperability, as far as I can see. Its what 
the real world needed, if there's no standard then it'll just be 
non-standard features, so why not standardize it and make everybody 
happy?

Rgds,

Choy Heng Wah
Software Specialist

._._._._._._._.
|d|i|g|i|t|a|l|   Digital Equipment Singapore
._._._._._._._.

Disclaimer : What I express here is purely my own opinion and does not
             represent any policy of Digital Equipment Corp and its
             subsidiaries ... blah blah blah ...

EASYnet  : {zposws|zpovc|zpoact}::hwchoy
InterNET : hwchoy%zpovc.dec@decwrl.dec.com
	   <@decwrl.dec.com:hwchoy@zpovc.dec.com>  <-- source route addressing
	   hwchoy@zpovc.dec.com