HDTenEightyP/NetNews huggingface dataset:
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: Configuring an Adaptec 1542B ...
Date: 31 Dec 92 20:45:10 GMT
Organization: Izot's Swamp

Tim Northrup <jrsalb1!tgn@brspyr1.brs.com> writes:

> Currently, the 1542b is configured for the default of 5 mb/s transfer speed.
> Has anyone had any problems using the higher settings?

   Yes!  I've used the 1542A on various systems and found that data is 
corrupted when the card's DMA is pushed past the motherboard's tolerance.  A 
friend with a 1542B reports the same experience with the 1542B (the limit on 
his 486/33 is 5.7 MB/s, I belive... is that one of the options? <grin>)

> I got zilch for documentation on the 1542b with the system; the document
> 154XB_IG.DOC from the Adaptec BBS is a little helpful; but I'm looking for
> a little better direction.

   You should be able to download the entire 1542B technical manual from the 
Adaptec BBS (that's where I got my 1522 manual); it is long and it may take a 
moment to find what you're looking for, but the info should all be there.

  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: Re: ev_open.S.Z.uu, again
Date: 3 Jan 93 08:02:47 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

I wrote:

> My previous attempt to send ev_open(S) got damaged somehow.  I checked
> the message in my outgoing mail log and it was OK; but when it
> returned to me through the scogen mailing list gateway, one line of
> the uuencoded data was missing.  So I'm including it again (the whole
> thing, under the theories that A) trying to explain where to put the
> missing line should go is too messy; and B) that most of the cost of a
> message is in sending it, not in its bulk).

WELL.  The new copy came back from xenitec with the same line missing!
That is particularly odd since the prefatory material in front of the
new copy was a lot longer, changing that line's position in the message;
and since I changed the uuencode format to use "`" rather than " ", and
the missing line did have a space on it.  SO.  I will resend just the
last portion of the file; you substitute it into what I just sent:


M96-UR.FT&*BJ`_J1826&F,3.".-!;I@&-0XDCG5,+;:FQ)M&R:-NS8B5.I4'
M!:&S1H`JYSSWBR!];C`=UYR"-I,*#H$.YITA<I+$J5!4@789Y<@5:5&FA`P2
"#@BS
`
end


The above segment should contain 3 full-length uuencode lines
respectively ending with ".I4'", "A7E_", and "A`P2"; 2 short ones; and
one "end".  I will now repeat the missing line, by itself, 3 times.  I
want to see if the gateway is somehow allergic to the contents of that
particular line:




and now one bonus time, with some quotes and stuff around it, and with
all uppercase letters converted to lowercase, to try to throw off the
line eater:


>> "  m+'6igwt*=9)iz6x-$fyb0;s%k3`7y0ngs7%h&2+f+yc!,;<t\tdd1(=;a7e_  " <<


There!  >Bela<
Newsgroups: biz.sco.general
From: art@chaos.cs.umn.edu ()
Subject: Beta site for (virtual/mirrored disk)
Summary: Need Beta Site for (Virtual/Mirrored disk)
Keywords: Mirrored Virtual
Organization: University of Minnesota
Date: Wed, 23 Dec 1992 17:45:04 GMT


I have posted some recent articles regarding a virtual disk and
am happy to announce that a primitive version is ready for beta testing
and I am looking for a site that would be willing try this thing out.

The first version is not really a virtual disk but rather a mirrored
disk using two nodes. The size is configurable and the mirroring is all
done in software assumming the following tools are available.


The reason I need a beta site other than my own is that we are technology
company and do not have an on-line type UNIX system with any significant
demand. 



 SCO unix 3.2 (development system would be useful)
 TCP/IP
 NFS would be nice but could make do with TCP/IP
 (I would be willing to port the technology to other platforms on
  a custom bassis)


For More Info Please mail me at
art@chaos.cs.umn.edu
or call
612-375-1066
Fax 612-375-0131
Polaic Research

Terms are negotiable (is that speled OK?)
From: mhl@genco.bungi.com (Mark Levy)
Newsgroups: biz.sco.general
Subject: Re: NE2000 driver
Date: 29 Dec 92 22:29:36 GMT
Reply-To: mhl@genco.bungi.com (Mark Levy)
Organization: Gentry & Assoc. Excelsior Springs, MO

RE: NE2000 problems.

   What sort of problems are you having wiht getting the card to run?
Something that tends to bite people is that the NE2000 uses 20 (Hex)
I/O ports, and can cause problems.  If you have the I/O ports set to 
0x360, it will stomp all over a printer port set at 0x378, since the 
NE2000 takes up the I/O ports from 0x360-0x37F.  I haven't had a chance
to try the NE2000 on a *IX system yet.  Good luck
Mark Levy - Micrologic/ValCom

Newsgroups: biz.sco.general
From: md@sco.COM (Michael Davidson)
Subject: Re: Performace degradation under SCO
Organization: The Santa Cruz Operation, Inc.
Date: Tue, 22 Dec 1992 19:07:52 GMT


kbvan!dave@uunet.UU.NET (Dave Van Allen) writes:


>> 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.

There is another factor that may be contributing to this problem.
Depending on the architecture and size of the secondary cache it
may or may not be caching memory accesses above 16 Meg. There are
a lot of motherboards that are sold with cache configurations that
will not cache above 16 Meg - this will have a very serious affect
on performance.
Newsgroups: biz.sco.general
From: /dev/null <alexl@alvarez.COM>
Subject: Capturing data from a RS232 Port
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Cc: sfrazier@eng.norstan.com
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Thu, 31 Dec 1992 04:47:50 GMT
Precedence: bulk

.>   From: Steven E Frazier <eng.norstan.com!sfrazier@uunet.UU.NET>
.>   Subject: Capturing data from a RS232 Port
.>   Organization: Norstan Communications - Columbus, Ohio
.>   Date: Wed, 30 Dec 1992 21:04:44 GMT
.>   Message-Id: <C03Bvy.3JB@norstan.com>


.>   Is there a way to use an existing program on SCO to open a file and capture
.>   data coming from say a RS232 port /dev/ttyak and then use cron to drop 
.>   DTR @ say 0200 then open the port back up?  I am thinking cu could do
.>   that but can than be run in the background?

.>   The purpose is to capture CDR (Call Detail Records) from a PBX, at 0200
.>   close the port copy them to another file and then reopen the port again
.>   for data capture.  

.>   Thanks in advance.

.>   Steve

.>   -- 
.>   Norstan Communications, Inc.        | Steven E. Frazier
.>   8101 N. High Street Suite 100       |---------------------------------------
.>   Columbus, OH   43235                | Local : sfrazier
.>   Voice 614-785-7335 Fax 614-785-7337 | Remote: sfrazier@norstan.com




It is crude but it should work.

# Initialize port and maintain settings (hold-open)
#
(stty 9600 ixon ixoff -ixany; while: ;do sleep 3600; 
done)</dev/ttyak  
#
# Create unique name for log file.
#
$FILE=`date +%h.$d.%y.%T`
#
# go to log directory.
#
cd /u/logs/phone
# capture information and put in file
#
cat < /dev/ttyak > ./$FILE
#
#let run so an hour
#
sleep 3600
#
#kill shell and close all files
#
kill $$
#




        This should work although it could probably be done 
cleaner with C, I was bored and decided to do it in shell.  

Have fun hope it works.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /  ) //            _//                   Alexander Lopez
 /--/ // _  _.,      /    _____   _  __.   Alex Alvarez and Associates
/  (_</_</_/ /\_    /___ (_) /_)_</_/  |_  alexl@alvarez.COM
                            /         (|   305-649-8900

Newsgroups: biz.sco.general
From: larryp@sco.COM (Larry Philps)
Subject: Re: sigaction() and rescheduling interrupted system calls
Organization: SCO Canada, Inc.
Date: Thu, 24 Dec 1992 13:08:02 GMT

In <GEORGN.92Dec23022328@idcrisis.noweh.com> georgn@noweh.com (Georg S. Nikodym) writes:

> In article <64@shady.UUCP> kevin@shady.UUCP (Kevin Smith) writes:
> 
>    In article <1992Dec16.100827.10097@dd.dk> wes@dd.dk (Mads Westermann) writes:
>    :>I'm running SCO ODT 2.0 (SCO Unix 3.2.4) and have run into the problem
>    :>of rescheduling an interrupted system call after a signal has occured.
>    :>
>    :>In my AT&T Sys V.4 manual there's reference to a SA_RESTART flag on
>    :>the sigaction() function that causes interrupted system calls to be
>    :>transparently restarted.
>    :>
>    :>In my Ultrix 4.2 manual there's reference to a SV_INTERRUPT flag that
>    :>does the same.
>    :>
>    :>My SCO manual doesn't know of any such thing - It seems like the only
>    :>possibility is to manually check the return code and the errno from the
>    :>system call and manually restart the system-call if errno equals EINTR.
>    :>
>    :>Has anybody solved the problem ? Is there a way to solve it ?
>    :>
>    :>Any input on this subject would be greatly appreciated.
>    :>
> 
>    Since most system calls are not interruptable the problem is not as big as
>    it might seem.  Terminal and printer I/O, pause(), wait(), messages and
>    semiphores are about it (and probably any network/socket read and writes)
>    Ok so there are a few.  Your basic disk and tape IO are, however, not
>    interruptable so the interrupt actually occurs immediatly after the system
>    call.
> 
> Interrupted system calls are a reality and should be dismissed out of
> hand.  One of the more annoying signals that usually needs special
> treatment for this is SIGWINCH (I'm not sure that it exists in SCO,
> but certainly does in the BSD and SVR4 worlds).  But this is secondary
> really since SCO UNIX claims to be POSIX.1 conformant.  Must it not,
> therefore, have a sigaction() call with all the trappings?

This has been mentioned in this thread before, but at the risk of being
pedantic, I'll say it again.

I have a copy of the POSIX 1003.1-1988 standard open right now to the
page on sigaction, and the _only_ flag it mentions is SA_NOCLDSTOP.
SCO Unix does indeed define and implement that flag.

The SV_INTERRUPT flag is part of the BSD sigvec(2) implementation, not
part of POSIX 1003.1.

---
#include <std/disclaimer>

Larry Philps,	 SCO Canada, Inc.
Postman:  130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
InterNet: larryp@sco.COM
UUCP:	  uunet!sco!larryp
Phone:	  (416) 922-1937
Newsgroups: biz.sco.general
From: bob@consult.UUCP (Bob Willey)
Newsgroups: biz.sco.general,comp.unix.xenix.sco
Subject: Re: SCO Xenix 386 2.3.4 Adaptec w/Archive ST 525mb Tape Unit
Keywords: Tape problems
Date: 28 Dec 92 13:32:33 GMT
Reply-To: bob@consult.UUCP (Bob Willey)
Organization: CCS Enterprises, Inc.

In article <75@consult.UUCP> bob@consult.UUCP (Bob Willey) writes:
>We have been having problems with a new tape drive installed on our
>We are able to read and write 150mb & 250mb  (DC6150 & DC6250) tapes
>without any problems.  However, when we go and try to write to a
>525mb tape (DC6525) (and using several different tapes) we get:
>%tape    type=scsi  unit=2:0
>SCSI: ERROR: on tape ha=0 id=2 lun=0
>SCSI: WARNING: Host Adapter Detected Error
>      SCSI Bus Data Over/Under Run
>tar: tape write error

This problem was documented in one of the SCO IT scripts on sosco.
It appears that the Archive units are shipped using 24k buffer (not 
documented anywhere).  You have to change CF0 CF1 jumpers  to:
CF0 CF2 and then all appears to work fine.
Did a backup last night and got about 8.5mb/minute, so it must
be working ok now.

Thanks for all those that e-mailed or posted information.
Another one bites the dust.

-- 
>.. 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 ...........<
Newsgroups: biz.sco.general
From: lee@dlpco.dlpco.COM (Lee Penn )
Subject: Re: CD's and SCO NFS
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Sun, 20 Dec 1992 15:33:55 GMT
Precedence: bulk

Be warned.  Everex just announced that they are lossing money like
crazy.  I cannot believe that ESIX will be on their list of things
to keep as I doubt that it can be profitable for them given their
current problems.

Their stock has dropped from about $1.50/share to less than $0.50
per share in the last week.

Before you consider ESIX, be really careful.

>donl@worldbridge.com writes:
>> We use ODT 2.0 and got an upgrade SLS from SCO for the CD-ROM drive.  As I
>> remember, it was still beta code.  It should be well into production and
>> available now.  I'm unsure as to the NON-ODT versions of TCP/IP and NFS.
>> It runs just fine here.  We mount the CD to several machines.

>Yes, it apparently can be done.  However, our system is just over a year
>old, and I'll have to upgrade everything in order to run NFS 1.2.  To
>upgrade the OS, DS, TCP/IP and NFS will cost us almost $1100 from SCO.
>It'd be cheaper for me to buy a CD-ROM drive for every PC!

>On the other hand, ESIX has a competitive upgrade available for $508, and
>complete BSD/386 costs under $1000 -- including X and source.

>I'm happy with SCO's tech support, hardware compatability and performance,
>but their upgrade pricing sucks rocks.  Right now I'm sufficiently pissed
>off that I'm seriously considering switching.

>[ \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 ]
================================================================================
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

Newsgroups: biz.sco.general
From: apl@world.std.com (Anthony P Lawrence)
Subject: Re: Capturing data from a RS232 Port
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: Tin 1.1 PL3
Date: Thu, 31 Dec 1992 21:30:36 GMT

kevin@shady.UUCP (Kevin Smith) writes:
: 	while :
: 	do
: 	    read line
: 	    echo "$line" >>$LOGFILE
: 	done
: 
: 	# Note: If the input data is non-ascii but fixed length you
: 	# could use dd instead of the read/echo combo.  Remember to
: 	# set -icanon on the port.
: 	#   while :
: 	#   do
: 	#       dd bs=?? count=1 >>$LOGFILE
: 	#   done
:     ) <$TTY
: 

I think you've covered most of the problems he could run into here,
except that of validating the data, and the possibility of variant
record lengths (assuming non-line oriented data).

If this is more than a casual grabbing (it sounds like it is), I
would think he'd want to validate "on the fly" rather than later.
I guess this could be done with shell tools (probably some perl
hacker would just love to do it!), but I think I'd get pretty
frustrated trying it!

Varying record lengths present another problem easily handled in
C (or whatever) but a little tougher in the shell.  Well, maybe
not tougher, but certainly messier.

Other advantages would be that a C program could eliminate the
need for cron, or could dump it's log on receipt of a signal (yeah,
I know: you can do that in the shell, too), etc.

I'm a fan of doing things with shell tools whenever possible, but
this is a case where I would go with C.


		Tony   apl@world.std.com

Lawrence & Clark, Inc		(617) 762-0707	(206) 323-2864
Xenix/Unix support,etc 	 	 Boston		 Seattle
       Kevin Clark is embarrassed by most of what I say.
From: watson@carssdf.UUCP (- Self Empl. Sys.Integrator)
Newsgroups: biz.sco.general
Subject: SCO UNIX 3.2.4 on Notebook
Keywords: TI 4000 ALR Ranger
Date: 24 Dec 92 17:48:57 GMT
Organization: John Watson (Self Employed System Integrator)


Does anyone know any reason why UNIX 3.2.4 would not run on either a
TI 4000 WINSX (Bios optimized for Windows) or an ALR ranger 486SX-25
mono display.

John Watson
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: Performance issues revisited
Date: 23 Dec 92 04:37:45 GMT
Organization: Izot's Swamp

sl@wimsey.bc.ca (Stuart Lynne) writes:

> The only time I've seen this problem it was due to the machines have a 
> configuration point in the low level BIOS setup that set the amount of memory
> to cache. The machine in question was field upgraded from 16MB to 32MB and
> the user didn't realize he had to change the BIOS CMOS setup.
> 
> So be sure to check that your machine has cache enables for all the memory
> you have installed.

   I've seen machines which exhibited the same problem *with* the BIOS 
configured to cache all 32 MB of RAM.  Upgrading the cache solved the problem.

   After reading through a dozen motherboard manuals, I finally found one that 
stated that 64K of cache covered only the first 16 MB.  This ratio seems to 
hold true for every system I've been able to check.  It's also worth noting 
that attempts to quantify the advantages of larger cache one machines with 
relatively little RAM (i.e. 8 MB or less) have indicated that there is little 
or no performance advantage to stuffing more static RAM in your cache if you 
don't have the megabytes of dynamic RAM that require it. 

   This indicates that a motherboard that can hold 64 MB of RAM had better 
have 256K of cache; on the other hand, anything more than 32K of cache on a 
board that can only hold 8 MB of RAM is overkill.

   I hope that there are designs which do not conform to this pattern (64K 
cache for 16 MB => 4K cache per megabyte of RAM, or 1K per 256K, etc.), but I 
have not yet found one.  Then again, I've only been testing commodity boards; 
perhaps some fancy design from IBM, NCR, Compaq, ALR, Everex, or some such 
innovator might have a completely different set of rules.

  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: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: BIOS shadowing, Re: Performance degradation under SCO UNIX
Date: 2 Jan 93 02:44:33 GMT
Organization: Izot's Swamp

dave@das13.snide.com (Dave Snyder) writes:

>     Video   ROM Shadow    C000,32k    Enabled
>     System  ROM Shadow    F000,64k    Enabled
> [all others disabled]

   Looks right to me but, as Bela pointed out, it doesn't affect performance 
past boot time.

> 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.

   I wouldn't think so; it sounds more like an interrupt or DMA conflict.

  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: blznrzn!jack@uunet.UU.NET (the developer)
Newsgroups: biz.sco.general
Subject: data xfer speed w/1542b
Date: 3 Jan 93 17:16:51 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

hi net,

this post is in response to kevin smiths recent query on data transfer
rates on the 1542b. i'm not sure how clear this will be, but if it helps...

the controller shuttles data between the host and its scsi targets
using dma speed(using bus master). the card offers rates between 
5 - 8mb/s depending on how fast your motherboard can go. 

adaptec provides a card-based utility to test this ability(dos debug, g=dc00:9).

the best case here then is the fastest dma possible for your box.
use the dma test to move the card jumpers as high as possible without
errors. in a test at work, on a 486, 25mhz, isa box using a dat drive
i went from 60kb/s to 80 kb/s shifting from 5 - 8 mb/s. 

your results may vary! ;)

so kevin, does that help? sco, have i misstated the case?

keep those bytes flying, jack...
=============================================================================
 Jack Craig  Microport         SVR4 408-438-UNIX   uunet!mport.com!jack
             Software Horizons SVR3 408-684-1375   uunet!sco.com!blznrzn!jack
=============================================================================