jimh%aubsch@mother.bates.edu (07/16/90)
NCR may consider it a "deal" to reduce the license fee for current customers, but I consider it a rip-off. As far as I am concerned, the cost should be the same $250 media charge as previous upgrades. This seems like another way to nickel-and-dime us to death. The result of this policy could very well be that they end up with two sets of customers to support, V.2 and V.3. They have made this same mistake over and over in the mainframe systems. I railed against the policy then, and will continue to do so. In my judgement, it will cost them more in dollars and customer good will than they can possibly gain in revenue. If this 'flame' upsets anyone, I apologize. ------------------------------------------------------------- Jim Hart aubsch!jimh@mother.bates.edu Dept. of Education Phone: 207-784-6431 P.O. Box 800, 23 High St. Auburn, ME 04210 "Happiness is a state of mind." USA
news1@texbell.swbt.com (Greg Hackney) (07/16/90)
In article <4382@texbell.sbc.com> jimh%aubsch@mother.bates.edu writes: >NCR may consider it a "deal" to reduce the license fee for current >customers, but I consider it a rip-off. As far as I am concerned, the >cost should be the same $250 media charge as previous upgrades. With a software service contract, the 'point issue' upgrades have only been the cost of the media. This was a new release, and my machine hadn't been under hardware or software maintenance agreements. For the price mentioned, I got the latest operating system, the compiler, man pages, accounting, troff, everything (not bundled). Also I got a full set of paper man pages in nice maroon hard binders with gold trim. In a similar situatuion, with my 3B2-310, a much smaller machine, AT&T charged me $600 to upgrade to S5R3. It contained only some basic stuff, like the operating system, & lp spooler. No compiler, accounting, etc. Also, they only sent loose updates to the man pages, not a full set of documentation. I thought NCR's 'deal' was wonderful in comparison. -- Greg
dougw@fdls.odag.or.gov (Doug Walker) (07/18/90)
In <4383@texbell.swbt.com> news1@texbell.swbt.com (Greg Hackney) writes: >With a software service contract, the 'point issue' upgrades have >only been the cost of the media. This was a new release, and my machine >hadn't been under hardware or software maintenance agreements. We have operating system maintenance, no hardware maintenance. Our NCR rep tells me that "I can get a real deal" at $750 to upgrade. He gave me a copy of the letter Greg Hackney mentioned. Frankly, I also think this is excessive. And, this doesn't even start to count the additional software outlays when existing software doesn't work with the upgraded operating system. In my case, I'll probably update one of these days (years) simply because our Data Base vendor always ports to the latest Unix release being marketed by the hardware vendor, and I'm already one version "behind" on the data base releases because their 03.xx port is not compatible with (will not run on) our 02.01.01 on a Tower 650. As long as the issue has been opened, what kind of performance change (if any) have users experienced when they went from 02.xx to 03.xx? I've heard (rumors, mind you) that additional swap space would probably be required (beyond the stock 10 mb under 02.xx) and that nothing is faster and some things are slower. I'd be interested in your upgrade experiences; both good and bad. Particularly changes in overall system performance and incompatabilities discovered with existing application software. -- ----------------------------------------------------------------------------- Doug Walker uunet!fdls!dougw -or- dougw@fdls.odag.or.gov Oregon Department of Agriculture, Salem, Oregon (503) 378-3790
news1@texbell.swbt.com (Greg Hackney) (07/21/90)
In article <282@fdls.odag.or.gov> dougw@fdls.odag.or.gov (Doug Walker) writes: >As long as the issue has been opened, what kind of performance change (if any) >have users experienced when they went from 02.xx to 03.xx? texbell, which is an overloaded byte pump, became more responsive with S5R3, I assume due to the addition of paging, although I didn't bother running any benchmarks. It has more idle time now, and programs like Elm run snappier. The main thing I wanted S5R3 for was for WIN TCP/IP. The Excelan package that NCR sold us was awfully crude in my opinion, and not suitable for use by a serious internet site. The WIN stuff is quite an improvement. Much of the BSD type of networking code will compile and run without much effort. I personally haven't gotten sendmail and RFS working to my satisfaction, but just got the software and haven't given up on it entirely yet. In summary, the major feature improvements for me were paging and WIN TCP/IP. If my system was not loaded, and I wasn't networking it probably wouldn't have been much advantage for me to upgrade. NCR, if you are listening, I'd be happy to be a beta test site for System 5 release 4.0. Someone was saying the other day (Interactive Communications Concepts, Houston, Texas) that the price for a full 4.0 release for a 386 was $5K. Wow. -- Greg
campbell@sauron.Columbia.NCR.COM (Mark Campbell) (07/21/90)
In article <282@fdls.odag.or.gov> dougw@fdls.odag.or.gov (Doug Walker) writes: >In <4383@texbell.swbt.com> news1@texbell.swbt.com (Greg Hackney) writes: > > ... > >As long as the issue has been opened, what kind of performance change (if any) >have users experienced when they went from 02.xx to 03.xx? I've heard >(rumors, mind you) that additional swap space would probably be required >(beyond the stock 10 mb under 02.xx) and that nothing is faster and some >things are slower. I'd be interested in your upgrade experiences; both good >and bad. Particularly changes in overall system performance and >incompatabilities discovered with existing application software. We have literally dozens of industry and proprietary benchmarks that show that release 3.00 is faster; however, the only thing most folks care about is whether ***their*** particular application is faster. I'd also be very interested in hearing about situations in which "...nothing is faster and everything is slower..." -- we'd like to pick those situations up to use in our testing so that it doesn't slip through the next major upgrade to an NCR system. You are correct about the swap space -- more is required under V.3. This was required to fix stress panic's and system hangs -- swap memory is accounted for a process when that process begins and not when swap memory is actually used. Note that this is swap memory (on the disk); not physical memory. With respect to the question in another posting concerning minimum physical memory required; if everthing else is equal, then you shouldn't need much more. One warning, however, most folks using V.3 on the 32/650 are tending to use more and more system and application packages -- this can cause the requirement for more memory. Some of this rumor has come from migration from the 6x0 to the 700 -- you do need more physical memory on this machine because of the larger virtual address space. The 700, unlike the 6x0, has a main-memory based MMU and requires significantly more MMU resources. -- Mark Campbell mark.campbell@ncrcae.Columbia.NCR.COM
steve@npdiss1.StPaul.NCR.COM (Steve Engelhardt) (07/23/90)
In article <4482@texbell.swbt.com>, news1@texbell.swbt.com (Greg Hackney) writes: > > > The main thing I wanted S5R3 for was for WIN TCP/IP. The Excelan > package that NCR sold us was awfully crude in my opinion, and not suitable > for use by a serious internet site. The WIN stuff is quite an improvement. WIN/TCP better than Excelan? ********WIN/TCP good points. Does function as a router. Provides full set of user applications (ftp,telnet,rlogin,sendmail,finger) ********WIN/TCP bad points. Hostip resolver funtion not implimented (nameserver) limited FTP functions, sometimes get dropped when ftp to remote sites. Sendmail implimentation crude. ********Excelan good points. resolver funtions properly. Rich set of FTP commands very reliable. Uucp to any machine on the network. Provides better network security. Has full set of applications (ftp,telnet,rlogin,finger) has rpr utility for remote printing to BSD or SYSV systems. ********Excelan bad points. SMTP is totaly unusable for Internet. cannot act as a router, Must set manual routing. Excelan is a decent product, WIN/TCP needs some improvements I hope WIN/TCP will be improved in the future, they can start with sendmail, then nameserver, maybe add whois nslookup ect. BTW, SYSVR3 is a much robust OS. There is a noticable impovement in response time. -- Steven Engelhardt NCR Comten steve.engelhardt@stpaul.ncr.com Development Computer Center, MS: S015 ..uunet!ncrlnk!ncrstp!ncrcce!steve 2700 Snelling Ave. N. StPaul, MN 55113 612-638-7223 NCR-652-7223 Do not try and adjust your set: We are controlling transmission.
news1@texbell.swbt.com (Greg Hackney) (07/24/90)
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
nick@toro.MTS.ML.COM (Nicholas Jacobs) (07/26/90)
>In article <144@npdiss1.StPaul.NCR.COM> steve@npdiss1.StPaul.NCR.COM (Steve Engelhardt) writes: > > 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 We had problems with interoperability between WIN-TCP machines and Excelan machines, particularly with rsh's. I was sent an update: WIN-TCP V.3 REL: 4.00.01 PROD ID: D900-1028-00CT from Codar. This release seems to be backwards-compatible with Excelan for rsh's. By the way, with respect to sendmail, I've gotten it to work, although I had to hack the rules. But it did interoperate with Sun and a DG iron we had on our net. If you're having any problems with it, feel free to drop me a line. Cheers, Nicholas Jacobs nick@toro.MTS.ML.COM, uunet!toro!nick, (212) 236-3230
guy@auspex.auspex.com (Guy Harris) (07/29/90)
> 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. No, they don't. UUCP in SunOS 4.1 runs only using UUCPD; there's no TLI support in 4.1's UUCP (I sure didn't put it in, and the other person involved with UUCP there says it wasn't put in). Prior to 4.1, there's no support for UUCP-over-TCP, period.
root@texbell.sbc.com (Greg Hackney) (07/29/90)
>> 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. > No, they don't. UUCP in SunOS 4.1 runs only using UUCPD; there's no TLI > support in 4.1's UUCP (I sure didn't put it in, and the other person > involved with UUCP there says it wasn't put in). Sun OS4.1 comes with RFS, including the network listener server programs (nlsadmin) used by Towers with WIN TCP/IP. The new Sun uucico program also has the same protocol ('e') used by WIN (in addition to 't'). But, you're right, TLI support was not added under the -i option of uucico. It's possible to get the Tower's WIN uucico to talk with the Sun's, with something like: --Systems.tcp-- Use address for port 540 sunsite Any TCP1 - \x0002021c84c82a13 --Devices.tcp-- TCP1,e tcp - - TLI \D tcp1 --Dialers.tcp-- tcp1 "" "" nuucp word: sunspassword And it's possible to get Pyramid's (att) uucico, and AT&T's uucico to talk with the Tower's WIN uucico with this: --Systems-- winsite Any TCP,e 1025 winsite "" NLPS:000:001:101\N\c However, I can't seem to get the above to work with Sun's 4.1 uucico. -- Greg
guy@auspex.auspex.com (Guy Harris) (07/31/90)
>Sun OS4.1 comes with RFS, Yes, I know, I was there when it was added.... >But, you're right, TLI support was not added under the -i option of >uucico. Yes, I didn't add it when I was working on 4.1's UUCP (I was doing it under 4.0, which didn't have TLI in it), and I asked the other person who worked on 4.1's UUCP, and he said it didn't support it.... >However, I can't seem to get the above to work with Sun's 4.1 uucico. Sun's 4.1 "uucico" tries to connect to a specified TCP port number; once there, it engages in a fairly standard "expect"/"send" dialog over the TCP connection (normally a login sequence). If you can talk to the listener that way, great, otherwise, you're stuck....