carlo@electro.UUCP (Carlo Sgro) (01/08/89)
This is being posted for a friend of mine (berner!richard). Please reply to me by E-mail as: 1) we don't receive the xenix newsgroup, and 2) his main feed is the one with the problem (dvlmarv). berner recently upgraded from SCO XENIX 2.3 to 2.3.1 (using HDB UUCP). Since the upgrade, their main news feed has not been able to log in via modem. The background is this ... 1) berner has a 2400/1200/300 modem. dvlmarv has a 1200 baud modem. 2) berner cannot call dvlmarv due to restrictions on dvlmarv's phone line. 3) dvlmarv polls berner regularly. Before the upgrade, there was no problem with connecting. 4) dvlmarv uses Ultrix on a Microvax. The symptoms are: 1) When dvlmarv calls, berner's modem answers. berner sends a BREAK to change to 1200 baud. 2) The login prompt appears. berner responds with their userid. 3) The password prompt appears. berner's attempt to enter their password does not succeed (it appears that everything freezes after the password prompt appears). 4) The connection times out. 5) They do not have accounting on so they cannot tell what berner's system thinks dvlmarv is entering as a userid. They have established that dvlmarv never manages to get logged on. Richard suspects that there may be a problem with getty and parity. They have tried all types of parity with no success (he thinks that the system is ignoring his attempts to change parity). The getty definition file entry is: B1200 HUPCL # B1200 HUPCL SANE IXANY Does anyone have any suggestions as to what the problem/solution might be? -- Carlo Sgro NET POLICE WARNING: .signatures that watmath!watcgl!electro!carlo are too long will be trunc
skrenta@eecs.nwu.edu (Richard Skrenta) (01/08/89)
I had the same problem a few months ago. A system which called mine would "freeze" after the password prompt. The sysadmin of the system which called mine fixed it from his end, so I'm not exactly sure what he did. He did say it was a parity problem though. Rich Skrenta
usenet@cps3xx.UUCP (Usenet file owner) (01/08/89)
Yes it seems to ignore parity changes. What will work, at least with a ordinary login, is to follow the login name with a ctrl-j. After that all is ok. ==larry --------------------------- LARRY SHIELDS UUCP: ...!frith!lunapark!larry P.O. Box 6159 BIX: lshields E. Lansing, MI 48826 Compuserve: 70277, 3677 BBS: lunapark 1200 7-1-E / 2400 8-1-N 24hrs (517) 487-3356 login: bbs
root@mjbtn.MFEE.TN.US (Mark J. Bailey) (01/09/89)
I have never really noticed anyone complaining, so maybe I read the docs
wrong, but the mkuser command (as is packaged with 2.3.x and HDB UUCP)
creates the home directories for uucp logins in /usr/spool/uucp. This is
just what the Version 2 UUCP on earlier Xenix versions have been doing.
In and of itself, there is no problem here. However, I upgraded to
the 2.3.1 and subsequently setup HDB on my system, and everything worked
like a champ...for one day. The next day, *ALL* uucp login attempts from
other sites to my system failed after the password.
I discovered that the home directories created by mkuser in /usr/spool/uucp
had vanished mysteriously. I proceeded to recreate them by hand, and again
everything worked great until the day after. This problem frustrated me for
several days until I by chance examined the uudemon.clean shell script
supplied with HDB. I run it every morning around 4:30am. In stepping through
it, I discovered that the script would delete *ALL* empty directories in
/usr/spool/uucp and also old ones. Since uucp login home directories are
always empty, they were axed every night. I corrected this easily enough
by simply relocating my uucp login home directories to /usr/spool/uucphomes
(an arbitrary location, of course). I also modified the files in
/usr/lib/mkuser/uucp to have all future uucp logins created in the new
spot. Once again, all is well with my uucp world. :-) I will add that
the SCO login does not allow logins of userids that have no existing home
directory. Some flavors of unix have a default directory. SCO's login
just shows a message and promptly returns to login. As the uucp home
directories had been axed, all attempts failed after the password.
It appears to me (whether documented or not) that this is a considerably
devastating problem created by SCO by shipping the release with such a setup.
Again, maybe it is in the docs, if so, I just missed it. But in either
case, I hope this may be of some help.
Mark.
--
Mark J. Bailey "Y'all com bak naw, ya hear!"
USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________
VOICE: +1 615 893 0098 | JobSoft
UUCP: ...!{ames,mit-eddie}!killer!mjbtn!mjb | Design & Development Co.
DOMAIN: mjb@mjbtn.MFEE.TN.US | Murfreesboro, TN USAbill@ssbn.WLK.COM (Bill Kennedy) (01/09/89)
In article <397@mjbtn.MFEE.TN.US> root@mjbtn.MFEE.TN.US (Mark J. Bailey) writes: > >I have never really noticed anyone complaining, so maybe I read the docs >wrong, but the mkuser command (as is packaged with 2.3.x and HDB UUCP) >creates the home directories for uucp logins in /usr/spool/uucp. This is >just what the Version 2 UUCP on earlier Xenix versions have been doing. I do not have SCO's HDB, so I am ignorant about mkuser. I am, however rather familiar with several variants of HDB and what's killing Mark and the fixes he arrived at are not correct. The home directory in /etc/passwd should be /usr/spool/uucppublic for all uucp logins. The uucico and uux will create directories and files as needed in /usr/spool/uucp/sitename just as uudemon.cleanup will get rid of them if they are empty. There's a similar minefield (if mkuser really makes spool/uucp be the home directory) in the AT&T (ISC?) adm shell. If you remove a uucp user and agree to the removal of its home directory then your logins fail because it can't chdir to /usr/spool/uucppublic. [ ... ] >always empty, they were axed every night. I corrected this easily enough >by simply relocating my uucp login home directories to /usr/spool/uucphomes You don't really need to do that and if it was my system, I would not. There's nothing wrong with having public as the home directory since you can grant and deny access with the Permissions file and uux/uucico run setuid uucp in order to write in /usr/spool/uucp/sitename, creating it if it isn't there. [ ... ] >It appears to me (whether documented or not) that this is a considerably >devastating problem created by SCO by shipping the release with such a setup. If mkuser is, indeed, the culprit then they have shipped you a pain in the neck, but if you change the home directory to public it sounds like they are shipping pretty much plain vanilla HDB. >Again, maybe it is in the docs, if so, I just missed it. But in either >case, I hope this may be of some help. If it's documented then I haven't seen it either, but it's the way that the distributed passwd came (for nuucp) and it works OK. Just remember that when you delete a uucp login you should not agree to remove its home directory or you'll kill 'em all. >Mark. I started to email that but decided to post instead since SCO HDB is rather new. I hope it helps Mark and anyone else who didn't know and I hope that there aren't fifteen jillion followups saying the same thing I did, there aren't any here... -- Bill Kennedy usenet {killer,att,cs.utexas.edu,sun!daver}!ssbn!bill internet bill@ssbn.WLK.COM
clarke@acheron.UUCP (Ed Clarke) (01/09/89)
From article <397@mjbtn.MFEE.TN.US>, by root@mjbtn.MFEE.TN.US (Mark J. Bailey): > (an arbitrary location, of course). I also modified the files in > /usr/lib/mkuser/uucp to have all future uucp logins created in the new > spot. Once again, all is well with my uucp world. :-) I will add that > the SCO login does not allow logins of userids that have no existing home I don't understand why you want to give uucp logins a private home directory. All of my uucp logins have "/usr/spool/uucppublic" as their home directory. This shouldn't cause any problems as far as I can see. Am I missing something? -- Ed Clarke uunet!bywater!acheron!clarke
jbayer@ispi.UUCP (Jonathan Bayer) (01/09/89)
In article <397@mjbtn.MFEE.TN.US> root@mjbtn.MFEE.TN.US (Mark J. Bailey) writes:
=
=wrong, but the mkuser command (as is packaged with 2.3.x and HDB UUCP)
=creates the home directories for uucp logins in /usr/spool/uucp. This is
=just what the Version 2 UUCP on earlier Xenix versions have been doing.
=In and of itself, there is no problem here. However, I upgraded to
=the 2.3.1 and subsequently setup HDB on my system, and everything worked
=like a champ...for one day. The next day, *ALL* uucp login attempts from
=other sites to my system failed after the password.
=
=I discovered that the home directories created by mkuser in /usr/spool/uucp
=had vanished mysteriously. I proceeded to recreate them by hand, and again
=everything worked great until the day after. This problem frustrated me for
=several days until I by chance examined the uudemon.clean shell script
=supplied with HDB. I run it every morning around 4:30am. In stepping through
=it, I discovered that the script would delete *ALL* empty directories in
=/usr/spool/uucp and also old ones. Since uucp login home directories are
=always empty, they were axed every night. I corrected this easily enough
=by simply relocating my uucp login home directories to /usr/spool/uucphomes
=(an arbitrary location, of course). I also modified the files in
=/usr/lib/mkuser/uucp to have all future uucp logins created in the new
=spot. Once again, all is well with my uucp world. :-) I will add that
=the SCO login does not allow logins of userids that have no existing home
=directory. Some flavors of unix have a default directory. SCO's login
=just shows a message and promptly returns to login. As the uucp home
=directories had been axed, all attempts failed after the password.
=
This is a known bug which has been reported to SCO many times. It is
due to be corrected in the next release.
Hello, SCO. Where is the next release???????
--
Jonathan Bayer "The time has come," the Walrus said...
Intelligent Software Products, Inc.
19 Virginia Ave. ...uunet!ispi!jbayer
Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispimanes@marob.MASA.COM (Steve Manes) (01/10/89)
From article <397@mjbtn.MFEE.TN.US>, by root@mjbtn.MFEE.TN.US (Mark J. Bailey): > I discovered that the home directories created by mkuser in /usr/spool/uucp > had vanished mysteriously. > It appears to me (whether documented or not) that this is a considerably > devastating problem created by SCO by shipping the release with such a setup. Hey, it's a *feature*! It's nice having a UUCP demon clean up all those unneeded spool directories, especially if you allow anonymous UUCP logins. Seriously though, the oversight is mkuser's using /usr/spool/uucp/XXX for the /etc/passwd home directory. Most BNU installations just specify a single communal directory with read/write permissions for UUCP, like /usr/spool/uucppublic. This is just to get past 'login'. /usr/spool/uucp directories will still be created as needed as needed. -- Steve Manes Roxy Recorders, Inc. Magpie-HQ BBS UUCP : {rutgers|cmcl2}!hombre!magpie!manes (212)420-0527 Smail: manes@MASA.COM
root@mjbtn.MFEE.TN.US (Mark J. Bailey) (01/10/89)
In article <439@acheron.UUCP>, clarke@acheron.UUCP (Ed Clarke) writes: > From article <397@mjbtn.MFEE.TN.US>, by root@mjbtn.MFEE.TN.US (Mark J. Bailey): > > (an arbitrary location, of course). I also modified the files in > > /usr/lib/mkuser/uucp to have all future uucp logins created in the new > > spot. Once again, all is well with my uucp world. :-) I will add that > > the SCO login does not allow logins of userids that have no existing home > > I don't understand why you want to give uucp logins a private home > directory. All of my uucp logins have "/usr/spool/uucppublic" as > their home directory. This shouldn't cause any problems as far as > I can see. Am I missing something? The issue I am concerned with is not the home directories for uucp logins. I know that that really is trivial. The problem was that "as shipped" from SCO, 2.3.[01] with HDB, had a mkuser setup to create uucp-user home dirs in /usr/spool/uucp as has been the case for 2.2.x xenix versions. Under Version 2 uucp it wasn't a problem, ever. But under HDB UUCP, the uudemon.clean script would wipe out those home dirs STILL created in /usr/spool/uucp by the mkuser command. For me, it is easy enough to change that to somewhere else. uucppublic is a perfect place, however, I have a lot of uucp logins (I prefer a login for every site calling for login record's sake - call it a weakness :-) ), and I simply preferred avoiding the clutter of a slew of empty directories (I use PUBDIR as a pass thur in my local unix network and wanted to keep it free except for traffic). But to get back to my main point, a virgining user, or one who just wants the machine to work within the frame of what is described in the docs, doesn't and shouldn't have to worry about the mkuser command (which IS a convenient way to create uucp logins!) choosing a spot for the uucp login home dir. Not everyone is blessed with instinctive System Administrator qualities such that they ever get around to learning about home directories, etc. I am simply stating that my release, and a client's, were SHIPPED that way, and it was a problem. The solution was to edit /usr/lib/mkuser/uucp/mkuser.defs and set the home directory to PUBDIR (or wherever). I am just saying that many xenix users never would have picked up on that as they simply DON'T WANT to know that much detail. I just felt it needed to be pointed out. I think they are up to 2.3.2, so it may be fixed by now. Mark. -- Mark J. Bailey "Y'all com bak naw, ya hear!" USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________ VOICE: +1 615 893 0098 | JobSoft UUCP: ...!{ames,mit-eddie}!killer!mjbtn!mjb | Design & Development Co. DOMAIN: mjb@mjbtn.MFEE.TN.US | Murfreesboro, TN USA
jim@tiamat.FSC.COM (Jim O'Connor) (01/10/89)
In article <439@acheron.UUCP>, clarke@acheron.UUCP (Ed Clarke) writes: > I don't understand why you want to give uucp logins a private home > directory. All of my uucp logins have "/usr/spool/uucppublic" as > their home directory. This shouldn't cause any problems as far as > I can see. Am I missing something? The practice of separate home directories parallels the practice of separate login accounts, and is convenient if your uucp neighbors are sending in files. With separate home directories, each acount can uucp to ~account, and have the files show up in separate directories. I used this for a while when we had remote machines sending in daily data files, and it helped eliminate some confusion. Other than convenience, there should be no reason why you can't specify /usr/spool/uucppublic as all uucp account home directories. To re-iterate other's warnings, though: Be careful not to remove this directory when using rmuser to cancel a uucp account. Then all other accounts will not have a home directory and login will complain. --jim ------------- James B. O'Connor jim@FSC.COM Filtration Sciences Corporation 615/821-4022 x. 651
john@jetson.UPMA.MD.US (John Owens) (01/11/89)
Xenix typically uses eight bits, no parity on dialup lines, and the configuration you showed keeps that setup. Most uucicos use 7 bits, even parity by default. Some can be configured to use zero parity (which is equivalent for logging in with 7-bit ASCII characters) with a string like "P_ZERO" in the L.sys file. Worst case, you'll have to pick characters for the remote systems password that have even parity without setting the parity bit, and have him end his password with a newline (\n) instead of a carriage return.... Good luck! -- John Owens john@jetson.UPMA.MD.US uunet!jetson!john +1 301 249 6000 john%jetson.uucp@uunet.uu.net
bill@ssbn.WLK.COM (Bill Kennedy) (01/11/89)
In article <210@tiamat.FSC.COM> jim@tiamat.FSC.COM (Jim O'Connor) writes: >In article <439@acheron.UUCP>, clarke@acheron.UUCP (Ed Clarke) writes: >> I don't understand why you want to give uucp logins a private home >> [ ... ] > >The practice of separate home directories parallels the practice of >separate login accounts, and is convenient if your uucp neighbors are sending >in files. I suggest that this point is moot because HDB includes a script, "uuto" which creates a rather lengthy path that is absolutely unique insofar as the originating site!user and the destination site!user are concerned. Any user at any site can send a file to another user at another site with little risk of file name collision in uucppublic if you stick with uuto. I'm not trying to diminish the utility of separate directories to enable transfers to ~account, but if you can uuto filename site!user, it seems to be as easy as mail (at least to me). -- Bill Kennedy usenet {killer,att,cs.utexas.edu,sun!daver}!ssbn!bill internet bill@ssbn.WLK.COM
jim@tiamat.FSC.COM (Jim O'Connor) (01/12/89)
In article <609@ssbn.WLK.COM>, bill@ssbn.WLK.COM (Bill Kennedy) writes: > In article <210@tiamat.FSC.COM> jim@tiamat.FSC.COM (Jim O'Connor) writes: > >The practice of separate home directories parallels the practice of > >separate login accounts, and is convenient if your uucp neighbors are sending > >in files. > I suggest that this point is moot because HDB includes a script, "uuto" > which creates a rather lengthy path that is absolutely unique insofar as > the originating site!user and the destination site!user are concerned. That's great, and I agree "uuto" is the better solution, but unfortunately not everyone has HDB available. At the time we were running Version 2 uucp, and this method was the simplest available. > I'm not trying to diminish the utility of separate directories to enable > transfers to ~account, but if you can uuto filename site!user, it seems > to be as easy as mail (at least to me). uuto is one of the many great features added in HDB, but unless Altos goes through some big shakedown, us poor soles with Xenix3.4b on the 80286 machines will probably be stuck with Version 2 uucp as long as the machines stay around (which shouldn't be too much longer :-). --jim ------------- James B. O'Connor jim@FSC.COM Filtration Sciences Corporation 615/821-4022 x. 651
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (01/12/89)
I had the same problem, and just hacked the cleanup script to be a
little smarter. I have some non-standard stuff on my system, but you can
do a quick and dirty check by using grep and looking at the status. I
don't remember the name of the env variable with the dirname, but this
is the idea:
grep ":${dirname}:" /etc/passwd || rmdir ${dirname}
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -merick@seismo.CSS.GOV (Rick Adams) (01/12/89)
uuto is a lot older than HDB. I think it goes back to System III or even earlier. At the very least it was on my System V.2 tape. (dont forget the companion uupick)
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (01/12/89)
In article <212@tiamat.FSC.COM> jim@tiamat.FSC.COM (Jim O'Connor) writes: | That's great, and I agree "uuto" is the better solution, but unfortunately | not everyone has HDB available. At the time we were running Version 2 uucp, | and this method was the simplest available. [ stuff ] | uuto is one of the many great features added in HDB, but unless Altos goes I'm sure a lot of people will tell you, uuto came in with SysIII. I just looked in my old December 1984 manual, and there it is. No Revision bars, either. If you don't have uuto you have a UNIX subset, or V7 based system (such as BSD). By the way, I don't really LIKE uuto, I have to get at the files using yet another arcane program with its own command set. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
jwc@Thalatta.COM (Bill Campbell Guest account) (01/13/89)
In article <1465@cps3xx.UUCP> las@frith.UUCP (Larry A. Shields {runs Lunapark}) writes: >Yes it seems to ignore parity changes. What will work, at least >with a ordinary login, is to follow the login name with a ctrl-j. >After that all is ok. > I have seen this happen because of a problem in /etc/gettydefs. The gettydefs entry consists of five parts separated by the '#' characters. The first is an identifier referenced in /etc/ttys on Xenix systems or in /etc/inittab on sysV, the second sequence is the baud rate... used for login password, the third the baud rate... for use after login, the fourth is the login prompt, and the last is the next gettydefs entry to use (cycles baud rates...). The following two entries cycle between 1200 and 2400 baud. 2 # B1200 HUPCL OPOST CR1 NL1 # B1200 CS8 SANE HUPCL TAB3 IXANY # \r\n@!Login: # 3 3 # B2400 HUPCL OPOST CR1 NL1 # B2400 CS8 SANE HUPCL TAB3 IXANY # \r\n@!Login: # 2 I have messed this up by copying an existing entry to create an entry for a new baud rate, and forgetting to change the baud rate on the second entry so that it changes after you finish the login :-( Another common error is to screw up the last entry which tells getty which entry to use next so that the baud rates don't cycle properly. Bill Campbell.
larry@tapa.UUCP (Larry Pajakowski) (01/13/89)
Uuto is also on the 2.2 286 and 386 versions of pre HDP SCO Xenix. Larry
root@mjbtn.MFEE.TN.US (Mark J. Bailey) (01/14/89)
In article <598@tapa.UUCP>, larry@tapa.UUCP (Larry Pajakowski) writes: > Uuto is also on the 2.2 286 and 386 versions of pre HDP SCO Xenix. > > Larry Yeah, but I think what Jim is talking about is Altos Xenix for the 286. The word 'Altos' represents a completely different ball game. Altos has good equipment, but their PROPRIETARY xenix is *NO* SCO 286. You can't even take binaries from SCO (ie, products of the cc on SCO) and run them on the 286 Altos. Something to do with the header formats being different. While SCO has uuto (and everyone else), it is not at all suprising that Altos would have left them out. No offense to Altos, they just do things differently...there own way. Mark. -- Mark J. Bailey "Y'all com bak naw, ya hear!" USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________ VOICE: +1 615 893 0098 | JobSoft UUCP: ...!{ames,mit-eddie}!killer!mjbtn!mjb | Design & Development Co. DOMAIN: mjb@mjbtn.MFEE.TN.US | Murfreesboro, TN USA
rac@jc3b21.UUCP (Roger A. Cornelius) (01/16/89)
From article <402@mjbtn.MFEE.TN.US>, by root@mjbtn.MFEE.TN.US (Mark J. Bailey):
- In article <598@tapa.UUCP>, larry@tapa.UUCP (Larry Pajakowski) writes:
-> Uuto is also on the 2.2 286 and 386 versions of pre HDP SCO Xenix.
->
-> Larry
-
- Yeah, but I think what Jim is talking about is Altos Xenix for the 286.
- The word 'Altos' represents a completely different ball game. Altos has
- good equipment, but their PROPRIETARY xenix is *NO* SCO 286. You can't even
- take binaries from SCO (ie, products of the cc on SCO) and run them on
- the 286 Altos. Something to do with the header formats being different.
- While SCO has uuto (and everyone else), it is not at all suprising that
- Altos would have left them out. No offense to Altos, they just do things
- differently...there own way.
-
- Mark.
Altos uses version 3 derived Xenix on the 286 machines as opposed to SCO's
system 5. This is why you can't take binaries directly from one to the
other without mods. If you compile on SCO with the -compat compiler
flag, you can run most binaries on the altos. You can also use SCO's
fixhdr program to modify some binaries so they will run.
As far as Altos' Xenix being no SCO, I totally agree.
Rogerdet@hawkmoon.MN.ORG (Derek E. Terveer) (01/18/89)
In article <212@tiamat.FSC.COM>, jim@tiamat.FSC.COM (Jim O'Connor) writes: > In article <609@ssbn.WLK.COM>, bill@ssbn.WLK.COM (Bill Kennedy) writes: > > I suggest that this point is moot because HDB includes a script, "uuto" > > That's great, and I agree "uuto" is the better solution, but unfortunately > not everyone has HDB available. Yes, but uuto (and its companion uupick) is really a simple shell script that invokes uucp with a somewhat unique destination path. One should, with relative ease, be able to write a much simplified uuto and/or uupick and retain much of the same functionality. derek -- Derek Terveer det@hawkmoon.MN.ORG || ..!uunet!rosevax!elric!hawkmoon!det w(612)681-6986 h(612)688-0667 "A proper king is crowned" -- Thomas B. Costain
allbery@ncoast.UUCP (Brandon S. Allbery) (01/21/89)
As quoted from <402@mjbtn.MFEE.TN.US> by root@mjbtn.MFEE.TN.US (Mark J. Bailey): +--------------- | In article <598@tapa.UUCP>, larry@tapa.UUCP (Larry Pajakowski) writes: | > Uuto is also on the 2.2 286 and 386 versions of pre HDP SCO Xenix. | | Yeah, but I think what Jim is talking about is Altos Xenix for the 286. | The word 'Altos' represents a completely different ball game. Altos has | good equipment, but their PROPRIETARY xenix is *NO* SCO 286. You can't even +--------------- Altos and SCO both get Xenix from Microsoft. My opinion? I can't see how anyone can stand SCO Xenix (well, pre-3.2, at least). (For that matter, I can't see how anyone can stand Intel processors....) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org (soon) uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
clewis@ecicrl.UUCP (01/21/89)
In article <544@jc3b21.UUCP> rac@jc3b21.UUCP (Roger A. Cornelius) writes: >Altos uses version 3 derived Xenix on the 286 machines as opposed to SCO's ^^^^^^^ >system 5. Xenix may be archaic, but it ain't *that* old! ;-) -- Chris Lewis, Markham, Ontario, Canada {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)
fnf@estinc.UUCP (Fred Fish) (01/26/89)
In article <13351@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >Altos and SCO both get Xenix from Microsoft. My opinion? I can't see how >anyone can stand SCO Xenix (well, pre-3.2, at least). (For that matter, I >can't see how anyone can stand Intel processors....) I used to feel much the same way about both Xenix and Intel processors. Gimme a REAL Unix with a REAL processor. A couple months ago, marketing realities forced us to acquire a 386 system to support several important customers using SCO Xenix, so we got a Bell Technologies MPE and SCO Xenix 2.3. I was pleasantly surprised by the quality of both the software and the hardware (mostly I just try to ignore the fact it has a 386 :-). The SCO documentation is as good or better than any of the previous systems I've had to work on. Most everything I've tried to port has come up with no problems. Prior to getting the MPE, my primary development machine was a Mac-II running A/UX. Subjectively, the MPE seems to be just as fast, if not faster. The multiple virtual terminals on the console (or whatever they are officially called -- I can switch between 12 of them at the touch of a function key) are more useful than the windowing "term" package on the Mac-II. Add to that a real backup device (streaming tape rather than Mac floppies), 9 REAL serial ports (I never did get modem control working on the Mac for both dialin and dialout), etc. have convinced me to switch over to the MPE as my primary machine. The price was also about half of what we have invested in the Mac-II. -Fred -- # Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA # 1-602-491-0048 asuvax!{nud,mcdphx}!estinc!fnf