HDTenEightyP/NetNews huggingface dataset:
Path:
 xenitec!watmath!watserv1!utgpu!csd.unb.ca!morgan.ucs.mun.ca!nstn.ns.ca!news.cs
.
 indiana.edu!sdd.hp.com!swrinde!mips!pacbell.com!decwrl!netcomsv!mork!gerg
From: gerg@netcom.com (Greg Andrews)
Newsgroups: biz.sco.general
Subject: Re: uugetty questions (HUPCL etc.)
Summary: Work your way back from the modem to the computer...
Message-Id: <-xbjd3_gerg@netcom.com>
Date: 27 Mar 92 07:18:43 GMT
 <1992Mar26.180526.8680@wes.on.ca>
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Source-Info:  From (or Sender) name not authenticated.

In article <1992Mar26.180526.8680@wes.on.ca> tomh@wes.on.ca (Tom Haapanen)
 writes:
>gerg@netcom.com (Greg Andrews) writes:
>> tomh@wes.on.ca (Tom Haapanen) writes:
>>
>>> This analysis is also right -- if I watch the modem LEDs, the DTR never
>>> drops.  What I don't understand is *why* DTR doesn't drop momentarily when
>>> I logoff -- shouldn't uugetty do that?
>>>
>>  [explanation of who drops DTR deleted]
>>  [check for HUPCL in the /etc/gettyfs entry]
>>
>I checked, and I am using HUPCL (the setup is very close to the 1-2-3 cycle).
>And yet I can't frop the line, either by logging out or by "stty 0".  What
>could do that?  (It's a standard COM2 port with a 16550AFN).
>

What does the DTR light do when you disable the port?  Nothing is using
the port, so it should turn off.  If it stays on, dig deeper for some
background process holding the port open, and check the modem cable.
If the cable isn't wired right, it could present the wrong signal to the
modem as DTR...


- - --
 .------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {amdahl,claris}!netcom!gerg        |
 |                 |   Internet: gerg@netcom.COM                    |
 `------------------------------------------------------------------'

- ------- Received message ends    ----


------- End of Forwarded Message
From: anto@dutetvd.tudelft.nl (Anto Daryanto)
Newsgroups: biz.sco.general,comp.unix.v386
Subject: SCO UNIX with OS/2 2.0
Date: 8 Apr 92 14:33:11 GMT
Organization: Delft University of Technology


Has anybody actually installed SCO Unix 3.2 v2 *and* OS/2 2.0
in one harddisk (not in one partition, off course)? 

Need information..
Regards,

Anto Daryanto
anto@dutetvd.et.tudelft.nl

|---------------------------------------------------------------|
| Take good care of your environment because it's your own life |
|---------------------------------------------------------------| 
Newsgroups: biz.sco.general
From: bill@Celestial.COM (Bill Campbell)
Subject: Re: Trouble with 3.2.4 cu on in/out Modem line
Organization: Celestial Software, Mercer Island, WA
Date: Thu, 09 Apr 1992 20:35:32 GMT

In <1992Apr09.172347.29448@Celestial.COM> bill@Celestial.COM (Bill Campbell) writes:

Following up my own post from this morning:

>I've had similar problems with device permissions on 3.2v2 when
>using /etc/getty.  The problem seemed to go away when using
>/usr/lib/uucp/uugetty, but has reappeared recently so outgoing
>uucp traffic fails because uucico cannot open the port to dial.

It turns out that the problem was that the /etc/inittab file had
been changed with the kernel was reconfigured.  I forgot to
change the /etc/conf/init.d/at8 files from /etc/getty to
/usr/lib/uucp/uugetty so /etc/inittab had the /etc/getty entries
again (at8 is for the Chase Research multi-port board, this will
vary locally).

Bill
-- 
INTERNET:  bill@Celestial.COM   Bill Campbell; Celestial Software
UUCP:   ...!thebes!camco!bill   6641 East Mercer Way
             uunet!camco!bill   Mercer Island, WA 98040; (206) 947-5591
SPEED COSTS MONEY -- HOW FAST DO YOU WANT TO GO?
From: ronald@robobar.co.uk (Ronald S H Khoo)
Newsgroups: biz.sco.general
Subject: Re: 'C' compiler for SCO
Date: 7 Apr 92 13:30:21 GMT
Organization: Robobar Ltd., Perivale, Middx., ENGLAND.

jle9162@venus.tamu.edu (ECKHARDT, JASON LEE) writes:

> I got a linker error something like this "couldn't find crt0x.o"...
> Is that a file that should come with GCC or is that something I need to 
> buy from SCO?

It is part of the SCO Development System, yes.  It's not impossible
to write alternatives that will work in a subset of cases, but for
100% compatibility, you do really need the vendor's version.

> If it is something I have to buy, does it mean I have to buy
> the whole $900 worth of development system? 

This is a rather difficult point to consider, because it is purely
a marketing decision as to how to unbundle.  SCO have a great deal of
value in their development system that no one would ever use all of:
3 to 5 different debuggers (depending on how you count them :-)
OS2 and DOS cross development, ISAM stuff for XPG3 compliance, etc, etc.

There is less than one floppy's worth of stuff that is essential
for use of any kind of third party development stuff (like the
crt*.o files, *some* include files like <utmp.h>, a basic system
call library, etc) which really IMHO should be bundled into the
base operating system under the same terms as adb is -- ie unsupported
for development use unless you buy the development system.  If the
user uses it with a third party development system, then it is up
to the vendor of that system to support the use of the base interface
module.

The absence of such a "basic system interface" development module
is an unfair restriction placed on third party development system
suppliers like GNU.  Also, it really works against SCO themselves,
since it prices them out of the low-cost development market, since
it forces their customers to buy a development kit 90% of which
they cannot afford.  The current SCO development system is *25
Megabytes* in size.  I estimate that the "system interaction module"
would be no more than a megabyte.  To force people to buy 25 times
as much stuff to get something that should never have been debundled
from the OS is not nice at all.

If you have any buying clout with SCO, I would urge you to bring it to
bear on SCO's marketing people, and show them the error of this
restrictive practice.
-- 
Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
-- 
/home/ronald/.signature: Not a name file
Newsgroups: biz.sco.general
From: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Subject: Re: 1.2 GB disk
Organization: Omen Technology INC, Portland Rain Forest
Date: Fri, 17 Apr 1992 09:15:25 GMT

In article <9204141127.aa13394@openage.COM> paul@openage.COM (Paul A. Fischer, Sr UNIX Sys Consultant) writes:
>>I have a Adaptec 1542A controller with a Wren VI (766MB) attached to my 
>>SCO 3.2.2 system. Can I easily add an external 1.2 MB SCSI drive without
>>problems or would I have to change to a 1542B controller?

I have a 1542A driving a Micropolis 1598 which is listed as having a
SCSI-2 interface.  Once I got the jumpers right I had no problems.
Previous disk (now 2nd drive) was/is a Wren V.

Newer versions of 386 Unix support the longer SCSI commands needed to
support disks > 1 GB.  The 1598 falls just under this limit.

Only SCO problem I have with the 1542A is booting on high bus speed
486/50 motherboards.  I have to run the AT bus at, say, 6 MHz to
work around a timing problem in the "ad" driver.

I am still looking for a 486/50 (or 486/33 for that matter) that
works properly with 32 MB AND secondary cache enabled for all 32 MB.
My 486/33 runs fine with 16 or 32 MB but provides no way to cache the
upper 16 MB, where Unix likes to run programs if given the chance.

-- 
Chuck Forsberg WA7KGX          ...!tektronix!reed!omen!caf 
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
  Omen Technology Inc    "The High Reliability Software"
17505-V NW Sauvie IS RD   Portland OR 97231   503-621-3406
Newsgroups: biz.sco.general
From: doug@uuisis.isis.org (doug)
Subject: SCO UNIX uucico bug with Trailblazers?
Organization: International Shared Information Service (Ottawa)
Date: Tue, 07 Apr 92 00:12:22 GMT

I notice that uucico on my SCO Unix cannot recover from a retrain when
Telebit T-2500 does one on a long uucp connection in PEP mode.

Does anyone know of any cures or remedies for this?

Pls. reply by mail.

----------------------------------------------------------------------
UUCP: uunet.ca!uuisis.isis.org!doug                Voice: 613-722-4724
DNS:  doug@uuisis.isis.org, doug@uuisis.UUCP, doug@isishq.fidonet.org
                      SKAN Communications Inc
      POST: P.0. Box 3041, Stn C., Ottawa, K1Y 4J3, CANADA 
----------------------------------------------------------------------
From: wex@dali.pws.bull.com (Member, Redheads Anonymous)
Newsgroups: biz.sco.general
Subject: Anyone had gethostname() fail on them?
Date: 10 Apr 92 17:04:23 GMT
Distribution: biz
Organization: Bull Worldwide Information Systems Inc.

I'm using a fairly standard call like this:

static char hostname[MAXHOSTNAMELEN];
   .
   .
   .
  if (gethostname(host, MAXHOSTNAMELEN) < 0)
    {
	perror("Luze -- no hostname");
	exit(2);
    }

And what happens is I get the message:

  Luze -- no hostname: Invalid argument

Any ideas why?  The executable resides on an NFS-mounted partition, but this
shouldn't cause problems, should it?

--
--Alan Wexelblat                        phone: (508)294-6120
Bull Worldwide Information Systems      internet: wex@pws.bull.com
Billerica, MA                                     wexelblat.chi@xerox.com
A++ is an object-oriented version of a perfect score.
Newsgroups: biz.sco.general
From: fitz@wang.com (Tom Fitzgerald)
Subject: Re: MY MAILER IS BRAIN DEAD!
Organization: Wang Labs, Lowell MA, USA
Date: Mon, 06 Apr 92 06:50:03 GMT

davidf@golem.uucp (David J. Fiander) writes:

> That's not quite true.  The biggest difference between 3.2v2
> MMDF and 3.2v4 MMDF is that v4 has support for the nameserver
> in it.  This is a _major_ improvement, but the older one can
> hardly be called braindead, since we ran it for a long time
> with no problems.

I *hope* 3.2.v4 has a lot of bug fixes too.  Between the infamous
"error 99", the confusions between RFC822-precedence and UUCP precedence
in addresses, the 1-uux-per-addressee limitation and all the other
problems, I'd think hard before I went to a new verion of MMDF.

Rich's suggestion is a good one - sendmail+IDA 1.4.4.1 is much, much better
than MMDF.  The m4 configuration stuff builds the sendmail.cf for you, and
sendmail does lots of things that MMDF just can't be configured to do.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz
Newsgroups: biz.sco.general
From: Network Mailer <mailer%dearn.bitnet@utcs.utoronto.ca>
Subject: Undelivered mail
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Tue, 31 Mar 1992 01:06:19 GMT

Your mail was not delivered to some or all of its
intended recipients for the following reason(s):

No recipients for this node.

--------------------RETURNED MAIL FILE--------------------
Received: from WATDCS(DCSMAIL) by DEARN (Mailer R2.08) id 4243;
          Tue, 31 Mar 92 02:06:19 MET
Received: from WATDCS by WATDCS.UWaterloo.ca (Mailer R2.08uw) with BSMTP id
 8599; Mon, 30 Mar 92 15:39:35 EST
Received: from watmath.waterloo.edu by WATDCS.UWaterloo.ca (IBM VM SMTP V2R1)
   with TCP; Mon, 30 Mar 92 15:39:32 EST
Received: from xenitec.uucp by watmath.waterloo.edu with uucp
	id <AA04208>; Mon, 30 Mar 92 15:40:37 -0500
Resent-Date: Mon, 30 Mar 1992 12:59:12 GMT
Resent-Message-Id: <9203302040.AA04208@watmath.waterloo.edu>
Resent-From: scogen@xenitec.on.ca
Newsgroups: biz.sco.general
From: Network Mailer <mailer%dearn.bitnet@utcs.utoronto.ca>
Subject: Undelivered mail
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Mon, 30 Mar 1992 12:59:12 GMT
Message-Id: <92Mar30.080044est.9597@ugw.utcs.utoronto.ca>
Source-Info:  From (or Sender) name not authenticated.

Your mail was not delivered to some or all of its
intended recipients for the following reason(s):

No recipients for this node.

--------------------RETURNED MAIL FILE--------------------
Received: from WATDCS(DCSMAIL) by DEARN (Mailer R2.08) id 4271;
          Mon, 30 Mar 92 13:59:12 MET
Received: from WATDCS by WATDCS.UWaterloo.ca (Mailer R2.08uw) with BSMTP id
 3956; Mon, 30 Mar 92 06:51:57 EST
Received: from watmath.waterloo.edu by WATDCS.UWaterloo.ca (IBM VM SMTP V2R1)
   with TCP; Mon, 30 Mar 92 06:52:00 EST
Received: from xenitec.uucp by watmath.waterloo.edu with uucp
	id <AA09127>; Mon, 30 Mar 92 06:54:48 -0500
Resent-Date: Mon, 30 Mar 1992 05:10:03 GMT
Resent-Message-Id: <9203301154.AA09127@watmath.waterloo.edu>
Newsgroups: biz.sco.general
From: Network Mailer <mailer%dearn.bitnet@utcs.utoronto.ca>
Subject: Undelivered mail
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Mon, 30 Mar 1992 05:10:03 GMT
Message-Id: <92Mar29.231058est.9225@ugw.utcs.utoronto.ca>
Source-Info:  From (or Sender) name not authenticated.

Your mail was not delivered to some or all of its
intended recipients for the following reason(s):

No recipients for this node.

--------------------RETURNED MAIL FILE--------------------
Received: from WATDCS(DCSMAIL) by DEARN (Mailer R2.08) id 1960;
          Mon, 30 Mar 92 06:10:03 MET
Received: from WATDCS by WATDCS.UWaterloo.ca (Mailer R2.08uw) with BSMTP id
 2214; Sun, 29 Mar 92 23:07:02 EST
Received: from watmath.waterloo.edu by WATDCS.UWaterloo.ca (IBM VM SMTP V2R1)
   with TCP; Sun, 29 Mar 92 23:07:03 EST
Received: from xenitec.uucp by watmath.waterloo.edu with uucp
	id <AA27385>; Sun, 29 Mar 92 23:09:29 -0500
Resent-Date: Sat, 28 Mar 1992 15:05:27 GMT
Resent-Message-Id: <9203300409.AA27385@watmath.waterloo.edu>
Newsgroups: biz.sco.general
From: Network Mailer <mailer%dearn.bitnet@utcs.utoronto.ca>
Subject: Undelivered mail
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Sat, 28 Mar 1992 15:05:27 GMT
Message-Id: <92Mar28.102419est.8763@ugw.utcs.utoronto.ca>
Source-Info:  From (or Sender) name not authenticated.

Your mail was not delivered to some or all of its
intended recipients for the following reason(s):

No recipients for this node.

--------------------RETURNED MAIL FILE--------------------
Received: from WATDCS(DCSMAIL) by DEARN (Mailer R2.08) id 0102;
          Sat, 28 Mar 92 16:05:27 CET
Received: from WATDCS by WATDCS.UWaterloo.ca (Mailer R2.08uw) with BSMTP id
 6684; Sat, 28 Mar 92 09:44:12 EST
Received: from watmath.waterloo.edu by WATDCS.UWaterloo.ca (IBM VM SMTP V2R1)
   with TCP; Sat, 28 Mar 92 09:44:12 EST
Received: from xenitec.uucp by watmath.waterloo.edu with uucp
	id <AA23984>; Sat, 28 Mar 92 09:46:53 -0500
Resent-Date: Fri, 27 Mar 1992 13:24:54 GMT
Resent-Message-Id: <9203281446.AA23984@watmath.waterloo.edu>
Newsgroups: biz.sco.general
From: Network Mailer <mailer%dearn.bitnet@utcs.utoronto.ca>
Subject: Undelivered mail
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Fri, 27 Mar 1992 13:24:54 GMT
Message-Id: <92Mar27.082750est.8300@ugw.utcs.utoronto.ca>
Source-Info:  From (or Sender) name not authenticated.

Your mail was not delivered to some or all of its
intended recipients for the following reason(s):

No recipients for this node.

--------------------RETURNED MAIL FILE--------------------
Received: from WATDCS(DCSMAIL) by DEARN (Mailer R2.08) id 3180;
          Fri, 27 Mar 92 14:24:54 CET
Received: from WATDCS by WATDCS.UWaterloo.ca (Mailer R2.08uw) with BSMTP id
 7610; Fri, 27 Mar 92 08:18:16 EST
Received: from watmath.waterloo.edu by WATDCS.UWaterloo.ca (IBM VM SMTP V2R1)
   with TCP; Fri, 27 Mar 92 08:18:18 EST
Received: from xenitec.uucp by watmath.waterloo.edu with uucp
	id <AA13081>; Fri, 27 Mar 92 08:20:06 -0500
Resent-Date: Thu, 26 Mar 1992 18:05:26 GMT
Resent-Message-Id: <9203271320.AA13081@watmath.waterloo.edu>
Newsgroups: biz.sco.general
From: tomh@wes.on.ca (Tom Haapanen)
Subject: Re: uugetty questions (HUPCL etc.)
Organization: Waterloo Engineering Software
Date: Thu, 26 Mar 1992 18:05:26 GMT
Message-Id: <1992Mar26.180526.8680@wes.on.ca>
 <g_-jdfagerg@netcom.com>
Source-Info:  From (or Sender) name not authenticated.

gerg@netcom.com (Greg Andrews) writes:
> tomh@wes.on.ca (Tom Haapanen) writes:
>>>>	- After I logoff, the system does not drop the connection, and
>>>>	  I have to do it manually from my terminal emulator.

>>> Then the computer is failing to turn off the DTR signal, or the TrailBlazer
>>> Plus modem has been set to ignore DTR.  The modem should be set to hang up
>>> and reset when DTR turns off (S52=2).

>> This analysis is also right -- if I watch the modem LEDs, the DTR never
>> drops.  What I don't understand is *why* DTR doesn't drop momentarily when
>> I logoff -- shouldn't uugetty do that?

> When you log out, the shell closes the modem port.  When that happens, you
> want the tty driver to turn off the DTR signal until the next program opens
> the port (normally getty or uugetty a couple of seconds later).
> The usual way to make this happen is to include HUPCL (hang up on close) in
> the gettydefs entry.  Make sure it's in the same part of the gettydefs entry
> as the second speed code.

I checked, and I am using HUPCL (the setup is very close to the 1-2-3 cycle).
And yet I can't frop the line, either by logging out or by "stty 0".  What
could do that?  (It's a standard COM2 port with a 16550AFN).

[ \tom haapanen    "i don't even know what street canada is on" -- al capone ]
[ tomh@wes.on.ca                   "trust the programmer" -- ansi c standard ]
[ waterloo engineering software      "to thine own self be true" -- polonius ]
Newsgroups: biz.sco.general
From: davidf@golem.uucp (David J. Fiander)
Subject: Re: MY MAILER IS BRAIN DEAD!
Date: Tue, 07 Apr 1992 10:30:59 GMT

According to fitz@wang.com (Tom Fitzgerald):
>
>I *hope* 3.2.v4 has a lot of bug fixes too.  Between the infamous
>"error 99"

Actually, this was just one of the error messages.  Whenever
one of these was generated, the rmail which failed also
generated a bounce message back to the originator.

>            the confusions between RFC822-precedence and UUCP precedence
>in addresses

This is not a bug.  This is different interpretation of a very
vague part of the standard.  MMDF is _not_ the only system that
decides the way it does.

>              the 1-uux-per-addressee limitation and all the other
>problems

Fixed.

>
>Rich's suggestion is a good one - sendmail+IDA 1.4.4.1 is much, much better
>than MMDF.  The m4 configuration stuff builds the sendmail.cf for you, and
>sendmail does lots of things that MMDF just can't be configured to do.

Well, there are two assumptions here.  The first is that one
has a dev. sys., and the other is that syntax based routing is
a good thing.  Fortunately it's possible to configure IDA
sendmail to not perform header raping.

The best thing about MMDF is that a human being can read the
configuration (sort of) in about 15 minutes without having a
manual sitting beside him.

- David
Newsgroups: biz.sco.general
From: doug@uuisis.isis.org (Doug Thompson)
Subject: uucico problem with SCO UNIX 2.3.2 and T-2500
Organization: International Shared Information Service (Ottawa)
Date: Sun, 12 Apr 92 20:21:40 GMT

We're doing a large newsfeed and the problem is that uucico sessions
abort with disturbing frequency. No, it is not modem initialization.
We've spent months talking to Telebit and fiddling everything there. No,
it is not 'too many re-trains'. We can force re-trains and everything
recovers and keeps going just fine. Sometimes the failures we observe
are accompanied by re-trains, sometimes they are not.

No it is not the other end, he does lots of news with others without
this problem. We find the problem occurs on other PEP uucico links too.

No, it is not a bad phone line. We have four lines and four T-2500s and
the problems occur on local calls on all the lines with all our uucp
neighbours. 

No, it's not super-lethal. Most sessions work fine - and terminate
normally. The really long ones, more than an hour, frequently stop
before they are done.

I've been searching for a diagnosis for a long time and about all I am
able to do is rule out every obvious possibility. There is nothing wrong
with the four modems. The problem occurs in V32 as well as PEP mode. The
problem occurs whether we use standard serial cards at 19200 (tty1A) or
the multi-port digiboard. Makes no difference. We have tried different
versions of uucico. Same problem. We have modified gettydefs in many
different ways, and while it appears we can make the problem worse, we
can't make it better.

What's left to check? What is *the* problem??

What I'm hoping is that someone out there in SCO-Land has run into this
kind of symptom before and has found a cause and a cure. I've consulted
with sysadmins of many Xenix and SCO Unix systems and no one else is
running into it. 

Something is wrong and badly needs fixing but Sherlock Holmes isn't
around and I'm stumped.

=Doug

----------------------------------------------------------------------
UUCP: uunet.ca!uuisis.isis.org!doug                Voice: 613-722-4724
DNS:  doug@uuisis.isis.org, doug@uuisis.UUCP, doug@isishq.fidonet.org
                      SKAN Communications Inc
      POST: P.0. Box 3041, Stn C., Ottawa, K1Y 4J3, CANADA 
----------------------------------------------------------------------

Xref: sparky biz.sco.general:1814 biz.sco.opendesktop:397
From: lin@cdin-1.compu.com (Lin Chen)
Newsgroups: biz.sco.general
Subject: Re: Trouble with 3.2.4 cu on in/out Modem line
Date: 13 Apr 92 21:21:33 GMT
Article-I.D.: cdin-1.1992Apr13.212133.19673
Reply-To: lin@compu.com.CUMPU.COM (Lin Chen)
Organization: CompuData

In article <1992Apr9.100310.18483@rtf.bt.co.uk> traub@rtf.bt.co.uk (Michael Traub) writes:

>If I use /usr/lib/uucp/dialTBIT and run "cu <phone >number>"  I  get  the  
>connect but have to hit a key for every character to be  echoed  from  the  
>remote end. I have run dialTBIT with the "-z" option to set the modem up.

I am having the exact same problem with our Telebit on UNIX v4 which worked 
perfectly with XENIX 2.3.3 before I upgraded our system last week. I even
tried the dialTBIT.c I brought over from my XENIX but it still does the same
thing !!

We are not alone, are we ? Any clues ?

-- 
Lin Chen	      * Work : lin@COMPU.COM	     	     * (215)824-3000
CompuData Inc.        *        {dsinc,uunet}!cdin-1!lin	     *      x209
10501 Drummond Road   * Home : lin@icdi60.COMPU.COM	     * 
Philadelphia  PA19154 *        {dsinc,uunet}!cdin-1!icdi60!lin *
Newsgroups: biz.sco.general
From: zoo.toronto.edu!telly!becker!united!steved@watmath.UUCP
Subject: Xenix 2.3.4, ESDI disk, SCSI tape
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Reply-To: united!steved@watmath.UUCP
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Tue, 7 Apr 1992 14:16:09 GMT

   I'm trying to set up a Xenix 386GT 2.3.4 system with an ESDI hard
drive and a SCSI tape.  The hard drive is no problem, but the tape
is proving to be troublesome.

   We tried "mkdev tape", set it up as a SCSI tape, and all that jazz.
It did not ask us to relink the kernel, and /dev/rct0 does not work.

   SCO support tells me that it is normal under Xenix for the %tape
hardware configuration line not to appear at boot time for SCSI
tapes, but rather when you first use it, and they faxed me a page
dealing with that.  They also tell me, on the one callback a day that
they're giving me, that it's also normal for the Adaptec card (1542B,
in this case), not to be recognized at boot time.

   Their solution so far has been to edit /etc/default/tape to change
the default device from /dev/xct0 to /dev/rct0, and try "tape status"
or "tape reset".  Any tape command produces an error telling me that
the drivers for the SCSI card and/or the tape drive are not linked
into the kernel.

   Ideas?

-Steve
--
steved@united.UUCP                  ...!{uunet,xrtll,becker}!united!steved
--------------------------------------------------------------------------
Stephen M. Dunn, CNE, Senior Systems Analyst, United System Solutions Inc.
104 Carnforth Road, Toronto, ON, Canada M4A 2K7             (416) 750-7946

Newsgroups: biz.sco.general