Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!ncar!ico!ism.isc.com!emisle!dvb From: dvb@emisle.uucp (David Van Beveren) Newsgroups: comp.unix.sysv386 Subject: Summary: What's wrong with SCO (long) Message-ID: <1991Apr14.022153.2099@emisle.uucp> Date: 14 Apr 91 02:21:53 GMT Sender: dvb@emisle.uucp (David Van Beveren) Organization: Emerald Isle Systems, Ltd. Agoura Hills, CA Lines: 1284 ======== Thanks to all the news readers that responded to my question. I grabbed some postings from the net, and combined with the mail responses I got, there were over 50 responses in all, from over 35 different people. The one-line summary is this: People who have SCO Unix are satisfied with it. Now, Everyone who wrote and said they were happy with it mentioned several bugs with the system. I guess this is probably true for any piece of software. However, my original impression that SCO is completely hopeless has been changed. I still feel that ISC would be better for software development, but SCO isn't really so bad for users of the word-processing type who just need a terminal. ======= Peoples opinion is that support for SCO unix seems to be better than ISC. I have never had a problem with ISC support, so I can't qualify that statement. ===== Since my original posting, my customer got SCO and is trying to install it. He is having a terrible time. bug: The TCP/IP was unlimited user license and the core was 1-2 user license. Installation of TCP barfed completely here and support told them to get the multi user core. $$. Nice touch. ============================================================================= Major Bugs Noted: ================ 1. Security system - Apparently, the C2 security features get in the way of doing many things conveniently: The main complaint with SCO unix is the alleged security features. They make it very, very difficult to get some types of work done. Setting up cron jobs, and starting non-root daemons, and verifying that users know passwords, and preparing at jobs, and doing setuid calls all seem to have problems. Starting cron doesn not work from a terminal. 2. Make - One respondent noted that you cannot do a make when the sources are mounted via NFS. The date-dependency checking gets all screwed up. 3. Curses cannot handle 8-bit characters. 4. Disk performance slower than other competitors. 5. X server supports only 16 colors. 6. Finger does not report correct information regarding permissions on a tty. 7. Getty release 1.0 would accept a RETURN at the wrong bps rate and act as if a BREAK had been received. This was "fixed" in 2.0, making login more difficult for users using a bps rate different from the default rate. (A modem that supports dual bps rates solves the problem since the modem and computer always talk at the same rate.) 8. 14 character file names could not be renamed. An SCO patch fixed this. 9. Release 1.0 of the system admin shell did not permit some account information to be changed, contrary to the docs. 10. The C shell lacks features I expected. This is not a software bug, though. 11. Permissions for several directories are wrong. Some email packages (elm), UUCP and Usenet software may not work without the permissions being corrected. 12. SCO's docs for configuring MMDF, the mail agent, leave a bit to be desired. (A major understatement.) After finally (I think) figuring out MMDF, it works quite well. 13. When I decided to install the network modules (TCP/IP, Ethernet...), the system refused all logins, even from root. I had to scrap it all and start over. 14. Several bugs appeared when I set the login shell for root to be /bin/csh instead of /bin/sh. 15. Some day, for no apparent reason, root started getting invaded by E-Mail messages from cron complaining about a bad HZ value. 16. - Limited to only 4 SCSI harddrives. We went to SCSI under Xenix because it would allow something like 14 drives in a system, and now Unix allows only four. With 1G drives getting cheaper, this may not be a problem, but I liked the notion of a 14G 386 box. :-) 17. - SCO's NFS doesn't seem to be completely compatible with HP's NFS (the only other NFS system we have). I've heard it has trouble with other's also. 18. - SCO tried too hard to retain a "Xenix feel" to some of the sys admin stuff, meaning that some things might be "in their Unix place" or "in their Xenix place", or sometimes (the worst of all), in both places (e.g. start up stuff can be done with either Unix's rc2.d scripts, or Xenix's rc.d scripts). 19. I would first say don't use tar, it skips empty directories, and they may be needed to make things work. A new version might have cured that, 20. Debug and line numbers is screwed up for cc. If a file (foo.c) contains embedded #line directives from more than file, you get all sorts of warnings when compiling and/or linking. I've pretty much given up on trying to track down the precise cause. 21. Problems with Trailblazer 9600Baud Modem (Recent news thread) 22. Daylight savings time not working correctly. (Recent News Thread) Original Posting: ================= >There has been a lot of talk about how horrible SCO Unix really is compared to >other PC Unixes. I have used ISC for 2+years and am relatively happy. Today a >customer told me he wants to order SCO. My first thought was OH NO, its full >of bugs, and generally horrible. Then I started thinking, and realized I don't >know what these bugs really are, if they exist at all. > >Please send me descriptions of all SCO bugs you know about. I want to know how >bad this product really is. Also, if you think it is great, let me know. I hope >I get lots of mail on this one. I will give it a week, then post my findings. >Please, give me some dirt I can use to convince my customer to get ISC. I know >it is what I want, I just don't know why :-) > ================================ ronald@robobar.co.uk (Ronald S H Khoo) aw1@stade.UUCP (Adrian Wontroba) wht@n4hgf.Mt-Park.GA.US (Warren Tucker) flon@pollux.usc.edu (Scott Simpers) Ian Geoffrey Sergeant Jack Cloninger steveo@world.std.com (Steven W Orr) Michael Squires sixhub!davidsen@crdgw1.ge.com (Wm E. Davidsen Jr) Erik Fortune (Dean Roth) cellar!toad@uunet.UU.NET laurana!ppaone@uunet.uu.net (Phil Paone) fred@cdin-1.COMPU.COM (Fred Rump) "Robert E. Laughlin" count!chip@uunet.UU.NET (Chip Salzenberg) Ian Searle (uw-beaver!sumax!polari!ian) drolet@drolet.cam.org (Jean-Jacques Drolet) rhealey@digibd.com (Rob Healey) macleod@cmllab.rgb.sub.org (Connor MacLeod) rbraun@spdcc.COM (Rich Braun) paulz@sco.COM (W. Paul Zola) steve@edm.isac.CA (Steve Hole) rk@theep.boston.ma.us (Robert A. Kukura) jim@tiamat.fsc.com (Jim O'Connor - IT Manager) davidsen@sixhub.UUCP (Wm E. Davidsen Jr) lerman@stepstone.com (Ken Lerman) tanner@cdis-1.compu.com bernd@pfm.rmt.sub.org (Bernd Hennig) sl@van-bc.wimsey.bc.ca (Stuart Lynne) gt2186a@prism.gatech.EDU (COBIA,FRANK NAYLOR) john@sco.COM (John R. MacMillan) chip@chinacat.Unicom.COM (Chip Rosenthal) newbery@stout.atd.ucar.edu (Santiago Newbery) macleod@cmllab.rgb.sub.org (Connor MacLeod) ptran@hydra.unm.edu (Michael Burg) Michael Squires gemini@geminix.in-berlin.de (Uwe Doering) tim@dell.co.uk (Tim Wright) iverson@xstor.com (Tim Iverson) scott@phlpa.UUCP (Scott Scheingold) Responses with minimal edits (Long): ================================ ronald@robobar.co.uk (Ronald S H Khoo) SCO's 3.2.0 Dev Sys terminfo curses seems to go crazy (*) when fed 8 bit characters -- Does anyone know if it's fixed in the rev 2.0 Dev sys, and if so, does anyone know how much the upgrade co$ts, and more importantly, what the part number is ? (I got a *real dumb* supplier -- quoting part numbers is the only way to get any sense out of him -- and don't ask me to change suppliers -- managment directive sez "buy from this sister company or else buy nothing" :-( ) Thanks for any help. -- (*) "crazy" in this sense: with this program - $ cat foo.c #include main() { initscr(); addch(0243); refresh(); endwin(); } $ cc -DM_TERMINFO foo.c -ltinfo I expect a pound sign on an ISO Latin 1 terminal, or a u-acute on a PC console. Instead I get a flashing blinking screen full of carets. Sigh. Strangely enough, it *does* work when I add a -xenix flag, but then GDB doesn't. Sigh. =============================== From: aw1@stade.UUCP (Adrian Wontroba) I believe that the dev system upgrade costs approximately 200 pounds. I'm afraid that I do not know if it will fix your curses problem, nor the part number. Phone SCO and ask? ================================ From: wht@n4hgf.Mt-Park.GA.US (Warren Tucker) The bits above the 0x80 bits are attribute bits in 3.2 curses and include blink, underline and color. Look at /usr/include/tinfo.h at the A_..... definitions and the man page for curses. There is an A_ALTCHARSET bit you can set, but you may utlimately be disappointed in using the high 128 video characters. I only tried for three days before giving up (wanted to use the ruling characters). I tried the 'acs' stuff and everything else in TFM, terminfo.src and header files, but with no luck. I am still interested in doing this one day. Until then, I use the termcap curses, which does not support color or a host of other nice things, but you can write any video ROM character from 0x20 to 0xFF. ====================== From: flon@pollux.usc.edu (Scott Simpers) Organization: Quality Software Products We are having a peculiar problem with sendmail, and I would appreciate any ideas, suggestions, or solutions. Sendmail is running on an SCO ODT 1.0 system, which is our UUCP gateway. The problem appears sending UUCP mail from other hosts on our Lan to UUCP sites. It works fine delivering, via SMTP, to all our local machines, and sometimes works OK when sending, via UUCP, to other hosts. The probem is that it will someimes get into a state where it says "Cannot exec '/usr/bin/uux' errno=13". This doesn't seem to be a problem when sending UUCP mail from the local (ODT) system, but rather when another systemon our networkis attempting to get it to send UUCP mail. Once it gets into this state where it will only send local UUCP mail, the only solution appears to be to kill and restart sendmail. The permission on /usr/in/uux are: ---s--x--x 1 uucp uucp 63408 Dec 09 1989 /usr/bin/uux so it should be runnable by anyone. I have run out of ideas. Please reply via email, and I'll summarize for the net if anything useful surfacs. Thanks. ========================= From: Ian Geoffrey Sergeant it supports X11R4, and motif no problem. if i had to say some single thing that annoys me about SCO it would be the attempt at providing security and auditing. the existance of a login uid stops things like su, cron working as they should, without providing any additional security. this couldn't really be considered a bug, more a misfeature. ian. =================================== From: Jack Cloninger Although there were one or two annoying little problems with early versions of SCO Unix, these were cleared up with release 3.2 version 2.0. This is an excellent Unix implementation. I have been using SCO Unix for over a year now, and the 2.0 version for several months. I have had no problems at all. SCO supplies hardware drivers for a wide range of peripherals and they supply an excellent development system. I've been very satisfied. I now work for a company that sells SCO products, but I purchased SCO Unix for my home machine while working for a company that had no connection whatsoever with SCO products except that we used SCO Xenix for cross-development work. My experience has been overwhelmingly positive, except that SCO support seems to be overwhelmed so that when you do have a question or problem it can take a while to get help. Also I am not too thrilled with the cost of SCO support. The Unix is great though. I have been using Unix in one implementation or another for over 12 years, starting when I worked for Bell Labs in 1979. Hope my impressions help. ================================================== From: steveo@world.std.com (Steven W Orr) I can give you lots of input on both sides of this issue. I personally favor SCO. If you want you can call me 617-327-3083. There are a lot of really good reasons to go with SCO. I am in the middle of convinceing a client right now to throw his ISC stuff away and purchase new SCO licenses. -- ======================================= From: steveo@world.std.com (Steven W Orr) BTW: ISC and SCO are both based on X11R3. The only way to get to R4 is to build it yourself or by something thats not 386 based. ======================================== From: Michael Squires UNIX is X11R3 and Motif 1.0, I believe. There are X11R4 servers but they are not supported by SCO (third-party commercial versions are available, I believe). ========================================= From: Michael Squires I run ODT 1.0, upgrade UFE; upgrading to 1.1 next month. Negatives: reviews and others' experience suggest that SCO's disk drivers are slower (see Personal Workstation review). The security system is a nightmare if you are not used to it, could be a real plus if your system is attacked. Pluses: SCO now the most heavily supported by software vendors; $495 gets you into the developer's program, then get email answers from SCO tech staff on your problems; current releases seem to be pretty solid (my system is connected to the Internet, MMDF is MUCH better than sendmail for mail, works with lots of hardware (I'm running a 486/25 genuine clone using the AMI BIOS and OPTI chipset). I don't think there's much difference now; main difference will be for the user if applications exist for which the vendor won't guarantee operation on a non-SCO box. SCO is quite surprised at acceptance; seems to be a lot of Fortune 500 interest. I did not buy ISC because of the horror stories about lack of support; SCO has been quite good in responding to my requests. ============================================================ From: sixhub!davidsen@crdgw1.ge.com (Wm E. Davidsen Jr) The biggest problem was the overly strict security. The recent SCO SLS fixes almost all of that. The only other bad thing is X11R3, and that's not going to change for a while. =========================================================== From: Erik Fortune SCO Unix is fine. I've been running Open Desktop for over a year and I was quite surprised at how "real" a unix it was. I'm from the workstation world and I was expecting some bizarre hybrid thing. The system is missing a few things I'd like, but SCO claims they're on the way and I believe them. ODT1.1. has job control (I should be upgrading in the next week or two). An update to 1.1 sometime this year should add long filenames and symbolic links. X server performance is adequate, but they only support 16-color mode for most VGA and SVGA's. I write X servers for a living, so I don't mind that much -- your mileage may vary. I've heard rumors and I expect SCO's X server to get *much* better later this year. Consider that vapor for now, of course. Some things about SCO are "different" from what you'd expect right away (e.g. MMDF vs. sendmail). For the most part I've found the "different" thing to be better once I learn it. If you have a network with 200 machines, one oddball might be annoying. If you have one machine, I think it's easier to administer SCO. Lots of people complain about C2 security, but I haven't had a lot of problems. My machine is personal and pretty well isolated -- things may be different in heavily used multi-user systems. I don't know. SCO support has been wonderful! My support number has long expired but I always get prompt useful answers to bugs I report to support@sco.com. Several times I've asked a question on a newsgroup or mailing list and gotten phone calls (!) from SCO support to help me out. All in all, I recommend SCO. I haven't really used other PC unices in years (since System III), so I can't really comment on SCO vs. other systems. ========================================================== From: (Dean Roth) I'd rate SCO as "average." Release 1.0 had some bug. Release 2.0 has some bugs. I've found a few. None that I've run into have been devastating, though some have been irritating. Finger does not report correct information regarding permissions on a tty. Getty release 1.0 would accept a RETURN at the wrong bps rate and act as if a BREAK had been received. This was "fixed" in 2.0, making login more difficult for users using a bps rate different from the default rate. (A modem that supports dual bps rates solves the problem since the modem and computer always talk at the same rate.) 14 character file names could not be renamed. An SCO patch fixed this. Release 1.0 of the system admin shell did not permit some account information to be changed, contrary to the docs. Many people have complained about the C2 security "features" and lack of information and/or tools to override them. Tools are being provided. Thus I do not classify as a bug, but a major irritant. The termcap and terminfo entries for a vt102's arrow keys were different in release 2.0. The C shell lacks features I expected. This is not a software bug, though. Permissions for several directories are wrong. Some email packages (elm), UUCP and Usenet software may not work without the permissions being corrected. Otherwise my SCO system has been running smoothly for a year. Increasing the amount of disk space from 330MB to 660MB (from 1 drive to 2) and rearranging the file systems helped a lot. (I made volatile directories into separate file systems.) This is a std. UNIX config problem, though, not something unique to SCO's UNIX. SCO's docs for configuring MMDF, the mail agent, leave a bit to be desired. (A major understatement.) After finally (I think) figuring out MMDF, it works quite well. Overall I've had FAR FEWER problems with SCO's UNIX than with Sun's early 386i machine - which would crash and burn regularly. Particularly if the MS-DOS emulator was used. =============== From: cellar!toad@uunet.UU.NET I dunno. We've been running SCO Unix for about 3 months, and there are two kinda irritating things we've encountered. One, SCO's MMDF is hard to implement and doesn't work as installed due to permissions problems. Two, we've crashed twice, we believe due to power failures, and when the system comes up automatically, people can't log in; they get a "can't find database information for your terminal" message. This is a SCO-specific security, it seems. We haven't gone too far in trying to resolve the problem yet, but it's especially irritating to us because we're running a public-access site. I mean, of all files to consistently be damaged after a power failure... ========================= From: laurana!ppaone@uunet.uu.net (Phil Paone) I rarly run across a "real bug" with SCO UNIX. There are some shortcomings though. First, the X server only supports 16 colors, no matter what the HW is. Another problem is the size. To load a full OS and Dev System, you need at least 200MB. For just the OS, at least 90MB. There are no shared libraries for the X libs. The standard utilities are not linked with the c shared libraries. It also needs alot of memory for things to work nicely. I have *only* 8 meg and things can get very slow with all the swapping. I have some other problems, which may be hardware related. Sometimes, the serial port will start babbling with the serial port on the connected machine. SCO denies this exists, but when it happens both machines stop. Sometimes the video display crashes when I use my tape drive. But, I do like the system. For what you get it is a good buy. With the basic ODT setup, you get X Windows, Ingres, a full UNIX (single user) and fairly good documentation (including on-line man pages). One more thing, there is a new release of ODT due out now. We have ordered it and are waiting. This is supposed to fix some of the annoying problems I mentioned in the first paragraph (alas 16 X server is not one). ========================= From: fred@cdin-1.COMPU.COM (Fred Rump) You ask about SCO UNIX. We are encouraging our Xenix users to convert at an appropriate disk enlargement or change time. No hurry here. At the same time all of our new sales go out as SCO UNIX. We really have no problems with it. fred ================ From: "Robert E. Laughlin" I am not a great guru. I am just a user. I have had sysv 3.2 from SCO for 18 Months and 3.2v2 for the last three months. I have had problems, yes, but, most of those were because I did not RTFM. The few problems that I had were responded to quickly by SCO at support@sco.com with either a fix or a work around that was not bad. For example, there was a problem with lpr in SysV 3.2 that I found. They sent me a copy of the lpr from Xenix that did not have the problem. SysV 3.2v2 does not have the lpr problem, incidently. I see a lot of flames about problems with SCO, they appear to be either a guru like Chip Salzenberg (sp) or some body like me that could not be bothered to RTFM. ========================== From: count!chip@uunet.UU.NET (Chip Salzenberg) No dirt for scum. (Editor's note: I am not sure if this is some kind of bug or an atack on me) ========================== From: Ian Searle (uw-beaver!sumax!polari!ian) Hello, in response to your survey question: I have SCO UNIX 3.2v2.0 (started with 3.2.0) OS & DS om a 386/25 with fpu, 14 inch VGA, NO X. bugs: Had some problems with `cc' but learned to use rcc, and then saw the light and picked up gcc (yay GNU). The problems I was having with SCO/Microsloth cc, ld, cvtomf were fixed for the most part by a SCO SLS (support level supplement), which are free for the asking, and/or UUCP. I have picked up other SLSs but never because of a bug, mostly just to keep current, and get things like dialer programs for 9600bps modems. Overall I am happy with SCO, I do not pay for support, but even so they will send me floppies with the SLSs on them and talk to me if I have an SLS related problem. My system has been very reliable, but I must admit I do not use it in a work environment. The machine is not on 24-hours-a-day and supports only me. I still don't know whether I should thanks SCO for not including X, or be mad at them, maybe X will go-away and leave us all alone, I get all the functionality I need with Emacs and multiscreens. It seems obscene to occupy 50% of RAM with maintaing the display. Overall I am very happy with SCO UNIX, the C2 stuff doesn't bother me at all, and the product has been very reliable, BTW Korn shell is GREAT. ========= From: drolet@drolet.cam.org (Jean-Jacques Drolet) Our Institute had SCO Open Desktop running on one of its computers for a few months. The core of Open Desktop is SCO Unix. This product has the potential to be a great operating system, but it has several problems which made us switch back to SCO Xenix. Its mail system, for example, is MMDF. This is a powerful and flexible mail transfer agent, but its maiboxes are incompatible with those of the more standard sendmail delivery agent; it insists on separating messages with non-printable characters which confuse several public-domain programs. When I decided to install the network modules (TCP/IP, Ethernet...), the system refused all logins, even from root. I had to scrap it all and start over. Several bugs appeared when I set the login shell for root to be /bin/csh instead of /bin/sh. Some day, for no apparent reason, root started getting invaded by E-Mail messages from cron complaining about a bad HZ value. The absence of a C compiler from the basic system is also annoying. SCO wants you to pay a premium for its development system, which contains several modules that an average user doesn't need. Why don't they sell a moderately-priced basic development system similar to that on Xenix? ============ From: rhealey@digibd.com (Rob Healey) First, anybody who knows anything about SCO knows that the ISC/ESIX zealots fail to mention their complaints are agaist an OS that was replaced well over a year ago, 3.2v0.0 SCO UNIX. SCO UNIX is different from ISC and the other UNIX's, that's the main reason everyone loaths it. I like SCO UNIX MUCH better than ISC, ISC feels like a rickty old bridge that's about to give way to me. The ISC drivers strike me as being ragged and unreliable. Fast wrong answers instead of timely correct ones, I know which ones I'll choose. I evaluated SCO UNIX 3.2v2.0 against ISC 2.2 last December to decide which should go on our main box. ISC's SCSI driver kept hanging the system or panicing, ISC's fix was to up the internal system V file system buffer constant which only delayed the problem, not fix it. The support for SCSI tape was pathetic at best. Alot of the utils felt ragged and incomplete to me, I'm comming from the high end UNIX level NOT the PC level used to all sorts of bugs as being "normal" operating procedure. While ISC may be somebody's idea of nirvana it is DEFINITELY not my idea of it. ISC's attitude on fixing the SCSI problem scared the shit out of me support wise, they brushed off the problem as a side effect of cockpit error. I've delt with Sun, DEC, IBM, AT&T, Apple and tons of software vendors in the past, NONE scared me like ISC. 2 months after I said fly with SCO UNIX, and everyone in the dept. said I was crazy to pick SCO over ISC, the imfamous bug came out that would have left our source code wide open to anyone... Quite a few ISC zealot's had egg on their face and my decision was finally accepted as being reasonable. SCO UNIX 3.2v2.0 on the otherhand worked fine with our SCSI setup, tape support was good, the utils don't feel like rickety old bridges and the system gives me a comfortable feeling that there isn't a nasty kernel/driver bug lurking out there... SCO UNIX requires you to take a week or two, REALLY read all the manuals and learn it. Once you learn it, it's as good or better than the other UNIX offerings. The next release will allow you to finally chuck the $%^%$^ C2 security BS. The SLS's basically have nullified the effect of C2 except for people who have to program /etc/passwd code. V3.0 will fix that too. V3.0 will also have symlinks and a flexname filesystem, all the features a sysadm could ask for... I would say sit down and take a good look at 3.2v2.0 SCO UNIX, it's not as bad as it's made out to be. ======== From: rhealey@digibd.com (Rob Healey) ISC doesn't currently ship X11R4 either, ODT 1.3 will be X11R4 based but I'm not sure about the braindead Motif stuff. I also thing OpenLook is braindead so don't attack. Real UI don't tell ME how I should think or do my work, they give me the pieces and *I* decide how they go together. Anyways, my workstation is running SCO UNIX 3.2v2.0 with 3.2v2.0 development and NFS 1.0. I've added gcc and gdb because I can't stand sdb and the two normal compilers aren't ANSI enough for me. I run X386 with a Tseng labs ET4000 based card and a NEC 3D monitor. Unfortunately, I am stuck with a VERY old version of TCP/IP so the socket based X connections are shakey when huge amounts of data is xfered. I run TCP/IP 1.1.0 over 56K SLIP to our main box. The STREAMS pipes work fine. So, X386 DOES work with the most recent SCO UNIX and development system. Assuming you have Motif 1.1 source you could get that working as well. SCO UNIX allows you to mount DOS disks as normal file systems, good for bulk work that doscopy would be tedious with. VPIX works great, even under X386. User level code and applications work fine except for passwd manipulation, then C2 security gets in the way. Non-SCO Kernel drivers may or may not work right, depending on what they need to do. DOS cross development works great. SCO seems to support any known SCSI or disk device that pretends to be a standard WD device, i.e. IDE controllers. I use 2 IDE 80M drives in my workstation and our main box is a SCSI Adaptec 1542b with 1 Wren 1.2G drive and 1 Wangtec DAT tape backup. Other boxes around here uses EDSI controllers with no problem. Man pages are layed out differently but you can get used to that after a while, you can also add the man.[1-8] dirs if you really need them. I think SCO get's more bad press than is really warrented, ========== From: macleod@cmllab.rgb.sub.org (Connor MacLeod) In article <1991Mar22.211749.13292@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) wrote: | SCO's 3.2.0 Dev Sys terminfo curses seems to go crazy (*) when fed | 8 bit characters I think that's a problem of the addch(). Use addstr() instead and it'll work. This "problem" is _not_ fixed in SCO U DEV 3.2.2. ========== From: rbraun@spdcc.COM (Rich Braun) I've gotten several criticisms for my posting inquiring about the identity of the person quoted below, and I'd like to set the record straight. Unfortunately the tongue-in-cheek nature of my posting didn't come across at all; netnews can't possibly read the expression of one's face as a posting is made, it only quotes the verbal statements made. In my own defense, I'd like to re-quote the original article and ask just how professional it really seems. It was basically a presumptive attack on SCO, and my posting--contrary to some of the complaints I've received--was intended to deter unwarranted attacks on vendors. I say it was presumptive because the writer states he's not an SCO user himself. Having been challenged before whenever I've criticized software that I've not personally used, I've posted a challenge to this writer. And I think a good healthy dose of skepticism *is* warranted whenever information of interest to corporate marketing departments is posted or requested on the Internet. The Internet's mandate is to provide a free flow of information necessary for the research environment. Conflicting with that goal is a need for security of information within the real-world business environment. The only way for Usenet/Internet to prosper is to balance these needs carefully. It's my assertion that the posting below showed blatant disregard for the ideals of the Internet, as I've interpreted them. Naturally, people are free to disagree with my presumptions regarding these ideals. At the very least, I have to admit that I was offended when I first read the posting, even though I'm no particular fan of SCO (after all, I have to *use* it every day!) =========== From: paulz@sco.COM (W. Paul Zola) The Colorado Memory Systems JUMBO tape is not supported by any SCO driver. The QIC-40/QIC-80 driver will not work with this unit. This driver supports the following drives for ISA class architectures: Vendor Qic-40 ====== =============== Alloy APT-40/Q Mountain TD44-40 Tecmar QT-40i Wangtek FAD 3500,3040F While tape driver support is a very fluid thing, I am reasonably sure that any floopy tape not in this list will not work with the QIC-40 drivers supplied with ODT. I believe that CMS has a driver for SCO UNIX systems: you'll have to contact them to obtain a driver for your unit. ============================ From: steve@edm.isac.CA (Steve Hole) > > Sendmail is running on an SCO ODT 1.0 system, which is our UUCP > gateway. The problem appears sending UUCP mail from other hosts on > our Lan to UUCP sites. It works fine delivering, via SMTP, to all > our local machines, and sometimes works OK when sending, via UUCP, > to other hosts. > > The probem is that it will someimes get into a state where it says > "Cannot exec '/usr/bin/uux' errno=13". This doesn't seem to be a > problem when sending UUCP mail from the local (ODT) system, but > rather when another systemon our networkis attempting to get it to > send UUCP mail. Once it gets into this state where it will only > send local UUCP mail, the only solution appears to be to kill and > restart sendmail. > OK, Scott, you are not going crazy. I have noticed the identical problem, except that I am running smail v3.19. First of all let me refine the occurrence of the problem a little. The problem occurs on our machine under the following conditions: 1. If I start sendmail from the rc as a an stmp daemon with the following arguments: /usr/lib/sendmail -bd -q1h the any messages recieved via SMTP and routed to an external connection via uucp will fail with a similar error message to the one you show above. If I kill the daemon started by the rc, and run it from the command line, everything works fine. 2. If I start smtpd via inetd.conf, it fails similarly every time. Therefore, it would seem that smtp daemon processes started without a controlling terminal cannot execute uux. I have absolutely no idea why. Perhaps something in the environment of a process started from a shell command line is required and not present when started from either the rc or inetd. For the longest time, I thought that it was some subtle bug in smail that was causing the problem, but I no longer think so. The reason for the change is that I have noticed several other intermitent problems with the SCO Unix (both v3.2 and v3.2.2) uucp distribution. Here are some of the problems that I see regularly occurring on the SCO Unix machines we maintain. Please note that all of these machines we are using either /usr/lib/uucp/dialTBIT or /usr/lib/uucp/dialHA24 as the dialer. The serial ports are standard UARTS that come with the machine (not a smart card). 1. When ever cu or uucico dial out over a serial port that is running /usr/lib/uugetty on it, as soon as uucico or cu acquire the port, the open succeeds for uugetty as well! Doing a ps -e shows that both uugetty and the dialer have acquired the port, and they proceed to fight for the data on the port. This causes the uucico or the cu to fail regularly. 3. The Sysfiles file does not function. If you try to use it, uuname, cu and uucp refuse to recognize that the system names exist. Uucico does recognize the name though, as you can slam a poll to the sites named through the Sysfile. The equivalent configurations worked perfectly under Xenix. So I went looking around, and to my surprise, I found that every single binary in the uucp distribution is a Xenix binary (Microsoft a.out separate pure segmented word-swapped 386 executable). Now I put on my theory hat. I have had problems in the past with executables compiled as Xenix binaries when running on SCO Unix. GNU emacs is a good example. While it worked fine most of the time, it would occaisonally lock up, and often couldn't stat some of the directories (especially NFS mounted directories). When I recompiled it as a COFF binary, everything worked hunky dorry. So I begin to wonder if there are some subtle incompatibilities that show up here between Xenix binaries and the Unix kernel. SCO is probably going to barf all over me for this, but I have checked the code that I have, and I can see no reason why smail or emacs should have behaved in the manner that they did. Not having the source for the uucp stuff, I can offer no opinion about it (other than the implied one :-). ============================ From: rk@theep.boston.ma.us (Robert A. Kukura) Most likely, if this is the problem I've seen before, incoming SMTP mail is not being reliably delivered either. Its not the controlling terminal or the environment, its SCO's infamous security feature, the LUID, or login user id. The init process that runs the rc scripts does not have one, and therefore the sendmail daemon started from the rc script does not have one either. This means that the kernel prevents the sendmail daemon from execing /usr/bin/uux, which I believe (I'm not on an SCO system at the moment), has the SUID bit set. When a user sends mail, the sendmail that is invoked has the user's LUID, so it is permitted to exec /usr/bin/uux, and delivery succeeds. When mail arrives via SMTP for forwarding, its handled by the sendmail daemon with no LUID and it fails. If you kill and restart the sendmail daemon by hand, it has your LUID, and succeeds. The solution is to give the sendmail daemon started by init an LUID by editing /etc/rc2.d/S85tcp to read something like: /bin/su root -c "/usr/lib/sendmail -bd -q1h" I hope this helps. ===================== From: jim@tiamat.fsc.com (Jim O'Connor - IT Manager) As a user of SCO Unix, I'll give you my reasons why I'm using it, why I like it (not necessarily the same :-), and what I don't like about it. Why we use it: - We were an established Xenix shop, moving from Altos Xenix on an 8086 box, to an Altos 80286 box, finally (after getting smart) to SCO Xenix on a 386 PC. - We have a substantial investment in Xenix binaries (286 and 386) which work just fine as they are, so we wanted to retain their use. - If anyone was going to bend over backwards to make sure Xenix programs would run correctly on their Unix it would be SCO. - SCO offered discounts on their Unix when upgrading from Xenix. What I like about it: - Believe it or not, now that I've gotten used to it, I actually like the enhanced security. Our accounting dept. runs on a 386 and once we upgrade it to Unix I'm sure our auditors will jump for joy with the new capabilities. - So far the Xenix compatibility claim has been valid. No trouble running old Xenix (even 286) binaries. - The SCO Dev Sys allows us to cross compile for Xenix, so we can still produce binaries for the few Xenix machines hanging around. - Performance seems to be good, especially wrt disk I/O. - The installation stuff has gotten much better over Xenix. - Since it is Sys V 3.2, there is alot of software for it (although this is true for ISC as well). - I like SCO's method of dealing with console multiscreens better than ISC's (it's been since 1.0.6 since I've touched ISC, though). What I don't like about it: - Limited to only 4 SCSI harddrives. We went to SCSI under Xenix because it would allow something like 14 drives in a system, and now Unix allows only four. With 1G drives getting cheaper, this may not be a problem, but I liked the notion of a 14G 386 box. :-) - SCO's NFS doesn't seem to be completely compatible with HP's NFS (the only other NFS system we have). I've heard it has trouble with other's also. - SCO tried too hard to retain a "Xenix feel" to some of the sys admin stuff, meaning that some things might be "in their Unix place" or "in their Xenix place", or sometimes (the worst of all), in both places (e.g. start up stuff can be done with either Unix's rc2.d scripts, or Xenix's rc.d scripts). There's probably more, but I guess there are the major points. From my experience with ISC and SCO I've always been of the opinion that ISC would make a much better workstation OS (i.e. for running CAD/CAM type stuff, better performance with X windows, easier sys admin when you have lots of boxes like you would in a workstation environment), whereas SCO is a better small, stand-alone system OS (i.e. for a box with lot's of terminals attached being used as a departmental machine for WP, spreadsheets, and other character I/O applications). When we were mostly an microprocessor based shop, I used to say we had a "mainframe attitude in a microprocessor environment", and I felt that SCO's OS fit this mold better. However, now that we have more 386 Unix boxes cropping up, SCO's sysadm stuff makes it more difficult to administer a group of machines using software tools (although, SCO has releases an OS support level supplement that is suppoed to include tools to make it easier to admin the system using programs, rather than doing it by hand). Granted, I haven't used ISC's current release, but I'm a happy SCO customer and don't really see any reason to consider changing. ========================== From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr) In article aris@tabbs.UUCP (Aris Stathakis) writes: | I'd like to know the best way to do a backup so that I can recover from | a FULL crash i.e. having to re-install on a different machine from | a tape backup. I'm sure there are lots of ways to do it, like using | the standard backup proggram SCO give you, but find it too inflexible. Since you say Xenix and I've been running a bunch of these for years, I would first say don't use tar, it skips empty directories, and they may be needed to make things work. A new version might have cured that, but there are other reasons. ================================= From: lerman@stepstone.com (Ken Lerman) 1 -- Make doesn't know how to read a directory over NFS. A simple test: touch foo.c make foo.o Should work in a directory containing no other files. Does not work over NFS. 2 -- Debug and line numbers is screwed up for cc. If a file (foo.c) contains embedded #line directives from more than file, you get all sorts of warnings when compiling and/or linking. I've pretty much given up on trying to track down the precise cause. =========================== From: tanner@cdis-1.compu.com It isn't so much that SCO UNIX is full of bugs, though of course the failure of ``custom'' to could be accounted one. It does not swallow the same disks that xenix systems swallow. Some xenix system calls don't work, and we had a piece of third- party software which dumped core for no good reason, though it was known to run under xenix. (It was the same binary.) The main complaint with SCO unix is the alleged security features. They make it very, very difficult to get some types of work done. Setting up cron jobs, and starting non-root daemons, and verifying that users know passwords, and preparing at jobs, and doing setuid calls all seem to have problems. Starting cron doesn not work from a terminal. It's also slow. In general, my advice is to avoid it. Go a long way out of your way to avoid it. If someone offers it to you, just hit them very hard. Note: my views may be biased. We sell the product. Your milage may vary. ========================= From: bernd@pfm.rmt.sub.org (Bernd Hennig) I have a great problem with the SCO UNIX 3.2.2 and cron. The following is a job in /usr/spool/cron/crontabs/news: 15,30,40,00 * * * * /bin/su news -c "/usr/lib/news/bin/input/newsrun" (at example, this is only ONE job..) And the result is, that cron mails me: Cron: can't set login UID Your commands will not be executed (on Interactive 3.2 or Microport 3.0e this works fine, on SCO UNIX 3.2.2 not..) ======================================= From: sl@van-bc.wimsey.bc.ca (Stuart Lynne) Just use: 15,30,40,00 * * * * "/usr/lib/news/bin/input/newsrun" And make sure that it is in the crontab for "news". I.e.: crontab -u news .... ============================ From: gt2186a@prism.gatech.EDU (COBIA,FRANK NAYLOR) I use a computer running SCO UNIX when I am at home (not away at school). The computer, on a seemingly random basis, will not let anyone log on because it "Can not find database for this terminal" (not the exact message). When the support agreement was still valid, I reported it to SCO. They admitted that it was a bug in the security software that shows up on systems with a large number of logins (we have 7 modems with people login in and out a lot). They said that the /etc/auth/system/ttys file was being corrupted. We found a way to fix it when someone calls complaining that they can not get into the system. This is unacceptable for two reasons: 1) We don't want paying customers to have to call and complain. 2) Unless the console already has someone logged on, we can't get in either. We got a small magazine from SCO (do not remember the name) that suggeted to us that a bug fix had been made available on their BBS. When we follow the procedure in the magazine for logging on the BBS, we get to a prompt that says "Shere=sosco", but then it seems to lockup. When I called Tech Help, they said they had never used the BBS and therefore they could help me. They also refused to talk to me about the problem with being payed $100, even though we had reported the problem during the 30-day free period. I do not think that we should have to pay $100 to get a bug fix for a product that we payed more than $1000 for. ============================ From: john@sco.COM (John R. MacMillan) I mailed this to the original poster, but I thought it might be of interest to others. The answer should probably be in an FAQ. Past distributions of SCO MMDF have had the permissions set wrong, you should run: /usr/mmdf/bin/checkup -p and fix what it tells you to. (Actually, it will probably say certain directories should be 707, but the group permissions don't matter so 777 is fine.) Another couple of notes for elm: you should have elm use the fcntl() locking, as that's how MMDF locks. Also, the locking code in elm that does the fcntl() does not expect EACCES if it can't get the lock, which is what SCO returns (as per the SVID), so you may want to add that in. ======================== From: chip@chinacat.Unicom.COM (Chip Rosenthal) In article <1991Apr02.184954.19405@sco.COM> john@sco.COM (John R. MacMillan) writes: >Another couple of notes for elm: Also...if you want off-site messages to be replyable you need to change the `ap=same' to `ap=822' in the appropriate channels. ======================== From: newbery@stout.atd.ucar.edu (Santiago Newbery) I am trying to add the ODT-NET service to my *existing* SCO ODT 1.0. First of all I ran the [custom] utility which installed the NET software. After the message "Installation of SCO REX Runtime set complete." I am returned to custom's main menu. The question is how do I get to the section on "Configuring the Network Interface" that is detailed in the ODT Installation Guide pp.83-86? The manual seems to assume that ODT-NET is being installed at the same time as the rest of ODT (I hope one can do this later). I am assuming there is a script or set-up utility that can be run independently, but I can't seem to find it. BTW I have done "mkdev wdn" (I am using a WD8003E card) and that installed the ethernet driver w/out problems. =========================== rom: macleod@cmllab.rgb.sub.org (Connor MacLeod) (For those who missed Marks article: he's got troubles when trying to get SCO Unix 3.2.1 (ODT) driving his TBIT with RTS/CTS flow full duplex at 19200 bd...) I just had the same problem. It's just as the guy at Telebit said: using the hardware handshake only in half duplex mode is ok for 99% of all the data transmission. But... I've got some dropouts when polling large files (it's the remaining 1% I bet :>) and I decided to set up RTS and CTS flow. It didn't work at all. I asked a few people around here and I was told to exchange the 16450 chips on my serial cards by 16550 ones. The NS16550A is able to run in 16 byte FIFO mode and this buffer stores the byte(s) in case the system is on havy load and not able to get all the data from the modem in time. The next step is to replace the original sio driver of the SCO Unix by a public domain driver called FAS 2.08 (I can mail/post more information about this driver if someone is interested in). This driver is able to do the RTS/CTS flow in full duplex mode 100%! Well. I haven't got the time to install the FAS driver so far but from the moment on I replaced the 16450s all works fine (about a month now). If anyone decides to replace his serial chips, too, make sure to get the 16550A! The 16550 chips have a hardware bug and the FAS driver will not work with them... ======================= From: ptran@hydra.unm.edu (Michael Burg) I recently got a SCO XENIX from a friend of mine who purchased in 1989; however, he has *NOT* even opened the package to install on his PC. I called SCO company to ask if they can allow to upgrade from version 1.1.0 (too old) to the new version (2.3.2). First, Doug Mcclenvon does not allow me to have it upgrade because SCO POLICY said that the version 1.1.0 is too old EVEN IT HAS NOT OPENED yet. This is outrage since it has not opened that is why my friend does not upgrade it. Because it has not used that is why my friend does not know how *GOOD* the SCO XENIX is. The reason is that he is too busy working on his project for the last 2 years. After Doug told me, I'm a bit upset. I told him that I will post this on the net for everyone to know about SCO, he came back and told me that for my SAKE he accepts this time with 50% off the purchased new version price, and I have to send every dammed things to SCO. Well, I read someone posted on comp.windows.x mentioned about the *VERY HELPFUL* from SCO. But to me, it is *VERY SUCKED*, I think I go and do my project on the SUN rather than getting the *VERY SUCKED SCO XENIX*. My friend he paid about $2,500 for everything TCP/IP, Compilers ....And now it is going to be trashed because I don't have that much of money to afford one. And they don't allow to upgrade with lower price or exchange the old version for the new version with the price different or a little charge. I don't think I will ever want to use SCO XENIX anymore unless they come back and give me a better deal. Because I don't have 1,250 bucks to upgrade!!!! Now I know how helpful the SCO is!!!!! ==================================== From: Michael Squires In article <1991Apr5.133123.11868@ugle.unit.no> knutta@lise.unit.no (Knut Alfredsen) writes: >I am trying to install a Western Digital ethernet card under SCO Unix, but the >thing will not work properly. When the kernel is relinked after the installation >, I get an error message: > >/./etc/conf/pack.d/kernel/space.c, line 310 unknown size >ERROR: space.c will not compile properly I got this error after installing UFE and then installing something else. Apparently you need to re-install UFE (for SCO ODT 1.0) after installing other components of Open Desktop 1.0. At least this made the error go away. =============================== From: gemini@geminix.in-berlin.de (Uwe Doering) >I am having a problem that I am not sure how to handle. Maybe some of you >can help. > >I am trying to get FULL DUPLEX hardware (RTS/CTS) flow control working on >SCO ODT 1.0 (unix version 3.2.1). I am not having much luck. The modem is This is a common misunderstanding of how RTSFLOW works under SCO UNIX (and Xenix as well). SCO implemented a half duplex type of hardware flow control, as it is described in the original RS232C standard. That is, RTS signals the modem whether there are any characters in the _computer's_ output buffer. If there are none, RTS is low, otherwise it's high. This won't work at all if the modem is configured to use full duplex hardware flow control. In this mode RTS signals the modem that the computer is ready to receive characters. As far as I know, there is no way to get this working with the original SCO sio driver, as it isn't designed for that type of handshake. > [detailed problem description deleted] >Now, I spoke with a tech support rep at Telebit, and he said that there was >a limitation with SCO Unix that when you run a port at speeds greater than >9600, RTS/CTS does not work in full duplex mode. He said 9600 or below it >works fine. Well, I tried this at 9600, and the exact same behavior occurred. >I tried this on different serial ports; same thing. I am using a straight >25-pin cable with serial port as DTE and modem as DCE. The fact that it also >fails on 9600 baud makes me suspect that something else is fouled up here. Yes. The port speed has nothing to do with your problem. >Any help and/or suggestions would be greatly appreciated. I am sure I am >not the only one to run into this. I do know about FAS 2.08, but I am really >not sure how to implement it into the SCO scheme of 'uugetty' and the post >dial/connect reset (dial -h .....). Ideas on that welcome too. FAS 2.08 is currently the only dumb port driver that is capable of full duplex hardware flow control (at least I think so). Therefore, you can't solve your problem without FAS as long as you don't want to buy an expensive "intelligent" card. You should be able to use FAS as a plug-in replacement for the sio without having to change your setup. This would only be necessary if you would want to use FAS's extended features like dialin/dialout on the same line while using `getty' etc. Note that the RTSFLOW (as well as the CTSFLOW) works in an SCO compatible way under FAS 2.08. But you can enable full duplex hardware flow control via the minor device number for a port. In this mode, RTS/CTSFLOW are simply ignored and hardware flow control is always enabled. As a side effect, your software can use hw handshaking without even knowing that there is such a feature in your UNIX kernel. No more worrying about whether a program knows about the RTS/CTSFLOW flags or not. =================== From: tim@dell.co.uk (Tim Wright) This is a help plea. We have a user who is trying to install SCO ODT 1.0 on a Dell System 325D. The kernel gets as fas as saying 'G12', then reboots. I'm given to understand that phase 'G' is concerned with setting up interrupt handlers and hence this is interrupt 12. The newer Dell Systems have a PS/2-style mouse (part of the keyboard controller), which uses interrupt 12. Is it possible that ODT is detecting this and erroneously assuming that it is on a PS/2 ??? Is there a fix/should they get ODT 1.1 ? =================== Fnrom: iverson@xstor.com (Tim Iverson) In article <1991Mar26.231914.26740@lunatix.uucp> robert@lunatix.uucp (Robert Sexton) writes: >I anybody running cnews successfully on SCO UNIX. when I get it >compiled, it has really terrible problems with holes in history.pag, >which implies problems with dbz... I've been up and running since January under Cnews and SCO Unix. There's a trick to it, though; you probably don't want to compile Cnews with Microsoft C (cc). Try using AT&T's compiler (rcc) and you'll have much better luck. You'll have better luck still using a version of gcc 1.39 that's been patched for #pragma pack. ================== From: scott@phlpa.UUCP (Scott Scheingold) I have noticed that some of my cron jobs are running an hour later than they are normally run. Example uucp.cleanup is supposed to run at 23:45 but it is running at 00:45 instead. This has occured since the swich to EDT. The system swiched the time on sunday just like we would change the clocks automaticly. Now not all the jobs are running late just some. Have I come across a bug with SCO UNIX SYS V/386 Rel. 3.2.2. Or is there something that I should do to get things back on track (besides a reboot of the system). I was supprised when I found the clock had changed. I am just glad that I didn't have anything of real importance that needed to be run at a specific time. My next question would be when we switch back to EST will this become a problem once again. -- David Van Beveren INTERNET: emisle!dvb@ism.isc.com EIS ltd. Professional Software Services UUCP: ..uunet!emisle!dvb voice: (818) 587-1247