Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!grian!alex
From: alex@grian.cps.altadena.ca.us (Alex Pournelle)
Newsgroups: comp.unix.xenix.sco
Subject: Re: Xenix upgrade 'ufm' - is it worth installing?
Keywords: ufm 2.3.3
Message-ID: <1990Oct22.211758.921@grian.cps.altadena.ca.us>
Date: 22 Oct 90 21:17:58 GMT
References: <107@embassy.nsi.com> <1990Oct15.224601.24494@robobar.co.uk>
Organization: Workman & Associates
Lines: 53

ronald@robobar.co.uk (Ronald S H Khoo) writes:

>In article <107@embassy.nsi.com> lance@embassy.nsi.com writes:

>> I am not sure whether the benefits outweigh the
>> potential for problems from the upgrade. [UFM (xnx155b)]

>The UFM upgrade procedure is pretty painless, the only thing
>which is slightly inconvenient is that you have to merge your local
>changes to /etc/termcap into the new one provided.

>On balance, I'd say, yeah, install it.

>MHO: Cost: low.  Benefit: medium to high.  Conclusion: I'd go for it unless
>you have a "production" as opposed to a "development" or "hacking" system.

I have just installed the XNX155SLS on my computer, and have much to say
about it.  Pull up a chair, this stuff's important.

System in question is an 386SX with 3.5 Megs, a 40 Mbyte MFM drive and
an EGA card.  Plus 1.2 and 1.44 Mbyte floppy drives.

1) There are some BIOS incompatibilities with this release.  I had an
old (Aug 89) AMI BIOS on my system and as soon as I hit multi-user mode
I would get a "Panic: parity error" on the system.  Worked (mostly) fine
in single-user, though.  When I switched to an 1988 Award BIOS, the
system came up multi-user without a problem.  Also :-) the mysterious
coredumps in Urogue went away.

Greg Fores, a really knowledgeable tech. at SCO, tells me that there is
a new release of the SLS which probably works better on the older
BIOSes.  This is stuck in QC and will be released (ahem) Real Soon Now.
Meanwhile, one can comment out the command to load the new RAM-checker
(oem.o) and use the old (2.3.2) checker.

2) the 3.5" high-density disk support from 2.2.3 to 2.3.2 and later is
different.  Under the "older" system one would use /dev/fd096ds18 to
read 3.5" HD disks.  Under 2.3.2 and later, one uses /dev/fd0135ds18.
To read older 3.5" HDs, mknod entries for fd096ds18 and rfd096ds18, lInK
them to /dev/fd0 and /dev/rfd0 and THEN tar or de-archive.

3) The SCO manual is wrong; use "custom -r /dev/install1" to run custom
from the second floppy device, not "custom -r /dev/fd096ds15" or
whatever.  Make sure you have properly installed the second floppy
device.

4) Floppy read-write speed isn't improved any.  Sorry.  Nor are there
any plans to change the floppy drivers (&*^*&^*(&^!!)
-- 
		Alex Pournelle, freelance thinker
		Also: Workman & Associates, Data recovery for PCs, Macs, others
		...elroy!grian!alex; BIX: alex; voice: (818) 791-7979
		fax: (818) 794-2297    bbs: 791-1013; 8N1 24/12/3