Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!stc!stl!robobar!ronald
From: ronald@robobar.co.uk (Ronald S H Khoo)
Newsgroups: comp.unix.sysv386
Subject: Re: Summary: What's wrong with SCO (long)
Message-ID: <1991Apr17.143722.7650@robobar.co.uk>
Date: 17 Apr 91 14:37:22 GMT
References: <1991Apr14.022153.2099@emisle.uucp>
Organization: Robobar Ltd., Perivale, Middx., ENGLAND.
Lines: 82

dvb@emisle.uucp (David Van Beveren) writes:

[ A summary ]

Thanks for posting a summary.  However I felt that it was still a bit
one-sided.  Some of those problems were generic ones (ie not specific to
SCO) and I think it would have been in good taste to mention some of the
things they *do* get right (like, for example, making bugfixes available
free in a way which you can browse *without* having to buy support)

Anyway, here's a bit of comment from me.  I've done my fair share
of SCO bashing before, let me try to address some of the problems
from the other point of view :-)

> 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.

A fix for NFS related make problems available free by anon UUCP or FTP.
It's lng 261.  I *suspect* that it deals with this problem.

> 3. Curses cannot handle 8-bit characters.

There is a generic (ie NOT SCO's FAULT) System V bug to do with
certain aspects of 8bit curses usage.  Specifically addch() is broken.
Having worked around that, you *can* use 8 bit stuff with SCO's curses.
Someone from SCO actually mailed me their suggested fix, ie. to code
around addch() by using addstr() instead.  Thank you for taking the trouble.

> 10.	The C shell lacks features I expected. This is not a software
> 	bug, though.

And ksh is bundled, so you have no excuse using csh :-)

> 15. Some day, for no apparent reason, root started getting invaded
>     by E-Mail messages from cron complaining about a bad HZ value.

This is probably due to point 14.  Anyone who gives root a shell other
than the standard unix shell is asking for trouble anyway.  On *any*
system.  It's just slightly worse on SCO's :-)

> 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,

Tar from *any* vendor does this, other than GNU tar with the appropriate
options, or some possibly commercial backup programs that have little to
do with tar.  If you want the directories, what's wrong with using
cpio ?

> 21.  Problems with Trailblazer 9600Baud Modem (Recent news thread)

I've not had problems running mine at 19200.  But then, it's not on
a dumb standard port on a machine with TCP.  I *have* run it on a dumb
port with a standard SCO driver, without TCP, at full speed, no problem.

> 22.  Daylight savings time not working correctly. (Recent News Thread)

I thought Paul Zola posted SCO's fix to this one ?  Here's the relevant
portion from SCO's database, probably in complete violation of their
copyright :-)  Anyway, this problem stems from Xenix heritage.  For
their old customers, it's arguable that maintaining extra Xenix compatibility
is a plus.  People who want new technology probably want SVR4 anyway :-)

-- begin excerpt from SCO's fix.
CAUSE:     The installation script, /etc/tz, writes to /etc/TIMEZONE, the TZ 
	   environment variable, and holds information in a bad format.  For 
	   example, a comma is placed in the string just after the daylight 
	   savings timezone name, instead of a semi-colon. The manual page for 
	   TIMEZONE(F) is correct.

SOLUTION:  Edit the file /etc/tz and change the line (line 476):

	     tz=$stname$sthours${dst:+$smname$smhours,$sdate,$edate}

	   so that it reads:

	     tz=$stname$sthours${dst:+$smname$smhours"'\;'"$sdate,$edate}
						     ^^^^^^
           Run /etc/tz and set up the timezone as before.  Log out and
	   log back in again so that the changes may take effect.
-- end of excerpt from SCO's fix.
-- 
Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)