HDTenEightyP/NetNews huggingface dataset:
From: clarinews@clarinet.com (UPI)
Newsgroups: biz.clarinet.sample,clari.biz.products,clari.local.michigan,clari.news.disaster
Subject: Brewery to send fresh water to hurricane victims
Keywords: food & beverage, manufacturing, severe weather, trouble
Date: 25 Aug 92 20:32:48 GMT
Followup-To: biz.clarinet.sample
Location: michigan
ACategory: national
Slugword: andrew-strohs
Priority: regular
Format: daily, regular
ANPA: Wc: 245; Id: z5381; Sel: mibfe; Adate: 8-25-430ped
Codes: &bfedmi., &nbwrmi.


	DETROIT (UPI) -- The Stroh Brewery Co. Tuesday said it will join the
national relief effort to support victims of Hurricane Andrew by
shipping more than 7,000 cases of fresh drinking water from its Tampa,
Fla., and Longview, Texas, breweries to hard-hit cities in Florida and
other affected areas.
	The water is currently being bottled at both facilities. Stroh will
ship 32-ounce bottles from Tampa to Miami on Wednesday. An additional
shipment of 40-ounce bottles will be standing ready in Longview
Wednesday to accommodate other Gulf cities that are impacted. In total,
nearly 50,000 bottles of water will be distributed free of charge to
local residents through American Red Cross disaster relief teams.
	``When disasters of such a magnitude strike, the innocent people who
are left to pick up the pieces need all the support they can get,'' said
William Henry, president and chief operating officer of Stroh.
	When news of the impact of Hurricane Andrew reached Stroh, the
Longview and Tampa breweries mobilized quickly, converting their filling
lines from beer to fresh drinking water within a few hours. The bottles
are being packaged in cases and will be transported on two semi-trucks
from Tampa to Miami; another five semi-trucks will be loaded to
transport water from the Longview facility to Gulf Coast cities as
needed.
	Stroh is the nation's fourth-largest brewer.
Xref: sparky biz.clarinet.sample:2222 clari.news.weather:75 clari.news.disaster:77 clari.news.urgent:116
From: eastick@ramsey.cs.laurentian.ca (Doug Eastick)
Subject: Re: Bike stolen, reward offered
Organization: Dept. of Computer Science, Laurentian University, Sudbury, ON
Distribution: usa
Date: Fri, 4 Sep 1992 16:40:35 GMT

vandevek@cse.unl.edu (James Vandevegt) writes:
>The location was the bike racks east of Ferguson Hall on the UNL City 
>Campus.

>The bike is a Black Trek 820 mountain bike.  It had black fenders
>and a "Rock Ring" crank guard.  [...]

I think I saw someone riding it in Little Current (on the north
shore of Manitoulin Island) down near the government dock.  I didn't get 
the serial number, but I know it was black. :-)

Sorry to hear about it.
-- 
Doug Eastick -- Sudbury, Ontario
Newsgroups: biz.stolen
From: vandevek@cse.unl.edu (James Vandevegt)
Subject: Bike stolen, reward offered
Organization: University of Nebraska - Lincoln
Distribution: usa
Date: Fri, 4 Sep 1992 14:21:31 GMT


My bike was lifted sometime between 6:00p Thursday, September 3
and 1:30a Friday, September 4.  I doubt it was done in the daylight
but I could be wrong.  The location was the bike racks east of
Ferguson Hall on the UNL City Campus.

The bike is a Black Trek 820 mountain bike.  It had black fenders
and a "Rock Ring" crank guard.  There is a distinguishing oval shaped
spot on the right front of the seat where the fabric is worn away and
the underlying foam discolored.  It is a 21-speed bike with underbar
shifters.  1991 model year.  22in frame.  It has a black seat cable.
It was locked up with a self-coiling three loop cable and 4-digit
padlock.  It has 26"x1.9" tires.  It has center-pull brakes.

Lincoln Police license number 86165
Bike serial number TOF46076

$25 reward paid to anyone with information leading
to the recovery of the bike and/or conviction of the thief.

$50 paid to the person presenting the thief's dead carcass
at my feet.
--
| James M. VandeVegt             |  University of Nebraska           |
| vandevek@cse.unl.edu           |  Computer Science and Engineering |
----------------------------------------------------------------------
|                  Insert standard disclaimer here.                  |
From: brian@ilinx.wimsey.bc.ca
Newsgroups: sanet.list.sco,biz.sco.general
Subject: Re: Booting and Keyboard Input
Date: 25 Aug 92 17:33:57 GMT
Distribution: sanet
Organization: [resent by] The SCOGEN gateway and Propagation Society
X-Conv: Automatic mail-->news conversion at olsa99


As enscripted by Taso Hatzi:
>
>
> At some point in time after a kernel reconfiguration, the following problem
> appeared:
>
> The kernel boots until it gets to the 'Type Control-d to etc.'
> stage. At that point, what I type at the console keyboard doesn't
> get through to the program which did the prompting. It seems that
> the input is in some sort of raw mode. If I let the system time
> out and boot itself in multi-user mode the console works as expected.
> Can anyone shed some light on the subject?
>
This sure sounds like it should be a FAQ if not already.

Anyway, a file in /etc called ioctl.syscon is not correct.  Remove the file,
then reboot the system and be sure to let it autoboot.  It will be recreated.

I have never had any luck with removing the file and answering all the boot
up prompts.

brian

--
Brian J. Murrell                                        brian@ilinx.wimsey.bc.ca
InterLinx Support Services, Inc.                        uunet!van-bc!ilinx!brian
North Vancouver, B.C.
        Platform and Brand Independent UNIX Support - R3.2 - R4 - BSD
Newsgroups: biz.sco.general
From: Thilo Koenig <thilo@bazooka.amb.org>
Subject: UUCP and window size
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Fri, 28 Aug 1992 16:21:41 GMT
Precedence: bulk

Hi netters,

I hope this topic has not been beaten to death, but I missed any discussions
on this topic, if any...

I am trying to improve the UUCP throughput on my system, so I tried playing
with the packet window size by patching the uucico binary (I believe it
was mentioned on this list).  The original window size is 3 and I patched
it to 7.  I am no guru to the UUCP protocols so I don't really know what
this does.  I observed a nice ~20% improvement in transfer throughput
when communicating with one of my UUCP neighors with the increased window
size, but now only incoming files are transferred.  Outgoing files are
ignored as if they are not there (although they are in fact in the spool
directory and "uustat -a" shows them to be spooled correctly).  I am the
one that always initiate the calls in this case but it doesn't seem to
matter, because the same problem occurs with another site that dials in.
Switching the window size back down to 3 solves the problem, but makes
things slow...

Can someone explain the phenonmenon I have observed?  My modem is a
Hayes V-series Ultra 9600 and the UUCP neighbors have Worldblazers,
Hayes, and U.S. Robotics Courier modems; if that matters.

Thanks in advance...

Thilo.
--
Thilo Koenig                         #include <std/disclaimer> ____
thilo%bazooka@sgiblab.sgi.com                                  \  /
...!{decwrl,synopsys,tandem,tsoft,ultra}!sgiblab!bazooka!thilo  \/
From: aaron@creat.com
Newsgroups: sanet.list.sco,biz.sco.general
Subject: A request for HP-UX datio(1) to run on SCO Unix 3.2 scogen@xenitec.on.ca
Date: 25 Aug 92 19:27:43 GMT
Distribution: sanet
Organization: [resent by] The SCOGEN gateway and Propagation Society
X-Conv: Automatic mail-->news conversion at olsa99



Hello,

 I have a request so I'll ask everyone and see what happens.  First
some background for those who don't know the best way to backup a Unix
computer:

datio(1) is a Hewlett Packard value add backup/restore utility found in
HP-UX 8.07.  It is similiar to cpio with extensions to utilize the fast file
search capability of DDS (Digital Data Storage) format.  DDS is the storage
format for DAT drives.



>From SCO EFS110 (Enhanced Feature Supplement):

  The DDS format encodes special data separator marks (setmarks) on
         the tape in such a way that they can be located more quickly than
         by reading the data sequentially (as most tape devices are
         required to do).  The HP DAT device can position a tape to a set-
         mark up to 200 times faster than by sequential data access
         methods.

A search for a setmark on a 1300 megabyte tape typically takes only 22.5
seconds.

>From HP-UX datio manual page:

 NAME
      datio - backup to and restore files from DAT tape devices

 SYNOPSIS
      datio -o [aAxvh] DATdev [DATdev [DATdev [DATdev]]]

      datio -i [tuxvmU] [pattern] DATdev

 DESCRIPTION
      datio is designed to both simplify and optimize routine file backup
      and recovery to a Digital Audio Tape (DAT) device.  It combines the
      standard format of the cpio utility, with a simple to use, extremely
      fast recovery strategy.  datio provides significant enhancements to
      file restore in addition to an interactive front-end for simplified
      file recovery.



Now since datio(1) is only found in HP-UX, I ask this:

To whom it may concern at HP and SCO:

  I would like to request that the backup/restore utility datio(1) be
ported/compiled for SCO Unix 3.2.4 (and 3.2.2 with the HP DAT EFS).  This
program would be a natural extension to the existing DDS support for HP DAT
drives already included in current SCO Unix and Open Desktop.

  The DAT products from Hewlett Packard stand well above the rest for
archiving valuable data.  The Santa Cruz Operation has done an excellent job
supporting state of art hardware.  The power and speed of HP-UX datio(1)
has utility in the SCO world as well.


Aside:  HP's onboard compression DAT drive (HP35480A) is now a good match
with SCO Unix, as end of tape is now handled correctly.  Previous versions
of SCO Unix required backup programs to state a volume size, impossible with
onboard compression.

Thank You,
Aaron Brown.

aaron@creat.com    -    Unix systems engineer   -   aaron%creat.com@uu.psi.com
Creative Machinery-70 S.Lively, Elk Grove Village,IL 60007 USA +1 708.439.0055

    "Saw a sign on a restaurant that said `Breakfast, Any Time'.
        So I ordered french toast in the Renaissance." - Steven Wright

Xref: sparky biz.sco.general:3100 comp.unix.questions:10553
From: rot@multisys.com (Republic of Taiwan)
Newsgroups: biz.sco.general,comp.unix.questions
Subject: Re: FaxBack that is Unix Based.
Date: 29 Aug 92 18:23:03 GMT
Organization: Multimedia Information Systems Corporation, San Jose, CA                        TEL: (408) 437-3031            E-mail: info@multisys.com

In article <1992Aug28.020317.16945@zeos.com> kgermann@zeos.com (Ken Germann) writes:
=
=	Are there any Unix based Fax Back vendors? I would be interested
=in any information about Fax Back systems that run under SCO Unix 3.2.4.
=I have information on Faximum Plus. I am impressed with the functionality
=of the software. However, a Fax Back capabilities under Unix would be
=an exceptional addition to the Faximum Plus software. E-mail or post 
=any information that anyone might have on this.
=-- 
=       	     
=Ken Germann		ZEOS International, Ltd.  
=Technical Support				support@zeos.com.
=Operating Systems Group.			os@zeos.com	


Our MultiFax server has FaxBack capability.
For more info please contact kemnitz@multisys.com or
info@multisys.com.
Newsgroups: biz.sco.general
From: steveh@zentronics.ca (Steve Haller)
Subject: Re: upgraded from ODT 1.1 to SCO 3.2.4 causing panics!!
Organization: Zentronics Head Office, Mississauga, Ontario, CANADA
Date: Tue, 01 Sep 1992 00:20:56 GMT

In article <m0mO7pL-000FjvC@ilinx.wimsey.bc.ca> "Brian J. Murrell" <brian@ilinx.wimsey.bc.ca> writes:

>I just upgraded to SCO 3.2.4, in a box which has run ODT 1.1 (SCO 3.2.2)
>for months now without a burp.  Now I am continually getting panic type 0xE.
>
>One thing I noticed different is that the hardware config on bootup reports
>the FPU on int 13 and the SCSI card at int 11 whereas the ODT reported int 15
>and int 13 respectively.  

That's because 3.2.2 hwconfig reports interrupts in octal and 3.2.4 hwconfig
reports interrupts in decimal.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Haller           steveh@zentronics.ca / uunet.ca!zentron!steveh
Systems Engineer,      Zentronics Toronto,  "Authorized SCO APC"
Tel: (416) 507-2600
Newsgroups: biz.sco.general
From: news@xenitec.on.ca (xenitec.on.ca News Administrator)
Subject: ODT Dos Merge
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Sun, 30 Aug 1992 10:43:01 GMT
Precedence: bulk

I just started to use Merger under ODT 2.0.  I would like COM2 to appear
as /dev/ttyac.

I looked it up in the manual.  I disabled the /dev/ttyac, I changed the
chmod to 666, and then I did


Script started on Sat Aug 29 11:56:19 1992
# dos +acom2[=/dev/ttyac]
TOKEN_NF: dos: ERROR: Could not find token 'com2[' of the needed type.
# 
script done on Sat Aug 29 11:56:44 1992


I am trying to assign COM 2 to /dev/ttyac, could someone tell me what I am
doing wrong?

I want to use PCPlus and I need to use com2, the mouse is on com1 and the
mouse is working under merge.


I am doing this from the root prompt as well.

thanks.

steve




-- 
Vlink 		                   | Steven E. Frazier
                                   |---------------------------------------
                                   | Local : sfrazier
(614) 785-7335                     | Remote: sfrazier@eng.norstan.com
Newsgroups: biz.sco.general
From: Jim Miller <jmiller@cis.ohio-state.edu>
Subject: Colorado QIC40 / SLS available?
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Tue, 25 Aug 1992 18:26:21 GMT
Precedence: bulk

Hi,
   I just bought a Colorado Jumbo 120 tape drive, which is a QIC 40 unit. I
was under the impression that this drive would work with SCO 3.2.2, since
3.2.2 supports QIC 40 and QIC 80 drives. Not so. I just spoke with
Colorado's tech support, and the fellow told me that no, SCO UNIX does
not support this drive, but SCO is working on the problem and an update will be
released in the form of an SLS.  He also said that the SLS is currently in 
beta test.

Have any of you had success with this type of drive? Do you think I should 
wait on the SLS or spend $99 on Colorado's own backup/restore software for SCO?

I would prefer to have the unit work with standard UNIX commands, like
'tape' etc.

Thanks for any help you can provide!

Jim Miller    **** USE THE REPLY ADDRESS IN MY SIG, NOT THE HEADER! ****
--
  Jim Miller is jmiller@wendy.bowlgreen.oh.us & osu-cis!bgsuvax!wendy!jmiller
  ** LOOK ! LOOK ! LOOK ! LOOK ! LOOK ! LOOK ! LOOK ! LOOK ! LOOK ! LOOK ! **
    ***** MY ADDRESS IN THE FROM: LINE OF THIS MESSAGE IS INCORRECT *******  
   ** WHILE MY MAILER IS BROKEN. PLEASE USE jmiller@wendy.bowlgreen.oh.us **
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: SCSI ID Problems resolved
Date: 27 Aug 92 00:58:54 GMT
Organization: Izot's Swamp

apl@world.std.com (Anthony P Lawrence) writes:

> Because it was, and I even looked at the jumpers (yep, all 3 of them) and
> somehow just did not see it.  Or somehow figured that all closed MUST mean
> 0 because who would  ship a drive ID'd at  7? (*Conner would-and does)

   Whoops, if I'd have been on the ball I'd have remembered that I've had the 
same problem with Conner SCSI drives in the past.  The first time conincided 
with the arrival of a DOA drive (the first dead Conner I've ever seen), the 
installation of a bus master SCSI host adapter into a motherboard that had 
never before been tested with bus master DMA, and my general lack of 
miscellaneous resources to debug SCSI hardware.  It took a while to figure 
it out...

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
From: kbvan!dave@uunet.UU.NET
Newsgroups: sanet.list.sco,biz.sco.general
Subject: Re: SCSI ID Problems resolved
Date: 26 Aug 92 04:24:17 GMT
Distribution: sanet
Organization: [resent by] The SCOGEN gateway and Propagation Society
X-Conv: Automatic mail-->news conversion at olsa99


Quoting Tony:
>
> Boy, did I screw up!
>
> As I had said to the client as I lay on my back, reaching up into the
> machine to see if cables were loose:  "There's something really screwy
> here, because this drive acts like it's ID 7"
>
> Did I listen to myself?  No.  Am I a total idiot?  Maybe.
>

Most of us would _never_ admit to that out loud. It's good to see
that some people will admit their err, so the rest of us can at least
put the thread to bed. You're OK! in my book, Tony!

--
David Van Allen - Lehigh Software Systems, Inc.
dave@kbvan.COM                   (215) 366-9130
73530,2463 CIS    ************   info@kbvan.COM
uunet!kbvan!dave                  Allentown, PA
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: Colorado QIC40 / SLS available?
Date: 29 Aug 92 01:45:47 GMT
Organization: Izot's Swamp

Jim Miller <jmiller@cis.ohio-state.edu> writes:

>    I just bought a Colorado Jumbo 120 tape drive, which is a QIC 40 unit. I
> was under the impression that this drive would work with SCO 3.2.2, since
> 3.2.2 supports QIC 40 and QIC 80 drives. Not so. I just spoke with
> Colorado's tech support, and the fellow told me that no, SCO UNIX does
> not support this drive, but SCO is working on the problem and an update will 
> released in the form of an SLS.  He also said that the SLS is currently in 
> beta test.

   The glossy propoganda sheet from Colorado Memory Systems that I hold in 
front of me right now says without ambiguity that their SJ-53J Software Option 
is needed to support "UNIX 5.0 From SCO, Interactive, AT&T, Intel".  Their 
interesting interpretation of "System V" leads me to question their dedication 
to the *IX market... 

> Have any of you had success with this type of drive? Do you think I should 
> wait on the SLS or spend $99 on Colorado's own backup/restore software for SC
> 
> I would prefer to have the unit work with standard UNIX commands, like
> 'tape' etc.

   Do you need the backups now or later?  <grin>

   Anyway, this option is supposed to provide a "friendly menu interface" as 
well as tar and cpio utilities for use with Jumbo 120 or 250 drives under the 
aforementioned implementations of "Unix 5.0".  tar and cpio close enough for 
you, or can you not get to work in the morning until you've issued a "tape 
reten" command?  <grin>

   The glossy *seems* to suggest that the UNIX software will work only with 
their FC-10 or TC-15 controller board (the latter comes with hardware support 
for data compression), but it doesn't say so outright.

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
"Feel for the winter but don't have a cold heart" - Little River Band, "Lady"
From: rey@safn2 (rey)
Newsgroups: biz.sco.general
Subject: Changing Adaptec 1740 to enhanced mode.
Keywords: scsi enhanced mode
Date: 2 Sep 92 17:51:02 GMT
Organization: SAF Customer Service, Atlanta GA


SCO Magazine July/Aug 1992 p18 describes the change from ad to eiad driver.

What benefits would I get? 
	EISA Bus Adaptec 1740
		Maxtor LXT-213S 200 meg disk.
		Archive Viper 150 2124 Tape.

Does either device use enhanced features? Is the driver change worth doing?
-- 
Reynolds McClatchey (Southern Aluminum Finishing Co, Atlanta, GA, USA)
Architectural Aluminum. Custom Fabrication. Paint, Powder Coating, Anodizing.
MCImail 414-2935  Voice 404-355-1560  Fax 404-350-0581
uunet!safn2!rey							rey@saf.com
Newsgroups: biz.sco.general
From: vgeorge@eng.umd.edu (Varghese George)
Subject: MDQS ver for SCO available?
Date: Tue, 01 Sep 92 18:58:12 GMT
Organization: College of Engineering, University of Maryland, College Park
Distribution: na
Originator: vgeorge@coke.eng.umd.edu

Hi all! 

I'm looking for a version of MDQS ( Multi-Device Queueing System )
that works with SCO UNIX 3.2v4. ( or any other earlier 
release if one for this is not available). 

Although, ver. 2.18 which I downloaded via anonymous ftp from 
ftp.brl.mil, mentions that it supports System III and V, it has
some of the source files tuned for 4.2 and 4.3BSD
systems ( for those who have used it, files  like 
~/src/netdae.c , ~/src/netopen.c etc ). As such, I run
into trouble at that point in compilation.

Anybody using this stuff on SCO? Would appreciate any help.

Thanks in advance,

Varghese George   

vgeorge@eng.umd.edu
geo@wam.umd.edu

 


Newsgroups: biz.sco.general
From: Bela Lubkin <belal@sco.COM>
Subject: Re: 3.2 4 system reports 3.2 2
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Organization: [resent by] The SCOGEN gateway and Propagation Society
Date: Mon, 31 Aug 1992 23:08:01 GMT
Precedence: bulk

Geoffrey Welsh wrote:

> mike@pacsoft.com (Mike Stefanik) writes:
> 
> > In an article, geoff@zswamp.UUCP (Geoffrey Welsh) writes:
> > >[...] but why does SCO UNIX SysV R3.2v4 report that it is SysV R3.2v2?
> > 
> > If it's so important to have the correct version number, then by all
> > means, change it yourself (an exercise for the determined reader :-)
> 
>    I'm curious more than anything.
> 
>    Also, it reports i386, even when running on a 486.

`uname -a` is more about compatibility than system information.  The
release and version are the release and version of AT&T's source base
from which the operating system was derived.  The processor information
tells you what processor line you're running on -- i.e. which header
files, which libraries, which compiler code generator, etc., are
appropriate.

`uname -X`, on the other hand, is about specific machine information.
It will tell you that you're running 3.2v4.[01], on an i80486, with the
appropriate kind of bus, etc.

>Bela<
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: re: cache design & > 16MB performance
Date: Thu, 03 Sep 92 23:13:40 EDT
Organization: Izot's Swamp

   I haven't yet found the article which led me to believe that direct-mapped 
cache assigned a line of cache per block of memory, but I have come up with 
some interesting findings regarding Bela's theory on tag RAM.

   I checked out several motherboard manuals, and all increase tag RAM size 
linearly with cache RAM size, but do not affect the width of the tag.  A 
Forex-based board insisted on tag RAM being perfectly linear with cache RAM.  
One design based on a C&T PEAK chipset had a fixed cache size: 64K.  I now 
kick myself for not finding out if the board supported 4 MB SIMMs (and, 
thereby, more than a modest 8 MB of RAM).  Other C&T designs used one tag RAM 
configuration for 32 and for 64K cache sizes and another for 128 and 256K,
and an OPTi-based board had a similar scheme except that it mentioned the 
possibility of using the larger tag RAM configuration with the smaller (32 and 
64K) cache sizes.  The board in my 386-40, a C&T-based board, uses four cache 
RAM chips and one tag RAM chip; for 25 MHz they recommend 8K by 8 chips in 
each socket (32K cache) and, for 33 and 40 MHz, 32K by 8 (128K cacke).

   Now that I think of it, I'm amazed that the tag RAM is only eight bits 
wide; what exactly is stored in the 'tags'?!?  And how does eight bits cover 
eight megabytes (as in my machine) or more, since this board will hold 32 MB?  
I suppose they could use consecutive bytes with sequential reads, but it seems 
silly to do multiple reads when the whole purpose of the cache is zero wait... 
and we're only dealing with the tags here, not the cache data itself (which, I 
would presume from the presence of four byte-wide RAMs on my board, is in fact 
a longword wide). 

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
         Coincidentally, most people who fight for "fairness" would be
         significantly better off under the system they call "fair"...