HDTenEightyP/NetNews huggingface dataset:
From: belal@sco.COM (Bela Lubkin)
Newsgroups: biz.sco.general
Subject: Re: Logitech C9 Serial Mouse at 9600 Baud
Date: 1 Jan 93 01:31:17 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

Kevin Smith wrote:

> It doesn't appear that the STTY and INIT strings are in any way
> configured into the kernel.  For a serial mouse, then, this must be
> handled by the event library calls (By the way, I seem to be missing
> my ev_open() man pages).  The sequence would be, I believe, to apply
> the STTY to the port then send the INIT string, after which,
> everything should be ready to go.

I've included ev_open(S) below (compressed, uuencoded -- it has
formatting which will not necessarily transport correctly over the
Internet).

It is ev_open() which sends the INIT string to the mouse port.  The
string itself is meaningful to the mouse, not the kernel.  The serial
mouse init strings in /usr/lib/event/devices all have the form "*nNx",
where "x" varies depending on the mouse mode to be used.  So presumably
either "n" or "N" is the baud rate specifier.  I'd say, experiment with
it.  With nothing using the serial mouse, do this:

  on multiscreen 1: sleep 10000 < /dev/tty1a    # keep the port open
  on multiscreen 2: hd /dev/tty1a               # log mouse output
  on multiscreen 3: stty 1200 < /dev/tty1a
  on multiscreen 3: echo "*nNU\c" > /dev/tty1a  # init to default mode
  <move mouse around, look at the hex output on screen 2, get an idea of
   what it's supposed to look like when it's working correctly>
  on multiscreen 3: stty 2400 < /dev/tty1a
  on multiscreen 3: echo "*nOU\c" > /dev/tty1a  # init 2400??
  <move mouse around: is it making sense on screen 2?>

I learned from the ev_open() source that the baud rate is set before the
init string is sent.  So I'm guessing that the mouse automatically
handles varying baud rates for the init string, which probably means the
first two characters are just to get it in sync.  So the third is
probably the baud rate, thus the guess of "*nOU" to initialize the same
mouse mode at 2400bps.

Anyone with tech docs for a Logitech serial mouse should be able to
answer this instantly...

>Bela<
From: paul@openage.com (Paul A. Fischer, Sr UNIX Sys Consultant)
Newsgroups: biz.sco.general
Subject: Re: Tape drive on floppy controller, no fun
Date: 29 Dec 92 14:08:29 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Precedence: bulk

>Yes, they can work successfully.  It does require a little bit of
>tinkering and making sure you have the JTAPE driver software from
>Colorado.

>However, One BIG NOTE of WARNING!!!

>For those uninformed, the Colorado 120mb is actually a 60mb unit uncompressed,
>and the Colorado 250mb is actually a 120mb uncompressed.  If you use tar
>you are limited to 60mb/120mb respectively.

>If you are like us, and use CTAR, the compression will recoup some of the
>area for you, depending on your file types.

You can also buy the colorado compression adapter, and use the jtape software 
one the command line.  The PROs:
        hardware compression
        lots of nifty options for logging and error reporting
        menu drived interface for normal users to restore from.

The CONs:
        Proprietary tape format
        can only transfer data to machine with same tape setup
        Slow
        Can't use compression with standard UNIX utilities (ie. there should
                be a compression device node available, but there is none!)
        tapes need formatting.

--------------------------------------------------------------------------------
Independent SCO support and service provider in the D.C. metro area.
Insert clever saying here...
Paul A. Fischer           | Open Age Inc.  | paul@openage.com
Sr. UNIX Sys. Consultant  | (301) 948-6422 | (301) 948-9644 Fax
From: lee@dlpco.dlpco.COM uunet!mlite!tom@uunet.UU.NET (Lee Penn )
Newsgroups: biz.sco.general
Subject: SCSI eiad selection error, Sankyo Tape driv
Date: 1 Jan 93 18:33:17 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'm getting an error message from my system which has be puzzled. 
It does not cause a problem, but we see the error every morning 
when we come in after a CTAR backup to my Sankyo 1 Gig tape 
drive.

NOTICE: eiad: Error (Selection Timeout) on SCSI adapter 0 (ha 0 
id 2 lun 0)

I get this error message 4 times during our nightly ctar backup.  
I think it comes actually from the verify step rather than the 
actual backup step.

If I try to run the verify from the csave menu, then I get the 
error message pops up after a while and ctar asks if I should do 
error recovery.  If I reply with a yes, then the verify continues 
onward.  During the nightly backup/verify, I am assuming that 
ctar simply retries automatically.

This is an irritating, but not disasterous problem and only 
occurs with the tape drive.  I suspect that backing off the 
blocking factor to 20 rather than 64 might help, but am not sure.

It looks like a kernal problem to me, but am not sure.

This is being forwarded to Microlite as well as SCO as a problem 
as I think it is a kernal driver issue.

================================================================================
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: Jean-Pierre Radley <jpr@jpradley.jpr.com>
Subject: Re: WANTED: Stories about SCSI Tape Backups
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Content-Type: text
Reply-To: jpr@jpr.com
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Mon, 4 Jan 1993 02:54:49 GMT
Content-Length: 597       
Precedence: bulk

Lee Penn writes:
> Media is another expense:
> 
>         3mdc6150                        $30 each
>         
>         3mdc6250                         41
> 
>         3mdc6350                         39
> 
>         3mdc6525                         45
> 
>         3mdc1gig                         50

I've had a Sankyo for a couple of years, and yes it's terrific.
But even when I first obtained it, 6525 cartridges never listed for more
than $39 in any mail-order catalog I ever saw. Somewhat less, usually.

-- 
Jean-Pierre Radley   Unix in NYC   jpr@jpr.com   jpradley!jpr   CIS: 72160.1341
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: Configuring an Adaptec 1542B ...
Date: 31 Dec 92 20:48:46 GMT
Organization: Izot's Swamp

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

> What prompted this was the recent performance discussion going on ...

   I should have mentioned this in the last post: changing the I/O bus speed 
can have an effect.  However, like setting the DMA rate on the 1542B, there is 
a point beyond which you will be plagued by data corruption.  My 386/40 will 
let me set my I/O bus as high as 20 MHz, but it is very obviously flakey when 
I do so.  At 13 1/3 MHz, it works fine.  At work I have some 386/33s tuned to 
operate their I/O bus at 16.5 MHz; the VGA cards (from ATI, Oak, and Trident), 
I/O cards (generic crud), and ethernet cards (Katron) work fine at that speed.

   You should back up first and test thoroughly before walking away from a 
system you've twiddled in this way.

  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_
Newsgroups: biz.sco.general
From: apl@world.std.com (Anthony P Lawrence)
Subject: time command
Organization: The World Public Access UNIX, Brookline, MA
X-Newsreader: Tin 1.1 PL3
Date: Thu, 31 Dec 1992 01:52:38 GMT

There has got to be a simple answer for this, but it's got me
stumped.

I'm sitting here playing with a 115K baud terminal. I wanted to
see how it compares to the system console, so I did 'time lr /etc'
on both the console and the terminal.

The console finishes first, as we would all expect.  But, 'time'
reports LESS real, user and system time for the command run on
the terminal.

The only rational explanation is that either the multiport card or the
terminal (or both) are doing a lot of buffering so that 'time' thinks
the command is complete when it actually isn't.  

Now: I had never thought about the effects of buffering on 'time'.  And
I can't honestly say that I've spent a lot of time thinking about it even
now.  But this simple example shows that 'time' measurements can be 
quite false... and makes me wonder about other 'time'd benchmarks...

		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: traub@rtf.bt.co.uk (Michael Traub)
Newsgroups: biz.sco.general
Subject: Re: time command
Date: 31 Dec 92 08:34:00 GMT
Organization: BT Customer Systems, Brighton, UK

In article <C03p7q.9v1@world.std.com> apl@world.std.com (Anthony P Lawrence) writes:
>The only rational explanation is that either the multiport card or the
>terminal (or both) are doing a lot of buffering so that 'time' thinks
>the command is complete when it actually isn't.  

We came across this problem with a driver we wrote. The solution was to
write a small program which outputs loads of text (the equivalent of
your "ls") *then* read the cursor position back from the terminal (assuming
your terminal has this feature). The elapsed time then reflected reality.


-- 
Michael Traub
BT Customer Systems, Brighton Systems Centre. traub@btcs.bt.co.uk
Newsgroups: biz.sco.general
From: fr@compu.com (Fred Rump from home)
Newsgroups: biz.sco.general
Subject: Re: Tape drive on floppy controller, no fun
Date: 25 Dec 92 22:32:57 GMT
Organization: CompuData Inc.

bill@Celestial.COM (Bill Campbell) writes:

>In <9212231532.aa13151@dlpco.dlpco.COM> lee@dlpco.dlpco.COM (Lee Penn ) writes:

>:DLP Votes DOWN THUMBS on Colorado J-Tape drives.  They should be
>:avoided at all costs.  We have several customers who have junked
>:these drives.  One just spent 2 solid weeks working with the

>This is the same experience we had when we last used CMS drives
>about 3 years ago.  We only have one client who's still using his
>and it's been replaced at least 4 times because of hardware
>failures (only the first time was free).

The problem always comes in when a customer uses his local DOS expert to 
configure and purchase the hardware for 'less'. It's oftem difficult to jump 
in and knock the competition but we state our case anyway and then let the 
custome stew after his choice is less money. They still blame us for not being 
forceful enough in making our point as they 'really' didn't understand what we 
were trying to say.

Too bad. If they want something that works they should listen to people who 
sell the stuff that works not the stuff that's simply cheap. In the end they 
ALWAYS pay more anyway.

Fred
-- 
W. Fred Rump 	office:	   fred@COMPU.COM     'mans feet have grown/so big 
26 Warren St.   home: fred@icdi10.compu.com  that he/forgets his littleness'
Beverly, NJ. 08010                          		Don Marquis 
609-386-6846    bang:uunet!cdin-1!icdi10!fr   
Newsgroups: biz.sco.general
From: sheldon@iastate.edu (Steve Sheldon)
Subject: Re: Performance issues revisited
Organization: Iowa State University, Ames IA
Date: Tue, 22 Dec 1992 15:41:36 GMT

In <1267@consult.UUCP> bob@consult.UUCP (Bob Willey CDP) writes:

>In article <92111533.3@dlpco.dlpco.COM> lee@dlpco.dlpco.COM (Lee Penn ) writes:
>>On another machine that I worked with, we found out that the hard
>>drive was the bottleneck.  I used the following command as a quick 
>>test to see about the bytes/second off the drive and found it very
>>very slow.
>>        time dd if=/dev/rhd0a of=/dev/null bs=2048 count=8192
>>This is a 16 meg copy to /dev/null.  On a lively machine, I expect
>>to see 1 Megabyte/second or better.  On my customer's machine, we
>>were getting around 200 K/sec.  Replaced the drive and he came back
>>up to speed.

>speed between the machine.  Running the above command on the new machine
>yielded some interesting results, but NOT the ones that we wanted.

>       OLD MACHINE                             NEW MACHINE
>386/33 w/8mb memory 64kcache           486/DX266 w/16mb memory 256k cache
>Ultrastor 12F ESDI controller          Adaptec 1542 SCSI controller
>Maxtor 338mb drive (~ 16ms)            HP 667 SCSI-2 drive (~13ms)
>CMS Enhancement 250mb tape             Archive ST-525 mb tape (SCSI)
>                       Results of above command:
>Real 25.3  user 0.3  sys 5.2           real 1:01.6  user 0.3  sys 3.6
>                 Tape backup results when using CTAR
>Typical:  2.3mb/min                    Typical:  5.8mb/min

>While the backup time is noticeable faster, the dd command for disk transfer
>appears noticeable SLOWER on the new machine???  Is there anything obvious

 Interesting results.

 I tried this command on one of our computers here,

 486DX/50 w/16 mb memory 256K cache
 Cheap Asian IDE interface(Goldstar I think?)
 Maxtor 340 Meg IDE drive

 Real 21.2  user 0.2  sys 5.3

 However, I decided on a much cheaper way to improve performance, especially
considering how poorly that Adaptec performed. :)
Instead I executed this command:

  time dd if=/dev/rhd0a of=/dev/null bs=131072 count=128

 Real 12.5  user 0.0  sys 0.7


 I'm curious if perhaps the configuration you have just doesn't like the
smaller block size.  I suppose it might be possible...



-- 
sheldon@iastate.edu                Steve Sheldon
Project Vincent                    ICSS Resource Unit
SCO ODT, Arc/Info, Atlas GIS       2142 Agronomy Hall
                                   Iowa State University
From: bruno@athena.mcrcim.mcgill.edu (Bruno Hall)
Subject: Re: Trouble with FLOW CONTROL and FAS and rzsz
Keywords: modem fas flow usr courier sco odt
Organization: McGill University Broom Closet
Distribution: usa
Date: Thu, 17 Dec 92 00:57:11 GMT

lucy@sandr.COM (Doug Lucy) writes:
>
>I'm trying to solve a hairy flow control problem on our Unix server.
>
>We've got SCO ODT 1.1 (Unix 3.2.2) with FAS 2.10 installed on the two
>standard (16550AFN-upgraded) COM ports with a US Robotics Courier
>V.32bis attached to COM2. The port is locked at 38,400, as is the
>uugetty and atdialer (SCO's High-speed modem SLS).

> [lots deleted -BH]

Just a guess, but have you got the minor number set right for the port
you're using?  It should be something like 81.

Bruno
-- 
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Bruno Hall  |  VE2HUM  |  bruno@mcrcim.mcgill.edu         
McGill Research Centre for Intelligent Machines - Controls Group
New systems generate new problems -- Join the Flat Earth Society.
Newsgroups: biz.sco.general,biz.sco.opendesktop,comp.unix.admin
From: sl@wimsey.bc.ca (Stuart Lynne)
Subject: Re: Busmouse not working on ODT 2.0
Organization: Wimsey Information Services
Date: Sun, 27 Dec 1992 21:25:06 GMT

In article <X1gewB3w165w@zswamp.UUCP> geoff@zswamp.UUCP (Geoffrey Welsh) writes:
>mknewman@blkbox (Marc Kraker Newman) writes:

>   WARNING: Some software *needs* the video card to use IRQ9.  I don't know 
>for sure, but ODT *might*.  Anyone know for sure?

I use IRQ9 (aka 2) for network cards under ODT. Works fine. Always has. (I.e.
it worked under Xenix and SCO UNIX as well.)

-- 
Stuart Lynne <sl@wimsey.com> ......................... UNIX Facsimile Software
Wimsey Information Technologies ................... moderator biz.sco.binaries
uucp login:nuucp passwd:nuucp .................... ftp.wimsey.com:~ftp/ls-lR.Z
PD Software for SCO UNIX .................... ftp.wimsey.com:~ftp/pub/wimseypd
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: Performance issues revisited
Date: 23 Dec 92 04:26:12 GMT
Organization: Izot's Swamp

sheldon@iastate.edu (Steve Sheldon) writes:

>   time dd if=/dev/rhd0a of=/dev/null bs=131072 count=128

   I know that the DMA controllers on PC-compatibles can't do a transfer of 
more than 64K in a go.  In theory, the Adaptec (models 154x, 164x, 174x) need 
not be limited by this, thanks to bus master DMA.  Does anyone know the size 
limit for a single DMA burst from these devices?

>  I'm curious if perhaps the configuration you have just doesn't like the
> smaller block size.  I suppose it might be possible...

   In my own experiments while constructing a count-oriented (for maximum 
performance) yet time-regulated disk benchmark, I found that throughput 
increases logarithmically with block size. (note: not exponentially; I mean 
approaching the maximum, with each increment in block size having less effect 
than the last.)  I ended up using 60K blocks, because they gave pretty much 
the same figures as 63K blocks.  Some systems gave very low figures when 64K 
block sizes are used, but others did not; I do not understand that 
observation. 

  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_
Newsgroups: biz.sco.general
From: news@choreo.ca (Choreo NetNews Administration Account(Ottawa))
Subject: Stan Barber's NNTP 1.5
X-Disclaimer:  This news article was written by an employee or customer of
               Choreo Systems Inc., and does not necessarily reflect the
               opinions or views of the Managament of Choreo Systems Inc.
Organization: Choreo Systems, Ottawa Canada
Date: Wed, 23 Dec 1992 22:00:31 GMT
Summary: inetd is having problems with starting nntp
Keywords: sco nntp inetd rn

I have Stan Barber's NNTP code compiled, amd and entry in inetd.conf.  However,
when I try to connect up to the server using telnet, syslog gets flooed with
messages like this

Dec  7 14:52:49 gateway nntpd[459]: host_access: getpeername: Socket is not connected
Dec  7 14:52:49 gateway nntpd[459]: unknown refused connection
Dec  7 14:52:49 gateway inetd[236]: /etc/nntpd: exit 0x1

What is wrong?  I've applied the SCO patches, but I don't have something right
somewhere.

Thanks

Chris
chare@choreo.ca
Xref: sparky biz.sco.general:4843 biz.sco.opendesktop:882 comp.unix.admin:6791
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general,biz.sco.opendesktop,comp.unix.admin
Subject: Re: Busmouse not working on ODT 2.0
Date: 26 Dec 92 17:27:44 GMT
Organization: Izot's Swamp

mknewman@blkbox (Marc Kraker Newman) writes:

> I attempted a upgrade to SCO ODT 2.0 from 1.1 today, and everything worked 
> fine except the mouse.  I tried an upgrade, a install leaving the other
> partitions in place and a full, wipe disk install, but I was unable to get
> my Logitech Mouseman Busmouse to work.  It is configured at interrupt 2,
> which I know is a bit flakey.  I checked SOS, and there was an article saying
> something about if the barrel on the mouse connector is a round one, it is a
> keyboard mouse.  Can anyone tell me if my Logitech Mouseman Busmouse is a
> Keyboard mouse and not a busmouse?

   NOTE: On an AT, interrupt 2 is not accessible from the I/O bus, as it 
connects to the cascading interrupt controller that provides interrupts 8 
through 15.  The I/O line associated with IRQ2 on an XT is connected to IRQ9 
on an AT; make sure that your driver knows this.

   Also, is you plan to use IRQ2/9 for anything other than video, you'll have 
to disable your video card's access to that line.  On a Trident card, that's a 
jumper; on other cards, I don't know...

   WARNING: Some software *needs* the video card to use IRQ9.  I don't know 
for sure, but ODT *might*.  Anyone know for sure?

  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: uhclem@nemesis.UUCP
Date: 22 Dec 92 20:55 CST
Newsgroups: biz.sco.general
Subject: NCSA Telnet connect vs SCO: Fix
Message-ID: <-12366655@nemesis>
From: kevin@shady.UUCP (Kevin Smith)
Newsgroups: biz.sco.general
Subject: Re: disassociating from a terminal
Date: 21 Dec 92 07:47:55 GMT
Organization: /usr/local/lib/news/organization

In article <m0n1POK-000Fk3C@ilinx.wimsey.bc.ca> brian@ilinx.wimsey.bc.ca (Brian J. Murrell) writes:
:>Hey there,
:>
:>	On a 3.2.4 (I'm pretty sure the level of OS is not the issure here) I have
:>a daemon which I wrote.  The problem is that it's not disassociating from the 
:>controlling terminal properly.  I did everything I thought I should, but 
:>probally missed something.  I wrote and example below.  All it does is run
:>a command via system(), the command is a shell script which just exits non-zero.
:>The program then prints the exit from system() into a log file.  If I start
:>this program from a terminal and watch test.out, it prints the non-zero return
:>code from the shell script.  As soon as I log the screen which started the 
:>program out, it starts printing a return code of 0, and I can guarantee you the
:>shell script is not even being run.
:>
:>Why??
:>
:>brian
:>

... program listings deleted ...

You may need to close all stdin, stdout, and stderr.  What is die() doing?
You should probably ignore SIGINT and SIGHUP.
-- 
	    | Email - !shady!kevin uunet!shady!kevin kevin%shady@uunet.uu.net
Kevin Smith | Voice - (908) 874-7980
	    | Mail  - ShadeTree Software, Inc., 192 Capricorn Dr. #10,
	    |         Somerville, NJ  08876