Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!deimos.cis.ksu.edu!unmvax!ariel!sdowdy
From: sdowdy@ariel.unm.edu (Stephen Dowdy)
Newsgroups: comp.sys.dec
Subject: Re: DEC TCP/IP
Summary: UCX buggy/misfeatures/unfeatures (+benefits)
Message-ID: <2038@ariel.unm.edu>
Date: 23 Mar 90 18:42:14 GMT
References: <8240001@hp-lsd.COS.HP.COM> <6922@decvax.dec.com>
Reply-To: sdowdy@ariel.unm.edu (Stephen Dowdy)
Organization: University of New Mexico, Albuquerque
Lines: 69

In article <6922@decvax.dec.com> evans@decvax.DEC.COM writes:
)In article <8240001@hp-lsd.COS.HP.COM>, harmon@hp-lsd.COS.HP.COM (Bruce
)Harmon) writes:
)> ...
)> Areas of particular interest are the use of sockets, ftp, and NFS.
)> Performance and price relative to the Wollongong product would
)> be interesting.
)
)I use the product within DEC. I have used the Wollongong product in the past.
)I prefer the DEC product.
)...
)The ftp program is very simular to other ftp implementations, probably because
)the RFC doesn't leave much room for interpretation. You won't be loosing
)anything by using the DEC flavor.

FTP under UCX is less than perfect.  there is no MGET/MPUT facility.
(This i would consider a MAJOR drawback)  Also, i have had problems getting
UCX FTP to talk to CMU FTP.  I am not willing to say who's at fault here,
since i really don't know.  UCX FTP to anything else works fine, Anything
else to CMU works fine.  It is only UCX client/ CMU server (Ftp) that is
flaky.  (Symptom:  Nothing completes, including DIR,  It hangs at the end)

)I suggest the change, if for no other reason that the third party products will
)likely break  when DECnet phase V becomes available (I can't really say
)anything more).
)
)- Marc (An unbiased contract software hacker)

(Does the above statement seem to imply proprietary hooks?  Hardware LMF
in the Ethernet board to disallow other vendor software?... EEEKK)

Anyway, i was a CMU site until V1.2 UCX, where Telnet was supplied.
Since i am on ESL, and UCX is thusly "free", i went with it, since almost
all of our tcp/ip needs are TELNET oriented.  UCX Telnet has freed up
A LOT of cpu cycles (CMU Overhead) and runs pretty well.  (i found a bug
in the Rlogin/Telnet server that crashes the machine, but Alex Conta
at DEC helped debug it, and there is a patch now available)

There are quite a number of bugs/misfeatures in UCX V1.2, and it is the
least functional TCP/IP product available.  However, for us it is "free"
and runs pretty efficiently.  If you have money, the way i hear it,
Multinet is the most efficient and feature-ful product.  I would use it
if it were also "free". (or close to free)  I wouldn't be surprised if
UCX starts to get competitive though "in a future release".  the
addition of BIND in V1.3 will be a great blessing, and several of the
bugs/misfeatures i spoke with Alex@DEC about are due to be fixed in
that release.

As for wollongong...  I have run this on an 8650, and found it to be
less than likeable.  I have been flamed by a madman (:-)) before on
this, but my belief is that any product on VMS should do its best to
integrate with VMS.  That includes accepting ^Z as EOF, and having
a VMS CLD interface to software.  You may beg to differ...  WIn/VX
at least now has the protocol built into the driver, and hence is
on the same magnitude of performance as Multinet and UCX.  And i
regularly use the win/vx ftp on one of our machines to get CMU server
files, since UCX doesn't work that way.  I don't like the interface, and
given a choice of paying more for a better integrated package, would
gladly do so.

So, in summary, UCX has the fewest features, you should check to
see that you aren't giving up functionality in the switch, but
has the (perhaps) greatest "integratability" with VMS.  Multinet is
the highest performance and most featureful (doesn't appear to be
any more expensive than Wollongong)  Wollongong is the most
UNIX-ish (which i consider a great disadvantage) but then you already
know about win/vx.

-stephen