From: dfilip@colorne.UUCP
Newsgroups: comp.os.coherent
Subject: Re: The extent of 4.0 v.1 problems
Keywords: coherent 4.0 problems
Date: 5 Sep 92 13:50:28 GMT
Distribution: world

Donald F. Parsons writes :

>I am using 3.1 on a 286 and wonder whether I should get a 386 mother board
>an install 4.0. I read about all these problems ......!
>  Does anyone have an estimate of the number of succesful installations 
>(without guru intervention). In any case, when will a new version be 
>released? Don

I can't give you the number of 'clean' installs, but I can tell you that
I have installed Coherent 4.0 on two systems with great success  :

	Gateway 2000 / ATI VGA / 140MB ESDI
	Gateway 2000 / SpeedStar VGA / 120MB+200MB IDE
	Both with 'standard' 102 key keyboards (NOT AnyKey keyboards)

I have had no real problems, and the in general Coherent seems to be very
stable. I have been using it for about two weeks, and the filesystem has not
crashed once. Although I was also concerned about some of the postings in this
newsgroup and all of the problems that have been reported, I find Coherent 4.0
to be stable and reliable.

Some of the 'problems' I have had were :

Protections on com ports :

	UUCICO will not 'dial' out on a line unless the permissions are 666,
	and owned by bin (the later may not be NECESSARY, but bin should
	normally be the owner). What is not clear in the documentation is that
	if you enable the port for logins, the protection changes to :

		C--S------  root  root

	and then uucp will no longer work, but merely reports a line problem.
	To fix it, you must do a :

		chmog 666 bin bin /dev/com... (for whatever your device is)

	It was originally not obvious why, when I kept fixing the ownership
	and protections, it kept getting reset. Also, because of this, you
	cannot (without writing a shell script) keep a direct line enabled
	and then expect uucico to disable it by specifying the 'remote'
	line as the local device, i.e. :

		DIR  com2l  com2l  9600  direct

	will NOT work in L-devices. This only works for a dial-in modem,
	becuase the outgoing (local) and incomming (remote) devices are
	different, i.e. :

		ACU  com1l  com1r  2400  direct

	None of this is really a bug in Coherent, but just a matter of
	understanding how it works.

Site names >7 characters :

	Although uucp warns against site names >7 characters, it will
	accept them. I was hoping that by using the MYNAME= in Permissions
	that I could get my system to actually send >7 character site names.
	Unfortunatly, that is NOT true, and regardless of what you specify
	in Permissions your site name will always be truncated to 7 characters.
	Again, not a bug, but it should probably be made more clear in the
	manual (and I should probably pay more attention to warnings :-).

UUCICO core dumps :

	If for any reason, while uucico is in the middle of dialing out and
	attempting to establish a connection, if the connection is dropped
	before a 'Ready for transactions' comes up, it will core dump. I
	have been told that there is a new uucico available from MWCBBS that
	fixes this problem.

Protection problems on uucp files :

	Coherent creates mail files (both /usr/spool/mail... and when you
	's'ave a message) with permissions 644, which allows world read.
	I have read that this is fixed with a download from MWCBBS.

	Also, the uumvlog script will create new, empty log files with
	the default ownership and protection of the process running it.
	If you run it from root, for example, you will get log files with
	the ownership of root. The next time that uucico tries to run
	under uucp, it cannot write to the log files, and dies. Running
	uucheck -f will fix this problem ... until uumvlog runs again.
	I believe this is also supposed to be fixed with the above patch,
	however it is also easy enough to fix in the script itself.

Installing /usr as a separate file system :

	I am used to working on systems which have a separate /usr
	filesystem, so when I created multiple partitions during the
	install I told it to create a /dev/usr and mount it under /usr.
	I got a warning that /usr already existed, which I basically
	ignored (got to do something about ignoring warnings :-).
	However, later I realized that the following files were 'missing'
	and actually accessible only when /dev/usr was not mounted (i.e.,
	they were under the directory /usr on the root filesystem) :

		/usr/bin/cpio
			/more
			/pax
			/ustar

		/usr/lib/terminfo/a/ansipc

	To get around this, I went into single user mode, mounted /dev/usr
	under /tmp, and then cp'ed the five files from /usr/bin.... and
	/usr/lib... to /tmp/bin... and /tmp/lib...

	Although it is questionable as to whether something like this is
	supported, it would have been nice if the installation script would
	have either copied the files itself, or warned me explicitly that
	I would be missing files (this problem is a result of the installation
	procedure, which first copies 'base' files from Disk 1 (without any
	filesystems mounted), and then later re-boots with mounted filesystems
	to load the rest of Coherent).

/dev/console ANSI support :

	For some reason, some escape sequences, when sent to the console,
	cause text to become invisible (i.e., black foreground, black
	background). Among these are :

		Esc [ ? 4 h | l
		Esc [ ? 7 h | l

	as well as some other non-documented VT-100 escape sequences. The
	way to fix this is to send an 'Esc [ m' to re-set the video
	attributes. Strange ... found this when connecting to my Xenix/286
	which has a lot of such escapes in the initialization sequence in
	it's termcap.

Except for the above issues, some of which were an ignorance of the product,
Coherent seems to be working fine.

Since most of these problems are minor in nature, as long as you know about
them, I would recommend upgrading to 4.0. What's great about comp.os.coherent
is that if there really is a problem, you have large group of people willing
to help you, and MWC's technical support is excellent (they had told me about
some of the above patches, and the com proection problem). Also, since
MWC runs their BBS, you can always download patches in a timely fashion.

The only real concern that I have seen has to do with incompatible hardware,
which I cannot comment on. But if you stay with reasonably standard hardware,
you should be OK. (hopefully, others can comment on this more). However,
just because your hardward is not listed in the compatibility list dosn't
mean that it won't work !

Regards,

Dave.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=   David E. Filip                UUCP   : uupsi!jpradley!colornet!dfilip   =
=   ColorNet Information Systems  CIS    : 76430,3111                       =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=     'Why fix the application when we can just keep fixing the data ?'     =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Newsgroups: comp.os.coherent