Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!ames!sun-barr!newstop!texsun!texbell!news1
From: news1@texbell.swbt.com (Greg Hackney)
Newsgroups: comp.sys.ncr
Subject: Re: Tower Sys V.3 upgrade
Message-ID: <4655@texbell.swbt.com>
Date: 23 Jul 90 19:47:36 GMT
References: <4382@texbell.sbc.com> <4383@texbell.swbt.com> <282@fdls.odag.or.gov> <4482@texbell.swbt.com> <144@npdiss1.StPaul.NCR.COM>
Reply-To: root@texbell.sbc.com (Greg Hackney)
Organization: texbell gateway, dallas
Lines: 56

In article <144@npdiss1.StPaul.NCR.COM> steve@npdiss1.StPaul.NCR.COM (Steve Engelhardt) writes:

>WIN/TCP better than Excelan? 
>Hostip resolver funtion not implimented (nameserver)

    I think you are right. If I remember correctly, named and nameservice
    works okay, but the gethost*() functions in /usr/lib/libresolv.a
    weren't compiled to work with the nameserver. I remember grabbing
    code from uunet and replacing files in libresolv.a.

>limited FTP functions, sometimes get dropped when ftp to remote sites.

    My FTP works perfectly, only after changing the Time To Live (TTL)
    values in sys/ip.h and sys/tcp.h to "255" and recompiling. Before that,
    it was no-connect or partial service to long haul sites. NCR's factory
    set values are too low.

>********Excelan good points.
>Uucp to any machine on the network.

     But how many on the net could uucp back?

     Excelan didn't use a "standard" uucpd daemon based on Berkeley's
     port 540, but instead used a kludge to gain access on the login port.
     This included a daemon process alright, but for transmitting rather
     than receiving.

     Berkeley uucp sites on the net could communicate happily on
     port 540, but couldn't talk with NCR Excelan sites as there
     was no provision for uucp'ing binaries over telnet type ports.

     WIN provided networked only uucp via TLI/NLS, however. Too bad
     they didn't throw in uucpd, as it's easy enough to compile. Sun
     provides both UUCPD and TLI/NLS. I don't see anyone else trying to
     emulate Excelan's method.

>********Excelan bad points.
>SMTP is totaly unusable for Internet.

     Amen. Programs that incorporate Berkeley networking calls, like Smail3,
     can be made to run under Excelan, only with great pain. With WIN, it
     compiles and runs fairly easily. I never could believe what Excelan
     tried to do with sendmail by inserting "EXOS" in the middle of addresses,
     and replacing uux and rmail with their versions, to recognize "EXOS".

>Excelan is a decent product

     WIN proved better for my needs. Does NCR still sell and support the
     Excelan based TCP/IP product?

     I fully agree that NCR's WIN product needs more work on it. The
     things that come to mind are the resolver, sendmail, uucpd, RFS
     (or add NFS). I'm also having a lot of connect failures when
     using rsh. I'm unsure if that is a bug or a tuning problem.
--
Greg