Summary: What's wrong with SCO (long)
David Van Beveren
dvb at emisle.uucp
Sun Apr 14 12:21:53 AEST 1991
========
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 at robobar.co.uk (Ronald S H Khoo)
aw1 at stade.UUCP (Adrian Wontroba)
wht at n4hgf.Mt-Park.GA.US (Warren Tucker)
flon at pollux.usc.edu (Scott Simpers)
Ian Geoffrey Sergeant <inas at cs.uow.edu.au>
Jack Cloninger <teqsoft!jmc at uunet.UU.NET>
steveo at world.std.com (Steven W Orr)
Michael Squires <mikes at iuvax.cs.indiana.edu>
sixhub!davidsen at crdgw1.ge.com (Wm E. Davidsen Jr)
Erik Fortune <erik at gogoman.sf.ca.us>
<sysop at mixcom.COM> (Dean Roth)
cellar!toad at uunet.UU.NET
laurana!ppaone at uunet.uu.net (Phil Paone)
fred at cdin-1.COMPU.COM (Fred Rump)
"Robert E. Laughlin" <ico.isc.com!bel at trout.nosc.mil>
count!chip at uunet.UU.NET (Chip Salzenberg)
Ian Searle (uw-beaver!sumax!polari!ian)
drolet at drolet.cam.org (Jean-Jacques Drolet)
rhealey at digibd.com (Rob Healey)
macleod at cmllab.rgb.sub.org (Connor MacLeod)
rbraun at spdcc.COM (Rich Braun)
paulz at sco.COM (W. Paul Zola)
steve at edm.isac.CA (Steve Hole)
rk at theep.boston.ma.us (Robert A. Kukura)
jim at tiamat.fsc.com (Jim O'Connor - IT Manager)
davidsen at sixhub.UUCP (Wm E. Davidsen Jr)
lerman at stepstone.com (Ken Lerman)
tanner at cdis-1.compu.com
bernd at pfm.rmt.sub.org (Bernd Hennig)
sl at van-bc.wimsey.bc.ca (Stuart Lynne)
gt2186a at prism.gatech.EDU (COBIA,FRANK NAYLOR)
john at sco.COM (John R. MacMillan)
chip at chinacat.Unicom.COM (Chip Rosenthal)
newbery at stout.atd.ucar.edu (Santiago Newbery)
macleod at cmllab.rgb.sub.org (Connor MacLeod)
ptran at hydra.unm.edu (Michael Burg)
Michael Squires <mikes at iuvax.cs.indiana.edu>
gemini at geminix.in-berlin.de (Uwe Doering)
tim at dell.co.uk (Tim Wright)
iverson at xstor.com (Tim Iverson)
scott at phlpa.UUCP (Scott Scheingold)
Responses with minimal edits (Long):
================================
ronald at 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 <curses.h>
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 at 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 at 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 at 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 <inas at cs.uow.edu.au>
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 <teqsoft!jmc at uunet.UU.NET>
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 at 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 at 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 <mikes at iuvax.cs.indiana.edu>
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 <mikes at iuvax.cs.indiana.edu>
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 at 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 <erik at gogoman.sf.ca.us>
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 at 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: <sysop at mixcom.COM> (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 at 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 at 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 at 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" <ico.isc.com!bel at trout.nosc.mil>
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 at 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 at 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 at 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 at 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 at 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 at cmllab.rgb.sub.org (Connor MacLeod)
In article <1991Mar22.211749.13292 at robobar.co.uk>
ronald at 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 at 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 at 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 at 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 at 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 at 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 at sixhub.UUCP (Wm E. Davidsen Jr)
In article <aris.670179095 at tabbs> aris at 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 at 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 at 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 at 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 at 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 at 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 at 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 at chinacat.Unicom.COM (Chip Rosenthal)
In article <1991Apr02.184954.19405 at sco.COM>
john at 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 at 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 at 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.
<sigh>
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 at 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 <mikes at iuvax.cs.indiana.edu>
In article <1991Apr5.133123.11868 at ugle.unit.no> knutta at 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 at 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 at 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 at xstor.com (Tim Iverson)
In article <1991Mar26.231914.26740 at lunatix.uucp> robert at 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 at 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 at ism.isc.com
EIS ltd. Professional Software Services UUCP: ..uunet!emisle!dvb
voice: (818) 587-1247
More information about the Comp.unix.sysv386
mailing list