HDTenEightyP/NetNews huggingface dataset:
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: .plan and remote fingering problem
Date: 23 Dec 92 04:46:23 GMT
Organization: Izot's Swamp

perry@johann.jpunix.com (John Perry) writes:

> 	I had an interesting problem pointed out to me when a friend
> tried to "finger" my account on my SCO ODT 2.0 system.

   What are the permissions on your .plan file?

  Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
                Now I've lost everything, I give to you my soul
           And the meaning of all that I believed before escapes me
                  In this world of none, no thing, and no one
                            - Genesis, _Afterglow_
From: dave@das13.snide.com (Dave Snyder)
Newsgroups: biz.sco.general
Subject: Re: BIOS shadowing, Re: Performance degradation under SCO UNIX
Date: 31 Dec 92 23:17:34 GMT
Organization: Snide Computer Services - Folcroft, PA


In article <9212300958.aa07997@scoke.sco.COM> belal writes:
} HOWEVER.  Shadowing is implemented various ways, depending on the
} machine's BIOS.  Some implementations of shadowing are actively harmful
} to UNIX and *must* be turned off.  I always recommend turning all
} shadowing off if you are having any odd problems.  If you are absolutely
} sure that it doesn't hurt your system, and you want the dots to move
} quickly at boot time, then turn it back on.
} 
I've been following this thread for a long time now, and have kept silent.
The reason for this is my total ignorance of BIOS stuff.  This recent
post however got me thinking... did the DOS guy who built my machine do
something unnecessary or even worse, something harmful in my BIOS.

This is how the AMI BIOS for my 386/40 machine running SCO Unix 3.2.4.1 is
set up:
    Video   ROM Shadow    C000,32k    Enabled
    Adapter ROM Shadow    C800,32k    Disabled
    Adapter ROM Shadow    D000,32k    Disabled
    Adapter ROM Shadow    D800,32k    Disabled
    System  ROM Shadow    F000,64k    Enabled

Does this look right?  My machine runs fine except for the problem with
the tape drive and floppy drive not being able to work simultaneously.
Which is weird, I have an Archive 2150L tape drive w/ an Archive VP402
controller card and I still can't use both simultaneously.  Could a
wrong BIOS setting be causing this.  Any pointers would be appreciated.

Thanks!
DAS
-- 
David Snyder @ Snide Computer Services - Folcroft, PA          Current Release
                                                               is db4glgen-3.9
UUCP:  ..!uunet!das13!dave   INTERNET:  dave.snyder@snide.com
From: infmx!ten_forward!aland@uunet.UU.NET (Alan Denney)
Newsgroups: biz.sco.general
Subject: Re: Performance issues revisited
Date: 23 Dec 92 20:07:38 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Cc: ten_forward!aland@uunet.UU.NET
Precedence: bulk

>> From uunet!xenitec.on.ca!news Wed Dec 23 11:04:25 1992
>> Path: xenitec!eff!ssd.intel.com!uunet!consult!bob
>> From: Bob Willey CDP <uunet!consult!bob>
>> Subject: Re: Performance issues revisited
>> Reply-To: Bob Willey CDP  <uunet!consult!bob>
>> 
>> NOTE:  Where do you get the above utility???? ^^^^^^^  SCSICNTL.EXE
>>        I have looked on Adatpec's BBS, Seagate's, Quantum's, and ours
>>        and did not find this utility.  Also checked several other BBS's
>>        and could not locate it.

It's not on Adaptec's BBS, as it's not an Adaptec utility per se.  It is
widely available solely due to the kindness of Roy Neese, a senior SCSI
engineer at Adaptec.  It is uucp-able from the "adaptex" server, and 
may well be on uunet or elsewhere.  Here is a snippet from mail Roy has
sent out in the past (this info is a year old but, to my knowledge, has
not changed.  corrections welcome.)

-------------------------------------------------------------------------------
adaptex uses a Telebit T1000.  So 9600 baud connections can only be made
using PEP.

Put the following line in your /usr/lib/uucp/Systems file.

adaptex Any ACU BAUD 18174886893 -\d\d\d-gin:-BREAK\d\d\d-gin:-BREAK\d\d\d-gin: suucp

NOTE: The word BAUD can be replaced with either 9600, 2400, or 1200.

You can snarf the following compressed binary files via uucp.

1540CPU.LIST.Z  GRDRIVE.EXE.Z   SCSICNTL.EXE.Z  1540DRV.LIST.Z  GREAD.EXE.Z
SCSIHA.SYS.Z    1540USR.MAN.Z   GWRITE.EXE.Z    SETSCSI.EXE.Z   sco.patches.Z
sds3.desc.Z     LIST            setscsi.doc.Z   @0F1F.ADF.Z     README
inq.Z           scsicntl.doc.Z  GETDEVS.EXE.Z   SCSI.EXE.Z      list

Use the following command:

uucp adaptex!~/filename /usr/spool/uucppublic/filename

--
uucp adaptex\!~/scsicntl.doc.Z /var/spool/uucppublic/scsicntl.doc.Z
uucp adaptex\!~/SCSICNTL.EXE.Z /var/spool/uucppublic/SCSICNTL.EXE.Z

--
Replace 'filename' with the appropriate name of the file that you want.  To
those who only want the mode sense fiddler, it is the SCSICNTL.EXE.Z file.

			Roy Neese
			Adaptec Senior SCSI Applications Engineer
			UUCP @  neese@adaptex
-------------------------------------------------------------------------------

If you cannot get it any other way, you might try re-mailing to the list
to see if somebody out there with a current version might mail you a
compressed/uuencoded copy.

Hope this helps.

--
Alan Denney      aland@informix.com      {pyramid|uunet}!infmx!aland

"Too many hands on my time
 too many feelings --
 too many things on my mind.
 When I leave, I don't know what I'm hoping to find
 When I leave, I don't know what I'm leaving behind."   -- Peart
From: tpotter@tedshom.nbn.com (Ted Potter)
Newsgroups: biz.sco.general
Subject: rlogin sco unix 3.2 rel 2.0
Keywords: login name rlogin
Date: Fri, 1 Jan 93 22:20:33 -0800
Reply-To: tpotter@tedshom.nbn.com
Organization: Data Acquisition Systems


I created an account today with eight characters on two machines
with an eithernet connection. Using rlogin from one machine to
the other the login fails the first time.

I then created an account on both machines with seven characters
and rlogin was able to login on the remote machine the first time.

I do not have this problem logging into the machine directly from
a terminal.

I use the rlogin program at the end of .profile ie rlogin machine 
-l accountname

Before I assume this is a bug, has someone else seen this problem
arise ? - I don't have the version number of the ftp handy but
it is a early release.

thanks in advance for any input!



-- 
tpotter@tedshom.nbn.com tedshom!tpotter
Newsgroups: biz.sco.general
From: infmx!ten_forward!aland@uunet.UU.NET (Alan Denney)
Subject: Re: Performance issues revisited
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Cc: ten_forward!aland@uunet.UU.NET
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Tue, 29 Dec 1992 21:10:32 GMT
Precedence: bulk

>> From aland@ten_forward Wed Dec 23 12:07:26 1992
>> To: uunet!consult!bob, uunet!xenitec.on.ca!scogen
>> Subject: Re: Performance issues revisited
>> Cc: aland@ten_forward
>> 
>> <SCSICNTL is> not on Adaptec's BBS, as it's not an Adaptec utility ...
>> It is uucp-able from the "adaptex" server, and ...
>> 
>> adaptex Any ACU BAUD 18174886893 -\d\d\d-gin:-BREAK\d\d\d-gin:-BREAK\d\d\d-gin: suucp

This number appears to be disconnected.  I've sent mail to Roy asking for
the current number; will advise.  (Does anybody know if the 817 area code
split recently, or know the current number for adaptex?)

--
Alan Denney      aland@informix.com      {pyramid|uunet}!infmx!aland
    Never trust a UNIX programmer who can't spell "kernel".
Newsgroups: biz.sco.general
From: mike%jim.uucp@wupost.wustl.edu (Mike S.)
Subject: Re: Serial terminals-reset when line dropped (SCO 3.2.2)
Organization: BITS, St. Louis, MO
Date: Mon, 21 Dec 1992 16:18:41 GMT

brian@ilinx.wimsey.bc.ca (Brian J. Murrell) writes:

>sounds like you would like "modem functionality" this is what normally
>happens on a modem line.  You would have to set up your serial ports as if

Basically, yes, that is what we want.

>Watch out for "flow control" lines such as DTR, as it will drop when the 
>terminal's buffer overflows and would kill the processes on your tty - the 
>users would not be happy.

Yep, we discussed this, but decided DTR wasn't suitable for what
we need, with the same reasoning.

Thanks,
Mike
-- 
mike%jim.uucp@wupost.wustl.edu
Newsgroups: biz.sco.general
From: vancleef@netcom.com (Henry van Cleef)
Subject: Re: compiling GNU programs
Organization: Netcom--posted from Andover, Mass.
Date: Sat, 2 Jan 1993 02:05:35 GMT

In article <9212302046.aa12907@ohriman.ohriman.mi.org> jep@ohriman.mi.org writes:
>	I've got a few problems compiling GNU software which I'm hoping
>someone here can help with.
>	I'm running gcc 2.3.3 (which, by the way, appears to compile without 
>problems using the instructions for SCO).  I've had the same problems
>with 2.2.2 and 2.3.2 in the past, which I compiled using different
>sets of instructions and patches provided by people on this list.
>	When I try to compile gdb 4.7, everything appears to go smoothly
>until it gets to "readline.c".  There I get massive errors; parse
>errors originating with /usr/include/sys/stream.h, including:

You will have to be specific about what version of SCO Unix you are
using.  YOur comments imply 3.2.4, and I have spent the last few days
living with GNU's attitudes towards SCO's 3.2.4 setup.  

The gdb readline.c will compile if you set the CC line in the makefile
to gcc -traditional.  If you still have trouble, try forcing
-D_NO-PROTOTYPE in the CFLAGS.  

All else fails, compile it with the stock cc.  If you have an early
version of the 3.2.4 devsys, get SLS lng353a from sosco---this is the
version of the stock cc I am using.  

The problems I have had, and that appear to be yours from your
description, stem from the header #ifdefs for __STDC__, _X_OPENSOURCE
and _POSIX_SOURCE.  GCC won't take full function prototypes under 
-traditional, and SCO has succeeded in preventing the errno.h
assignments in some cases.  On top of which, various GNU things claim to
be ansi or posix, but aren't, in terms of SCO's headers.  A brute force
-U__STDC__ without the -traditional flag seems to make a lot of problems
go away with GCC.  

My config is 3.2 vee four, GCC 2.3.3, GDB 4.7.  I have not yet taken a
whack at libg++, although have notes on what it took to make that happen
(plenty) on a 3.2.0 system with GCC-2.3.2.  

Don't be deluded by the idea that GNU software is either clean or
consistent with other GNU things.  -Di386, -U__STDC__, and _NO_PROTOTYPE
seem to make things work.  Read your headers, and learn how to read the
#ifdefs.  Those are what you are going to compile with.  

As far as the finxinc.sco script that comes with GCC 2.3.3, I have not
run it, and it looks to me like a horrible hack.  

So far as standards are concerned, it is much more difficult to port
code that claims to meet standards these days, and I am very tired of
the stuff around "Standard C." Shutting off of all the error numbers in
sys/errno.h is the living end, and I "fixed" that problem on my system.

 
-- 
Hank van Cleef  vancleef@netcom.com vancleef@tmn.com  Andover, Mass.
Unix systems consultant---kernel, device drivers, networking, X11
SysV, BSD, Sun, Ultrix, AIX, SCO. Porting a specialty. 
	     The Union Institute  History of Science
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: Performance issues revisited
Date: 23 Dec 92 04:49:02 GMT
Organization: Izot's Swamp

Bela Lubkin <belal@sco.COM> writes:

> Real conclusions: you'd better run some extensive tests like this before
> you can even begin to understand the transfer rate characteristics of
> your disk & CPU combination -- and that's only one small part of
> characterizing the overall performance of your disk subsystem.

   Hmm, might that test be affected by fragmentation of available space?  If 
so, it would explain why the track buffer (which is only sensible controller 
design: since, on average, it takes only slightly more than twice as long to 
read a whole track as it would take to wait for and read a single sector, why 
not?) is not having the desired effect.

  Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
                Now I've lost everything, I give to you my soul
           And the meaning of all that I believed before escapes me
                  In this world of none, no thing, and no one
                            - Genesis, _Afterglow_
From: belal@sco.COM (Bela Lubkin)
Newsgroups: biz.sco.general
Subject: boot-time delay, Re: Two things....
Date: 30 Dec 92 07:27:13 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

Michael B Garrett wrote:

> Also: Has anyone ever seen an ODT system that took about 1 minute to start
> reading the .text and .data files on bootup? Mine waits at least that long
> after you hit "enter" at the "Boot:" prompt. Since it has done this since
> ODT 1.0, I assumed it was just a SCSI kinda thing, but my last client
> got SCSI also, and it doesn't do it there. Both machines are EISA 486/33,
> mine is a Bustek 742A and the client's is a 1740A.
> 
> Is this slowness indicative of some problem I'm unaware of, or is it
> just because the disk is slower (Maxtor 660MB) ?

Are you sure this behavior dates back so far?  (I sort of doubt it since
at the time that ODT 1.0 was current, 486/33 EISA machines did not
exist).  I wonder because a delay at exactly that point in the boot
process was introduced with SCO UNIX 3.2v4.0 and ODT 2.0.  The delay is
indicative of the boot program being extremely careful about caches.
ODT 1.1 and UNIX 3.2v2 had problems on 486 machines because /boot could
get confused by the 486 internal cache.  The new code is "paranoid" and
does (slow) cache-flush instructions while sizing memory.

In a later release (I'm not sure which release this will appear in), the
delay will be user-selectable (you can choose to have it skip the cache
flushes, and *hope* it's safe); and, instead of sitting there looking
like it hung, it will print dots:

  Boot
  :

  Sizing memory
  .................
  Loading hd(40)unix .text
  ................................

Anyway, under 3.2v4.x and ODT 2.0, the delay is normal (and varies
depending on CPU speed, cache design etc.)

>Bela<
From: messina@netcom.com (Tony Porczyk)
Subject: Need recommendations for SCO *NIX OS
Followup-To: poster
Organization: Messina Software
Date: Sun, 27 Dec 1992 21:51:12 GMT


I need some advice from experienced SCO *NIX users on the choice of
the OS.  I want to run *NIX as a terminal server.  X is not important,
although it would be nice if I could add it later on.  Here are the
specs of the hardware i want to use, with questions following it:
(I tried a couple of dealers, but they didn't seem overly informative)

Motherboard     Micronics Gemini 486/33 w/16 MB of memory (ISA bus)
BIOS            Phoenix 80486 ROM BIOS Plus Version 0.10 G17-2
Disk Controller SCSI Adaptec 1542B
Disk            340 MB SCSI Maxtor
Video           Oak 512 + VGA B&W monitor
Keyboard        Northgate Omni Key 101

1. Will any known SCO *NIX run on it?  Is anyone running it in a
   similar configuration?  Any suggestions for changes (not too
   extensive, hopefully)? 
2. I would like 3+ user version with development tools (no X, not
   yet).  What would you recommend?  How much would it cost?
3. Would it be possible to add windowing system later on to it?
4. I need to find (hopefully, as inexpensive as possible) a
   spreadsheet and a database (up to 20-40 MB total table size) that
   would exchange data nicely (from database to spreadsheet essential,
   the other way is an icing on the cake).  Any recommendations? 
   Costs involved? 
5. Does troff come with all of the SCO *NICES?  Support for HP Laser
   Printers PCL?
6. Are there SCO *NICES that support 3+ users, but do not require Dev
   Tools?  (For the end user's platform).  How much do they run?
7. Can SCO *NIX be installed from floppies (before the tape is added
   later on)? 
8. Any recommendations for (inexpensive but reliable) SCSI tape?

Since the above would be planned to develop for (and serve) small
offices, the cost factor is *very* important. 

Thanks a million,

Tony
From: bob@consult.UUCP (Bob Willey)
Newsgroups: biz.sco.general
Subject: Re: Configuring an Adaptec 1542B ...
Date: 31 Dec 92 12:38:40 GMT
Reply-To: bob@consult.UUCP (Bob Willey)
Organization: CCS Enterprises, Inc.

In article <9212301744.AA00859@jrsalb1.UUCP> jrsalb1!tgn@brspyr1.brs.com (Tim Northrup) writes:
>It has an Adaptec 1542b controller with 2 Maxtor SCSI drives, and a SCSI
>Syquest 44 (all internal, ID's 0, 1 and 2, terminators on the Syquest drive
>& adapter only).  Everything works okay at the moment.
>Currently, the 1542b is configured for the default of 5 mb/s transfer speed.
>Has anyone had any problems using the higher settings?  A friend (who set

I was the one who prompted some of this recent discussion due to our 
inhouse upgrade.  After doing a fair amount of research and a lot of help
from the net, here is my findings.

You must have the 1542B set to 5mb/s transfer speed.  That is what the
driver is set for.  Do not try to run it faster.
You might want to get xnx316 which is a patch for the Adaptec drivers
under SCO Xenix.  It adds some enhancements (like allowing tape reten
to work) and supposedly some performance issues.
There is a program written by Roy Neese @ Adaptec (not supported by
Adaptec) called SCSICNTL.EXE which allows you to access the drive
and set up the drive.  Things like onboard cache in the drives are
sometimes turned off by default.  I have been trying to get hold of
this utility and am awaiting a reply for assistance.  Once I get hold
of it, I will also put it up on our BBS system here at the office.
If anyone knows where I can get this utility (BBS somewhere??),
it would be most appreciated.  The adaptex system does not answer,
and it is NOT on their BBS.

-- 
>.. Bob Willey, CDP          ..  |  ..  uunet!consult!bob  bob@ccs.com   ..<
>.. CCS Enterprises, Inc.    ..  |  ..   Office: (410) 820-4670          ..<
>.. P.O. Drawer 1690         ..  |  ..      FAX: (410) 476-5261          ..<
>.. Easton, Maryland 21601 ......|......... BBS: (410) 476-5098 ...........<
From: kbvan!dave@uunet.UU.NET (Dave Van Allen)
Newsgroups: biz.sco.general
Subject: Performace degradation under SCO
Date: 22 Dec 92 17:19:15 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk


> In article <1472@pacsoft.com> mike@pacsoft.com (Mike Stefanik) writes:
> >This posting is on behalf of a friend of mine who is having a problem
> >with an SCO UNIX upgrade.  A customer of his originally had a 486/33
> >with 16M of memory and a 1G SCSI drive.  Recently, the system was upgraded
> >to a 486/50 with 32M of memory and an additional 1G drive was added. The
> 
> >is now crawling along at a snail's pace.
> 

The problem may not be related to kernel parameters at all. Many ISA bus
motherboards will exhibit major speed degradation when you go past 16 MB
of main store.

The reason, simplified, is that the ISA bus has 24 address lines for doing
memory access, which means it can only directly address 16MB. After that,
when UNIX tries to do DMA, it must copy down or page memory chunks to a
space below 16 MB. This is very slow. Some MB manufactures have worked 
around this but for the most part, my experience has been that stock and 
standard MB's ( read; the ones that work right) will have this limitation.

Before ODT came out, we didn't see this often because > 16MB of memory
was the exception rather than the rule on x86 hardware. ODT's hunger
for main memory has pushed this ISA amonaly into many unsuspecting 
faces. 

Prove this by yanking the top 16MB out, and seeing if you still have
the problem. Don't let swapping (if any) fog your results.

Fix == EISA


-- 
David Van Allen - Lehigh Software Systems, Inc.
dave@kbvan.COM                   (215) 366-9130
73530,2463 CIS    ************   info@kbvan.COM
uunet!kbvan!dave                  Allentown, PA
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/-
       Remember when sex ->0 was safe...  
     and race cars o/--\o were dangerous?
From: lee@dlpco.dlpco.COM (Lee Penn )
Newsgroups: biz.sco.general
Subject: WANTED: Stories about SCSI Tape Backups und
Date: 3 Jan 93 15:06:56 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

>Earned a few bucks and am looking to get a SCSI tape for my
>SCO Xenix (2.3.2) system. I'm looking in the 250MEG range. 

>Anyone got any war stories??
>-- 
>Its most likely a     | E-MAIL: jp@michigan.com  CAT-TALK IS BACK as a FREE
>forgery, so save your | SYSTEM!! 313-882-2209 300-14400 V.32/V.32BIS/TurboPEP
>flames for someone    | Anon-UUCP: System: tygra, Login: nuucp, no pw
>who cares  :->        | Get file "/cat/pub/filelist" for a list of files.

We use and sell Sankyo.  We used to use Archive/Maynard drives 
and starting having problems getting the drives serviced.  Sankyo 
has been very reliable and service has not been an issue.

Regarding service however, we are finding a number of 3rd party 
service organizations who are in the business of refurbishing 
drives.

War stories:  Compaq WANGTEK SCSI drive which would not read SCO 
installation tapes.  Had major problems with this and no help 
from either Compaq or Wangtek.  Would not even admit the problem 
existed.

WANG DAT drive which caused system panics and data which could not 
be verified with CTAR's bit level verify.  At this point, we are 
avoiding DAT as a result of this experience.  I really think this 
is a DAT drive driver issue, but unless a device is supported 
really well in software, we tend to avoid it.

Tape backup is just too critical an issue for us to ignore.  ALL 
of the major disastors which we have been envolved with center 
around faulty tape drives which appeared to backup but could not 
restore, or errored out and the customer just did not do backups, 
etc.  We have a fortune 500 customer lose 8 years of customer 
data as a result of the staff not doing backups properly.

FYI:  QIC drives are expensive, but not as bad as DAT drives.

        Sankyo 150/250 drive            $750 retail

        Sankyo 350/525 drive            $972

        Sankyo 1 Gig                    $1,265

Media is another expense:

        3mdc6150                        $30 each
        
        3mdc6250                         41

        3mdc6350                         39

        3mdc6525                         45

        3mdc1gig                         50

We feel you need at least five cartridges, thus you can see that 
the cost of those is not insignificant.

Happy shopping.




================================================================================
Lee Penn,  DLP Technologies, Inc.                     Voice: 513 232-7791
SCO Advanced Product Center                           FAX: (513) 232-7801
7444 Jager Ct.
Cincinnati, OH  45230-4344                           email: lee@dlpco.COM
From: watson@carssdf.UUCP (- Self Empl. Sys.Integrator)
Newsgroups: biz.sco.general
Subject: Re: Trouble configuring UUCP on TCP/IP
Keywords: sco uucp tcp/ip
Date: 30 Dec 92 14:46:40 GMT
Reply-To: watson@carssdf.UUCP (John Watson -- Self Empl. Sys.Integrator)
Organization: John Watson (Self Employed System Integrator)

Re: your explanation of connection UUCP via TCP,

Why port 540?  Is this magic, or how do I figure out which port to use
on my machine?

John Watson       watson@carssdf.UUCP
Newsgroups: biz.sco.general
From: fred@genesis.demon.co.uk (Lawrence Kirby)