HDTenEightyP/NetNews huggingface dataset:
From: chip@chinacat.unicom.com (Chip Rosenthal)
Subject: Re: Avoiding the "8/16 Bit Problem"
Organization: Unicom Systems Development, Austin, TX
Date: Wed, 26 Aug 1992 23:31:35 GMT

In article <1992Aug26.145710.3533@crd.ge.com>
	davidsen@crd.ge.com (bill davidsen) writes:
>  The real 1542 is a 16 bit card, won't run in 8 bit sockets.

But that's beside the point.

The issue on the 8-bit vs 16-bit conflict is how the device performs
memory accesses.  For example, a card might do 16-bit I/O accesses
but only 8-bit memory accesses.  In the context of this question, such
a card should be treated as an 8-bit card even though it requires a
16-bit slot.

The specific question which needs to be asked is whether the SCSI card
uses 8-bit or 16-bit BIOS ROM accesses, because that is the only memory
mapped portion of these cards.  True, UNIX does not use the BIOS, but
that doesn't matter.  The whole point is that if any card in the 128K
memory segment wants to do memory transfers 16-bits at a time, then
every card in that segment must use 16-bit tranfers.

I don't know the answer to the question, but I'd guess with 99% confidence
that you are right, and the SCSI card does 16-bit memory accesses.

Yes, it's a stupid restriction.  Yes, it's typical IBM engineering.
-- 
Chip Rosenthal  512-482-8260 | The secret to a long life is
Unicom Systems Development   | knowing when it's time to go.
<chip@chinacat.Unicom.COM>   |  - Michelle Shocked
From: tdunbar@vttcf.cc.vt.edu (Thomas Dunbar)
Newsgroups: comp.unix.sysv386
Subject: Re: Unix/Xwindows on a 486...Where/How much?
Date: 25 Aug 92 23:40:31 GMT
Organization: Virginia Tech, Blacksburg, VA


i'm running X386 1.2E with SHAPE, Compressed and Scalable font support, 
ET400 speedup, etc with: Metafont, xfig, olvwm, x11emacs, Lucid GNU Emacs,
and lots of other stuff, all FREE, running on the Linux os which also 
has virtual terminals, multiple sharable libraries, virtual file systems (msdos,
cdrom, minix and ext currently). tcp/ip just went from alpha to beta status.
source for os and all the above is freely avail/distrib
  the abl[2ove runs fine on my 386sx (387sx, 8M ram, 60M disk space), tho 
i'd certainly like a 486 (with ET4000 local-bus video)!
  in short: 386/486 -> nice workstation is free if u can hack it.
From: sam@ug.uk.sun.com (Sam Pierson)
Newsgroups: comp.unix.sysv386
Subject: Re: What is /dev/pmem?
Date: 3 Sep 1992 09:00:38 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: sam@ug.uk.sun.com
NNTP-Posting-Host: ug.uk.sun.com

In article 16817@cti-software.nl, pim@cti-software.nl (Pim Zandbergen) writes:
>dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
>
>
>>On my SVR4 box (Microport), in addition to the standard /dev/mem and
>>/dev/kmem, there is a /dev/pmem.  All three have different minor mumbers 
>>(same major number, so /dev/pmem is obviously related to the other two).
>>The manual page for /dev/mem and /dev/kmem has no mention of /dev/pmem.
>>Can anyone enlighten me on what this is?
>
>I've asked the same question a couple of months ago, because
>there's also a /dev/pmem in Interactive's SVR3.2.
>
>I had zero response then, I wonder if there will be any now.

Under SVR3, /dev/mem only lets you access physical addresses that are
already virtually mapped.  /dev/pmem however will map the addresses for
you if they are not already mapped, allowing you to access *any*
physical address.

I am not familiar with SVR4 internals, but I do not see any reason why
this should have changed.

---
    Sam Pierson -- European Tech Support, SunSoft Inc. High Wycombe, UK.
        Internet: Sam.Pierson@Sun.COM   UUCP: uunet!sun!sam.pierson
         I do not speak for SunSoft, Inc or Sun Microsystems, Inc.

Newsgroups: comp.unix.sysv386
From: oklein@smallo.bo.open.de (Olaf Klein)
Subject: Support (was: Re: How to replace disk driver in SCO Unix ?)
Organization: smallo.bo.open.de Fido-SubNet-Gate : 2:245/5800.12
Date: Mon, 24 Aug 1992 20:25:23 GMT

jochen@mrz.sub.org (Jochen Fahrner) writes:

>P.S.: Can someone recommend a german SCO distributor which has a good
>support ? We tried two different distributors, both have a very poor
>support. The guys at their "hotlines" don't know much about SCO or
>unix in general. If I tell them, there is a bug in the Microsoft C
>6.0, it can't compile the following statement:
>	const char *p[2];
>	p[0] = "wrzlbrmpft";
>they tell me, my code is wrong, the compiler is ok !!!
>If we don't find a better SCO distributor, we have to switch to
>another brand of unix. We don't care if our unix is from SCO, ISC,
>Dell or whatever. What we need is a working unix and a good support !

I don't know any Unix with good support, (my firm bought a sun clone,
a service man from this firm "and how do I get the floppy back out of
the drive?" answer for non-suns - "eject") 
(Come on Larry, its your turn to advertise for Dell...)
I work with SUN-OS 4.1.1 and SCO-Unix 3.2.4 and all things I know, I
know because of reading usenet or debugging wrong running programs...
In my opinion it's the cheapest and easiest way to get
informations about your system - the only thing I would prefer
would be a mail to a programmer ot the system...(but I fear that all
SCO-programmers are shot after releasing the system because of C2 >;-)  )
An answer from a system admin is mostly very more reality than an
answer from the vendor of the system..

Bye, Olaf


-- 
Olaf Klein     smallo.bo.open.de       2:245/5800.12
From: mbarkah@slate.mines.colorado.edu (Ade Barkah)
Newsgroups: comp.unix.sysv386
Subject: Clue Me Re: SVR4.2 Please !
Date: 25 Aug 92 19:22:39 GMT
Organization: Colorado School of Mines

Well, I've been gone throughout the summer, and I come
back with some excitement (but no substance) regarding
USL's svr4.2. Can someone give me some details about
4.2 ? About the only thing I've heard is that it will
support DOS & Windows, and it somehow ended the Unix
wars. (Bye bye OSF ?)

Regards,

-Ade Barkah.
-- 
Internet  : mbarkah@slate.mines.colorado.edu    (NeXT Mailable)
CompuServe: 74160,3404
FIDO_net  : Ade Barkah [1:104/108@fido.org]
SNAIL_net : 1800 West Campus Road, Golden, CO 80401
From: jrh@mustang.dell.com (Randy Howard)
Newsgroups: comp.unix.sysv386
Subject: Re: SVR4 tar
Date: 31 Aug 92 19:53:39 GMT
Distribution: usa
Organization: Dell Computer Co

les@chinet.chi.il.us (Leslie Mikesell) writes:

>In article <jrh.714700942@mustang> jrh@mustang.dell.com (Randy Howard) writes:
>>You are correct.  In Dell UNIX I added a backwards compatibility flag so that
>>it would do the right thing for old 3.2 unix systems.  I don't know if any
>>of the other vendors did that.  If you are using Dell UNIX, the flag you
>>want is 'Z'.

>What's the difference, and does GNUtar care?  
The difference is it won't stick directory entries in the archive.
I have no idea what GNUtar does about this.
>What should happen if you
>have a SysVr4 and SysVr3 system cross mounted with RFS and use each other's
>tar on the opposite filesystem?  (Actually, if you rfs mount a UFS filesystem
>into a SysVr3 machine, find won't recurse down it's directories and make
>won't see anything to be done - is that supposed to happen?)

Hmm, you can't use the SVR4 version of tar on the 3.2 machine, because the
binary won't fire off, you can however use the 3.2 version on the V.4 
machine (i.e. backwords, not forward compatibility).  3.2 generated archives
are understood by the SVR4 tar.  I don't know how rfs impacts the behavior,
I can only wonder why you would use that instead of nfs :)  Seriously, we'll
take a look, it's conceivable that the rfs code doesn't handle the truncation
right for big inode numbers or something similar.

>Les Mikesell
>  les@chinet.chi.il.us
-- 
Randy Howard            _o	    @'s: jrh@dell.com
Dell Computer Corp.     \<,	    !'s: ...!uunet!dellunix!jrh
______________________()/ ()______________________________________________
Superusers should wreak havoc only by accident.
-- Maurice J. Bach "The Design of the UNIX Operating System"
Newsgroups: comp.unix.sysv386
From: larry@gator.rn.com (Larry Snyder)
Subject: Re: disk mirroring
Organization: The Gator Public Access Unix Site - 219-289-3745
Date: Mon, 31 Aug 1992 21:09:22 GMT

chip@chinacat.unicom.com (Chip Rosenthal) writes:

>I'm quite excited by this move.  Everybody I've talked to about the
>Chantal drivers has told me pretty much the same story:  (1) the
>drivers work very nicely, and (2) the company was the worst, most

At one time, they were working in improving the ISC 3.2 2.0
SCSI drivers -- they claim "increasing speed by 100%" -- to the
best of my knowledge, these drivers never shipped -- 

Their SCO drivers were very, very fast --

-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry
Newsgroups: comp.unix.sysv386
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Subject: Re: X386 1.2E on ATI Graphics Ultra
Organization: AT&T
Date: Wed, 2 Sep 1992 15:27:37 GMT

In article <BtyAsx.7FB@gator.rn.com> larry@gator.rn.com (Larry Snyder) writes:
> hlu@poly2.eecs.wsu.edu (H.J. Lu) writes:
> 
> >Get Linux. I think it has X386 1.2 for ATI Graphics Ultra . It is free. I
> >think it may get back into 1.2E.
> 
> Get Dell.  Dell comes for complete support for it "out of the box".
> 
> -- 
> Larry Snyder                                    internet: larry@gator.rn.com
> keeper of the Gator                                  uucp: uunet!gator!larry


Why do people feel compelled to tell others to buy a new operating system?
The original poster was asking about Esix 4.0.4; he's not likely to dump
this and get Dell.  Linus is not an option for many people because it does
not run commercial software (yet).

Putting an 8514 or S3 server into a stock USL-based SVR3 or SVR4 is 
non-trivial.  According to Thomas Roell (I wish I had saved the posting),
who is in a position to know, shortcuts were taken in the kernel that
make accessing devices using the extended registers on the 8514 and
S3 prone to error.  SGCS (and, from what I'm told, MetroLink) have
a kernel patch that works around this for their offerings.

What's going to happen with porting the Linux 8514 driver into SVR3
and SVR4 is up in the air.  There are people beginning to look at it;
the core team is not involved in accelerated servers directly.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat             | dwex@mtgzfs3.att.com  | Somebody get me a
AT&T Bell Laboratories      | ...!att!mtgzfs3!dwex  |   cheeseburger!
200 Laurel Ave - 4B-421     |                       |      
Middletown, NJ  07748       | (908) 957-5871        | --Steve Miller Band
From: hlu@poly2.eecs.wsu.edu (H.J. Lu)
Newsgroups: comp.unix.sysv386
Subject: Re: X386 1.2E on ATI Graphics Ultra
Date: 2 Sep 92 00:48:51 GMT
Organization: Washington State University

Get Linux. I think it has X386 1.2 for ATI Graphics Ultra . It is free. I
think it may get back into 1.2E.

H.J.
Newsgroups: comp.unix.sysv386
From: pat@abtlabs.uucp (Patrick Conroy)
Subject: Help "gdb" under ISC V3.0
Organization: Abbott Laboratories
Date: Thu, 27 Aug 92 20:46:06 GMT


Has anyone successfully built/installed "gdb 4.6" under ISC V3.0?

I've just downloaded the code, and I can't even get past the "configure"
stage.  I've tried variations on "./configure isc"  and I invariably
get back :    "*** Gdb does not support i386-unknown-iscsysv ***".

I'd be very grateful for some help!
Thanks - Patrick
=============================================================================
Patrick Conroy                   Internet: pat@doc.abbott.com
Abbott Laboratories           AnotherINet: pat@turing.abbott.com
P.O.B. 152020              YetAnotherINet: 75016.3500@CompuServe.com
1921 Hurd Drive   2-27       TelephoneNet: (214) 518-6738             The sky
Irving, TX 75015-2020              FAXNet: (214) 518-7469           is cryin'
Newsgroups: comp.unix.sysv386
From: paul@pphbau.atr.bso.nl (PPH Bauwens)
Subject: Re: X does not reset screen mode under ESIX
Organization: PPH Bauwens
X-Newsreader: Tin 1.1 PL5
Date: Mon, 31 Aug 1992 20:15:46 GMT

Simon Langley (slangley@constant.demon.co.uk) wrote:
: 
: I am having problems with X under ESIX SVR4 using a Trident 8900C SVGA card.
: 
: I am using the 1024x728x256 server.  The problem appears when I come out of
: X or change to another virtual terminal the screen mode is not reset properly.
: What I see is 8 fuzzy copies each shifted slightly to the right in very small
: print of the prompt &c.

Dear Simon,

Did you forget re-running 'evgainit' after building a new kernel?

Check if 'evgaqry -verbose'  (in /usr/sbin)  gives the correct
Trident card answer. 

You can also try a different Trident card or different card with a 
Trident chipset. Also, to my knowledge ESIX has an updated X server
available on their BBS.

Hope this helps.
-- 
--------------------------------------------------------------------------
Paul Bauwens			E-mail:	 paul@pphbau.atr.bso.nl
Rietkerkweg 364				 paul@pphbau.hobby.nl
3066VL Rotterdam		Phone:   +31-10-4211858
Newsgroups: comp.unix.sysv386
From: bill@unixland.natick.ma.us (Bill Heiser)
Subject: Re: Dell SVR4 News: Can't Post
Organization: Unixland Public Access Unix  (508) 655-3848
Date: Fri, 4 Sep 1992 00:31:37 GMT

bash@tware.UUCP (Paul Bash) writes:

>You must have a different installation tape than I do (or it flew past so 

You probably don't have the "advertisers special!"   :-) :-) :-)

-- 
bill@unixland.natick.ma.us                      ESIX Mailing List Moderator
Public Access UNIX/USENET/E-MAIL!  UUCP Accounts Available!  (508) 655-3848
5 lines  -  Located in Natick, MA   USA    Supporting V.32/PEP/V.42bis, etc.
Newsgroups: comp.unix.sysv386
From: danson@lgc.com (Doug Anson)
Subject: UHC SVR4 and gdb 4.6
Keywords: UHC SVR4 GNU GDB GCC
Organization: LandMark Graphics Corporation LGC
Date: Fri, 28 Aug 1992 14:32:45 GMT

Hello!

I have successfully installed gcc (2.2.2) and g++ (2.2.2) on my UHC SVR4
(4.0.2.0) system. I have *COMPILED* gdb 4.6 and installed the beast. 
However, when I try *USING* gdb on a small "hello world" test program
compiled with gcc -g, my kernel panics as sure as the sun rises in the
east!

I compiled gdb with the i386-svr4 configuration. I compiled gcc with
the i386-svr4 configuration as well. gcc works *WONDERFULLY* on my system
and sdb correctly uses the debugging stuff provided by gcc -g. 
(FYI dhrystone1.1 compiled with gcc -O -O2 gave 16666 dhrystones on my
 386/33.  Thats better than the stock cc can do! -- using the register option
  of course...)

Has anyone gotten gdb 4.6 running on svr4?  Are there binaries available to
a working gdb that I can ftp? 

On another note, I've noticed that some svr4'ers use the old getty instead
of ttymon.  Just curious, what is the advantage of doing this?  When running
X386 and using vi, I've noticed that "arrow" keys are kinda "abrupt" and 
slow -- does using getty instead of ttymon fix this?   Is there a FAQ on how
to switch from ttymon *to* getty?

Thanks in advance,
Doug
-- 
-------------------------------------------
Doug Anson					
Internet: danson@lgc.com			
Phone:	  713-579-4739
SNAIL:    Landmark Graphics Corporation LGC	
	  333 Cypress Run			
	  Houston, TX 77094			
-------------------------------------------
Newsgroups: comp.unix.sysv386
From: sells@cs.umn.edu (Chris Sells)
Subject: Re: cpio one file at a time?
Followup-To: comp.unix.sysv386
Organization: Spanlink Communications
Date: Mon, 31 Aug 1992 03:12:42 GMT

In article <1992Aug31.011929.9632@unislc.uucp>, dold@unislc.uucp (Clarence
Dold) wrote:
> 
> From article <sells-290891105149@dialup-slip-1-31.gw.umn.edu>, by sells@cs.umn.edu (Chris Sells):
> 
> > The 'mv' was only an example. I'll be performing multiple operations on
> > each file and I need to be able to do it before the next file is loaded.
> > BTW, what's pax?
> 
> Methinks that a named pipe fits into this scheme somewhere.
> I might be inclined to read directly from the tape to a file, perhaps via my
> code, or dd, where the file on disk is a named pipe that would be a raw
> cpio dataset.  Then the "special" process would read from the raw data, and
> pipe to cpio.  While monitoring the files that cpio is creating and filling
> (by some undescribed method), the "special" process would stop feeding data
> down the pipe to cpio until the manipulation was done.  Then the data feed
> would resume into cpio.
> The named pipe would be some system determined maximum size on disk, I think
> 5K.  The tape coming in would stop while the pipe was at its maximum size,
> and feed when the named pipe is drained.  The "special" process would act as
> a throttle, controlling the data rate into cpio.  Without figuring out how
> to monitor the internals of a cpio archive, I might do something as crude as
> a cpio -it to find the file names on disk, storing the names, then start in
> earnest, watching for each to be created (or modified), as an indication that 
> the previous one was fully restored.
> Named pipes are created with "mknod foobar p"
> 
> -- 
> ---
> Clarence A Dold - dold@unislc.slc.Unisys.COM
>                ...pyramid!ctnews!tsmiti!dold

You mean, something like this?

mknod foo p                      # make input pipe
mknod bar p                      # make output pipe
pr_pid=`pipe_reader foo bar &`   # start pipe_reader and keep pid

dd if=/dev/rdsk/tape0 >foo &     # start data dump

cat bar | cpio -iv |             # dump 'throttled' data into cpio
while read file                  # for each file
do
   kill $pr_pid                  # signal pipe_reader to pause
   handle $file                  # handle file while cpio paused
   kill $pr_pid                  # signal pipe_reader to continue
done

Thanx, I'm not sure how well this would work, but it's the best (read
'only) idea I've gotten so far.
+-------------------------+
| Chris Sells             |
| Spanlink Communications |
| sells@cs.umn.edu        |
+-------------------------+
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.unix.sysv386
Subject: Re: SUMMARY: Re: Questions about MAS90 from SOA
Date: 27 Aug 92 12:06:58 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <BtKDCp.4tC@mudos.ann-arbor.mi.us>, mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:

| think I've finally gotten it to the point where it's usable.  There is
| one problem that I'm still having, though -- because the bbx2
| interpreter does not work properly if run SUID or SGID, I have had to
| make the database directories and files writable by the people who are
| going to be running MAS90.  This is a large security hole, IMHO --
| this means that the people using MAS90 can remove the databases or
| modify them without going through MAS90, either with a binary-file
| editor or by directly typing commands into BBx.  It also means that
| instead of just having to secure a "mas90" account or the root
| account, I must make sure that all of the MAS90 users' accounts are
| secure.

  I included this in my response to you, perhaps you missed it:

Have people login as themselves then do a "su - mas90" to access the
database. That way only the mas90 account has to be able to get at the
data, and you can use the mas90 program itself as the login shell, or
use a secure login shell which can start mas90. That seems to eliminate
most of the problems you mentioned.

You could also use a command sutuid root which does a seteuid() and then
starts mas90, I bet that will work, too.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
Newsgroups: comp.unix.sysv386
From: dsamperi@ccorp.uucp (Dominick Samperi - bond)
Subject: Re: larger/higher resolution monitors
Organization: Citicorp, New York City
Date: Wed, 26 Aug 92 02:47:27 GMT

In article <1992Aug19.122333.19628@newshost.unh.edu> pss1@kepler.unh.edu (Paul S Secinaro) writes:
>In article <Bt5rD7.1rw@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
>>In article <1992Aug17.222036.29571@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>>>  Now, even if you spend the money for a very fine dot pitch, you will
>>>find that the human eye limits you, and you have to get very close to
>>>the display to read reasonable text. 1024 on a good 15 inch display is
>>>useful, but if the price were right I would go to 20.
>>
>>The major problem here, I think, is a basic misunderstanding.  When
>>you go to 1024x768 on a 14" monitor, you're not usually trying to make
>>the text smaller so you can cram more on the screen.  (Like I said,
>>usually.)  Instead, you want to keep the text about the same size as
>>you might use at 800x600, but have finer characters with a bigger
>>character box.
>>

My goal is to configure a PC at home with a 16-17" monitor so that some PC
UNIX running X windows that will support text and graphics that is at least as
clear as it is on a 16" Sony monitor that comes standard with a Sparc2 (same
aspect ratio, etc.). The Sparc configuration does not require the use of
a huge monitor yet the work space is adequate for work under X windows.

Possible on a PC?


-- 
Dominick Samperi -- Citicorp
dsamperi@Citicorp.COM
uunet!ccorp!dsamperi
From: rolf@saans.north.de (Rolf Nerstheimer)
Newsgroups: comp.unix.sysv386
Subject: Re: SCO support (was: How to replace disk driver in SCO Unix ?)
Date: 29 Aug 92 09:05:35 GMT
Article-I.D.: saans.1992Aug29.090535.1657
Organization: a private node

davidsen@ariel.crd.GE.COM (william E Davidsen) writes:

>In article <JOCHEN.92Aug24111621@mrz.sub.org>, jochen@mrz.sub.org (Jochen Fahrner) writes:

>| I don't have another way to tell SCO about bugs, than through our
>| distributor. 

>Mail to support@sco.com. They may or may not fix your bug, but they sure
>as hell read mail to that address (and this newsgroup).

No, Bill, this only works, if you're in the USA.

I e-mailed a bug report to support@sco.com. They forwarded it to
SCO-London. These guys told me, that it is impossible for me ( speaking
for a company with 100000+ employees ) to get support from SCO 
(unless you buy a support-contract from SCO-London ) via e-mail or fax or voice.
They advised me to our german distributor, who wants to sell its own
support me, and (sorry) couldn't help me without a contract.

PLease understand me, I'm in business now for 12 years ( almost 5 years 
with SCO-products ). In those good old days the os-guys were happy, if you
showed them the bugs in their system, giving them a chance to fix it in time.

Nowadays, maybe Larry is right. 
For my part, I don't like SCO anymore, they don't listen any longer. 
It's seems, time has come to try something else.
-- 
Rolf Nerstheimer, Surwisch 20, 2856 Sandstedt, Germany   | a private 
E-Mail: rolf@saans.north.de    Voice: +49 4702 1285      |   node           
"Contrariwise," continued Tweedledee, "if it was so, it might be; and if it
were so, it would be; but as it isn't, it ain't. That's logic." Lewis Carroll
Newsgroups: comp.unix.sysv386
From: larry@gator.rn.com (Larry Snyder)
Subject: Re: SCO support (was: How to replace disk driver in SCO Unix ?)
Organization: The Gator Public Access Unix Site - 219-289-3745
Date: Tue, 1 Sep 1992 12:22:50 GMT

bill@Celestial.COM (Bill Campbell) writes:

>via a mailing list to those who don't have news access.  SCO has
>a far greater presence on the net than say, Interactive (SunSoft),
>DELL, USL....

Since as you say they have 2 dedicated individuals reading the net,
I would hope their presence would be noticed.  Yes, they also
have their own newsgroups as well -- under biz --

-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry