KLENSIN@INFOODS.MIT.EDU.UUCP (03/16/87)
Apologies, in advance, to the UUCP and BITNET readers of this list: this
is specifically a TCP/IP inquiry, but this seems to be the right place to
send it.
There seem to be considerable difficulties in FTPing VMS save sets, at
least without explicitly converting to and from encoded forms at each end.
Better conversion tools keep coming along, but are clearly an inelegant
solution. Given this, has anyone considered defining and RFC-ing an
extension to STRU, possibly with the use of SYST, to permit agreement
between the server and user FTP programs that a save set is coming and
should be handled accordingly?
It should be possible to reach agreement, either to define a special
character for the save set type (disadvantageous because it would
immediately lead to a request for similar things for other systems) or to
allocate a few extra STRU characters for, say, type A and B "sending
system archives". This latter convention would be general enough to
accommodate a variety of special operating system formats that don't FTP
and reconstruct easily (IBM NETDATA comes to mind). An (even-slightly)
intelligent FTP program could then request the operating system type of
the server with SYST and then either refuse the transfer or make the user
assert that it was ok anyway if the operating system types did not match.
I think this could be done as a sufficiently clean extension that hosts
that did not support the facility at all would simply return a 504 "not
implemented for that parameter", presumably what they do now if the
character is not F, R, or P.
Note that none of this contemplates any conversion of intrinsically
internal formats from one operating system to another -- just figuring out
a way that two systems that are known to be using the same operating
system and compatible host types can transfer file organizations that are
heavily used and highly supported in that operating system.
At present, the number of VMS implementation of TCP/IP and FTP is small
enough that they can be counted on the fingers of one hand and, to my
knowledge, none have made explicit arrangements for save sets. Unless
this type of feature is less important than I think it is, it would be
wise to try to standardize something before we end up with several
incompatible solutions.
If people want to send comments directly to me, I'll be happy to summarize
after a week or so.
John C Klensin, MIT
ARPANET: Klensin@INFOODS.MIT.EDU
BITNET/EARN/etc (if you have a working MAILER): as above
(if you don't): JCK@MITVMAMACALLSTR@vax1.physics.oxford.ac.UK (03/17/87)
With VAX/VMS and Coloured Book Software one can transfer any type of file from one VAX/VMS system to another by using the /CODE=FAST qualifier with the TRANSFER ( i.e. FTP ) command. That includes BACKUP savesets. The tools must be available, somewhere, to write that functionality into Unix,etc software. John
TLI%Sargas@USC-OBERON.ARPA (Tony Li) (03/17/87)
I find the suggestion of a separate option to FTP to add yet-another-feature to be distasteful, at best. Binary mode FTP is supposed to be able to deal with such things, since it passes data in a transparent manner. The only REAL problem is that FTP cannot handle the different file types that VMS supports/requires. This is a problem with VMS, not with FTP. Don't fix it by hacking on FTP. There are reasonable ways of encoding and decoding the proper FDL onto the binary file so that binary mode FTP will work properly. The need to standardize should be in finding a de-facto standard encoding, not in enhancements to an already overburdened networking program. Cheers, Tony ;-) -------
gmt@ARIZONA.EDU.UUCP (03/20/87)
For FTPing VMS save sets we use a trick based on an earlier posting by
H}vard Eidnes:
1. Fetch the save set using binary mode FTP.
2. Backup any handy file to create a trivial save set with the right block
size.
3. Use COPY/OVERLAY to copy the real save set on top of this one. The result
is a save set with the right data and attributes.
This requires no special encoding of the save set. This is a big advantage
to us because we don't need to distribute a decoder to people fetching from
us. Agreed, it would be nicer if this trick wasn't necessary, but it works.
Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 4325 gmt@Arizona.EDU 110 57 17 W / 32 13 47 N / +758m