Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!ENCORE.COM!bzs
From: bzs@ENCORE.COM (Barry Shein)
Newsgroups: comp.protocols.tcp-ip
Subject: FTP "STRU VMS" extension
Message-ID: <8902241549.AA08799@multimax.encore.com>
Date: 24 Feb 89 15:49:06 GMT
References: <8902231555.AA23173@monk.proteon.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 31


From: jas@proteon.com (John A. Shriver)
>The VMS folks have a real problem.  The binary abstraction of FTP just
>does not hack it for their files.  You will find that they are not the
>only OS that has addresses this, I think the UCLA MVS TCP/IP FTP
>allows you to specify a bit of (moral) JCL before writing a file.
>
>Let's let them agree on something to solve this problem.  Anything to
>make the VMS users less anti-TCP.

Ok, I can live with this but...VMS is a proprietary operating system
managed by exactly one corporation. I hear DEC is supporting or soon
to support TCP on VMS, do they have any proposals in this realm?

If DECNET solves this problem then DECNET over IP might be a better
way to deal with this issue as it simply provides a lower layer for
transport and any changes in the file attributes etc by DEC can be
punted to DECNET support, it can be the only layer aware of such
things and as long as the DECNET packets flow all should be well.

We *are* talking VMS<->VMS communications here, right? And at least
one vendor already offers DECNET over IP, so the only real question is
whether this combination already or could in the near future solve the
problem. I could see an encapsulation standard (RFC) for DECNET/IP as
a way to acheive this in a uniform manner among vendors.

At least that model could lead to dealing with other proprietary
systems and network protocols, as it has in the past (eg. RSCS over
IP, CHAOS over IP, XNS over IP, etc.)

	-Barry Shein, ||Encore||