HDTenEightyP/NetNews huggingface dataset:
From: berger@atropa (Mike Berger)
Subject: Re: Any Digicom Scout+ bugs?
Organization: University of Illinois at Urbana
Date: Sat, 21 Nov 1992 21:22:44 GMT

zeke@fasttech.com (Bohdan Tashchuk) writes:
>>As Wolfgang has said, Prodigy is selling Digicom Scout+ external
>>modems, Prodigy calls them "Eagles".  They come with a 30 day money back
>>guarentee for $199.00 U.S.  I haven't seen ANY bug reports about the
>>Digicom Scout+, this seems too good to be true.

>Perhaps it IS too good to be true. Has this modem been "crippled" in any way,
>or is it the standard Digicom product?

>Wolfgang, are you SURE it is the standard product?
*----
All of the announcements I've read billed it as a V.32 modem, not
V.32bis.  That would explain why it only connects at 9600 baud.
I'm also curious as to what's really included now.
--
	Mike Berger
	Internet    berger@atropa.stat.uiuc.edu
Newsgroups: comp.dcom.modems
From: jlacour@casbah.acns.nwu.edu (John Lacour)
Subject: Re: USR Sportster Question
Followup-To: poster 
Organization: Northwestern University, Evanston Illinois.
Date: Tue, 17 Nov 1992 22:07:26 GMT

In article <1ebcfdINN62n@uwm.edu> rlippert@csd4.csd.uwm.edu (Ryan Jon Lippert) writes:
>I'm sure EVERYONE knows about the Sportster PROBLEM(?!) be able to have
>a FULLY working Dual with just a few AT commands. What I wanna know is,In the
>NEW version of the modem (After 4.1) did they change anything BESIDES the
>Roms???? Like the mother-board or something.? Well if you know I'de be REAL
>glad if u responded... thanks..

I wouldn't advise you waste your time trying to duplicate the 4.1 supervisor
ROM.

Regards,
--
John A. LaCour III, Technical Support                      +1 708 982 5151
USRobotics, Inc.                                       FAX +1 708 933 5552
8100 N. McCormick Blvd.                           
Skokie, IL  60076                              jlacour@casbah.acns.nwu.edu

USR Email:      jlacour_+a_robopost_+ljohn_lacour+r%usrobotics@mcimail.com
Newsgroups: comp.dcom.modems
From: paul@tvt-k (Paul Pries)
Subject: Re: Zyxel refuses to drop carrier detect ?
Organization: >Televerket Utbildning, Utf
Date: Mon, 23 Nov 1992 11:08:53 GMT

sinan@carson.u.washington.edu (Sinan Karasu) writes:


> We got a Zyxel 1496E couple of weeks ago. This goes on a 
>Sparcstation 1 at home. It works mostly great. (refreshing after 
>4 USR Sportsters 14400 that never answered and 1 USR Sportster 9600
>that did work for 10 days and died.) Anyway. Zyxel stays on line
>after the uucp connection drops. Carrier detect stays on , 
>and the line is hung up.... (If I call it I get a busy signal).
>I have not been able to determine if the other side hangs up or
>not. It seems to work fine if I tip to cua0 and connect and then
>exit; then it drops the connection . Only in uucp do we have 
>a problem. Has anybody been able to configure a Zyxel 1496E ver 5.02
>correctly for a SparcStation?

>The only things we change are 
>  S00=001
>  and sometimes &K0 (otherwise we have problems with 
>                       telebit modems)

>Thanx...
>Sinan

Did you turn off the software carrier detect? If you don't, the Sun will
emulate a carrier detect signal in software and thus, never hang up.
Check the manpage for ttysoftcar and zss.
Hope this helps...
/Paul.
--
Paul Pries
email: 5322@msg.abc.se    

Newsgroups: comp.dcom.modems,ch.sun-managers,comp.sys.sun.admin,comp.sys.sun.hardware
From: osicki@hasler.ascom.ch (Chris Osicki)
Subject:  V.32BIS / Sun workstation problem
Originator: osicki@polaris
Reply-To: osicki@hasler.ascom.ch
Organization: Ascom Hasler AG
Date: Mon, 23 Nov 1992 16:27:14 GMT


Configuration:	Zyxel U-1496 modem connected on ttya (tty speed set to 38400)
		Sun ELC & Sun IPC, SunOS 4.1.2

When a connection is made at 14400, V.42, V.42BIS many characters are 'lost'.
Connecting a vt220 directly to the modem instead of the ELC no characters
are lost. Is this a known problem in that Suns serial ports cannot handle
data at high speeds? If yes, are there any solutions (H/W or S/W) which
solve this.

Please reply by email and I will summarise.

Many thanks,
Chris


   Chris Osicki ( osicki@hasler.ascom.ch )
   System and Network Administrator
   Ascom Hasler AG, Abt 85L2, Freiburgstr. 251,
   CH 3000 Bern 18, Switzerland.  Tel: +41 31 999 38 07, Fax: +41 31 991 37 35
Newsgroups: comp.dcom.modems
From: tim@boxhill.com (Timothy Jones)
Subject: SUMMARY: ZyXEL not hanging up on DTR off
Organization: Box Hill Systems Corporation, New York, NY
Date: Thu, 19 Nov 1992 15:23:25 GMT

The modem I was having trouble with is a U-1496E, but had a U-1496E+ PC board
inside.  Apparently the ZyXEL engineers don't believe this to be a problem,
but replacing the PC board with an E version fixed all bugs I saw.

Nick in tech support was quite helpful and got me a replacement pronto.  Kudos
to them.  I'll be ordering more shortly.

Tim
--
Timothy Jones                                           e-mail: tim@boxhill.com
Box Hill Systems Corporation                                voice: 212-989-4455
161 Avenue of the Americas, New York, NY, 10013               fax: 212-989-6817
From: jason@retina.anatomy.upenn.edu (Jason Ehrlich)
Newsgroups: comp.dcom.modems
Subject: Re: Any one use ZyXEL on Mac?
Date: 18 Nov 92 00:09:04 GMT
Organization: Dept. of Neuroscience, U. of Pennsylvania

Either FAXstf or QuickLink II/FAX should work okay. FAXstf is what
ZyXEL is shipping with their modems now, when you request the Mac
package.

I have a ZyXEL and a Mac, but I haven't tried the FAX. Although I have
the FAXstf 2.2 software and hear it works very well.

jason
From: jay@gdx.UUCP (Jay Snyder)
Newsgroups: comp.dcom.modems
Subject: Faxmodem Upgrade for T3000's -- Worldblazer too?
Date: 17 Nov 92 21:49:24 GMT
Organization: GDX-BBS,Central Pa Unix BBS/anon uucp (717)737-3249 PEP+/2400/1200 24hrs


I got a flyer in the mail from Telebit Corp., about the latest T3000
promotion.  It describe the new fax feature for the T3000s, and that
this is an upgrade feature.  Could someone from telebit tell me if
this is availible for WorldBlazers?

Thanks,
J
_______________________________________________________________________________
Jay A. Snyder               jay@gdx            ...{uunet,eds1}!wa3wbu!gdx!jay
This is your Brain: (unix)              GDX-BBS (717) 737-3249 WorldBlazer
This is your Brain on drugs: (MSDOS)     Unix and MSDOS File areas + Xenix bins
Newsgroups: comp.dcom.modems
From: ssmith@eos.arc.nasa.gov (Stephen Smith)
Subject: PEP over SLIP?
Summary: is SLIP viable over PEP?
Keywords: SLIP PEP
Organization: NASA Ames Research Center
Distribution: usa
Date: Mon, 16 Nov 1992 21:30:34 GMT

Is it possible to use SLIP over a PEP connection? 
I appologize if this is a FAQ.

Thanks, 
	-Steve

-- 
-----------------------------------------------------------------
ssmith@eos.arc.nasa.gov                  (415) 604-1381  
NASA Ames Research Center                Moffett Field, Ca. 94035
Newsgroups: comp.dcom.modems
From: ssmith@eos.arc.nasa.gov (Stephen Smith)
Subject: SUMMARY : PEP over SLIP?
Summary: not advisable
Keywords: PEP SLIP 
Organization: NASA Ames Research Center
Distribution: usa
Date: Tue, 17 Nov 1992 17:08:27 GMT


The replies to my query suggest *not* using SLIP over PEP because it is
slow. This bears out my experience this a.m. w/PEP between a world-blazer 
and trailblazer plus (I'm not alone :-). 



Here is the summary :
From Vernon Schryver:
	Yes, but if possible, you would be happier with SLIP over v.32 or 
	v.32bis.

From Wolfgang S. Rupprecht:
	Possible yes.  Enjoyable no.

	PEP == high turn around delay.

From Ivars Upatnieks:
	PEP only works well in a single direction.  For example, if you want
	to send lots and lots of characters from system A to B, but only an
	occasional character for B to A, PEP is for you.

	SLIP will work, but REEEEAAAAALLLLYYYY slowly.  It would probably
	be better to just use a 2400bps connection instead.

From David Lesher:
	It's very slow & not advisable.


	
My thanks to all who took the time to respond.

	-Steve
-- 
-----------------------------------------------------------------
ssmith@eos.arc.nasa.gov                  (415) 604-1381  
NASA Ames Research Center                Moffett Field, Ca. 94035
Newsgroups: comp.dcom.modems
From: ipacs@solomon.technet.sg (IPACS PTE LTD)
Subject: Re: NEW USR COURIER PRICING
Organization: TECHNET, Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Mon, 23 Nov 1992 05:12:06 GMT

What about Sysop prices?
From: tnixon@hayes.com
Newsgroups: comp.dcom.modems
Subject: Re: AT&F command - does it truly reset?
Date: 23 Nov 92 10:51:39 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Nov18.162012.20888@uhura.neoucom.edu>,
wlrc@uhura.neoucom.edu (William R. Cruce) writes: 

> What does the 'AT&F' command do in a Hayes or truly Hayes-compatible?

It doesn't "reset" at all.  AT&F copies the ROM default values for 
SELECTED parameters (commands and S-registers) into the current RAM 
settings.  It doesn't change the user-storable non-volatile memory 
settings directly (you do that with &W).  The behavior of &F is no 
different than if you had individually issued a whole bunch of 
commands and S-registers (e.g., AT&E1L2M1N1PQ0S0...S0=0S2=43..., 
etc.).

> What does it do in a Gateway Telepath?  Gateway's tech service can't
> give me a straight answer (flames  about that will be reserved for
> another post :-<<).

I have no idea.  Note that my description above is of the way &F 
works in Hayes modems.  Behavior may vary in modems from other
manufacturers. 

> I am looking for a way to do a software reset of the modem to factory
> conditions.  'AT&F' is supposed to do that.  But apparently it doesn't rest
> the 'S' registers. Or not all of them. Or some of them sometimes.  Maybe.

Like I said, &F doesn't necessarily set EVERY parameter and 
S-register, but selected ones.  In the case of Hayes modems, &F 
(without a number) sets virtually all of them, but the selection of 
affected registers/parameters and the resulting settings are quite 
likely different in products from other manufacturers.

> The reason?  I have to use different command sets to link with different
> remote systems/modems.  I would like to cleanly reset the modem before
> using a new command set.  Things from other commands seem to lurk about
> and confuse the issue.  Most notable is the N0S37=n where n is an integer
> representing modem speed, e.g. '9' = 9600.  This seems to help with some
> communications but the only way to clear it is to shut power to the system
> completely down and restart.

Why not just do AT&FS37=0N1, if you know those particular settings 
are a problem?  If your software has control of the modem, &F is no 
different from individually issuing the commands to change the 
necessary parameters.

FYI, in Hayes modems AT&F sets S37=0 and N1.

-- 
Toby Nixon, Principal Engineer      | Voice   +1-404-840-9200  Telex 401243420
Hayes Microcomputer Products, Inc.  | Fax     +1-404-447-0178  CIS   70271,404
P.O. Box 105203                     | BBS     +1-404-446-6336  AT&T    !tnixon
Atlanta, Georgia  30348             | UUCP uunet!hayes!tnixon  Fido   1:114/15
USA                                 | Internet                tnixon@hayes.com
From: shobhana@shakti.ncst.ernet.in (Shobhana)
Newsgroups: comp.dcom.modems
Subject: Recommendations for Modems+Terminal server rack?
Date: 20 Nov 1992 01:29:00 -0600
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu


Hello---

We need to have dial-up connectivity at our facility here---we'll be
looking to provide about 50 lines. Given that our facility has a
TCP/IP based network with workstations connected over ethernet, what
configuration you would recommend for a modem + terminal server rack?

Is there any way to avoid using 50 modems? What about PBXes? Would
they be useful?

I would appreciate E-mail responses since our site tends to lose news
sometimes. Please reply to shobhana@shakti.ncst.ernet.in.

Thanks in advance
Shobhana
Newsgroups: comp.dcom.modems
From: paul@tct.com (Paul Levin)
Subject: ZyXEL Phone Number
Organization: TC Telemanagement, Clearwater, FL
Distribution: na
Date: Mon, 23 Nov 1992 14:43:49 GMT

ZyXel -- 800-255-4101
-- 
From:  Paul Levin   paul@count.tct.com   813-532-2239 (work, 9-5 EST)
    --> Jesus loves you, and died for you; thank Him today. <--
From: jim@n5ial.chi.il.us (Jim Graham)
Newsgroups: comp.dcom.modems
Subject: 14400 modems and 16550 UARTS (Problem with higher trf 
Distribution: world
Date: Wed, 18 Nov 92 23:25:27 GMT
Organization: Me? Organized? Hah! :-)

In article <Bxsnqn.B6z@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us
writes:

> Were you having problems before with lowered throughput due to dropped
> incoming characters?  If not, then the buffers on a 16550 UART will do
> absolutely nothing to increase your transfer speed.

taken literally, the above is true....but there is more to it than
just the above (and this bit isn't talked about as much here).  see,
the buffers are only the first part of what the 16550 buys you.  the
second part is a little thing you can do *WITH* those buffers, that
being reducing the number of interrupts generated.  remember that every
time an interrupt is issued, the CPU has to stop what it's doing to
service the interrupt.  this doesn't happen instantly...there is a
certain amount of time wasted when the CPU is changing tasks (context
switching overhead).

the 16550 can help reduce the number of interrupts required (assuming
your software goes along with this) by allowing more than one character
to be handled per interrupt.  basically, you can tell the 16550 not to
issue an interrupt until a certain number of characters are in the Rx
FIFO (1, 4, 8, or 14).  let's assume we set this to 8 characters.  now,
instead of every single incoming character causing an interrupt, the
UART waits around until EITHER their are 8 characters in the Rx FIFO
*OR* a certain amount of time has passed w/o an interrupt being issued
since there was at least one character in the FIFO (in other words, it
doesn't sit there like an idiot and wait forever).

along with this, of course, your software has to know that it might be
taking more than just one character for any interrupt it services.

btw, this information is adapted right out of the National Semiconductor
data sheets (Application Note 491, ``The NS16550A: UART Design and
Application Considerations'').

type at y'all later --- gotta go meet someone ASAP.
   --jim

--
#include <std_disclaimer.h>                                 73 DE N5IAL (/9)
------------------------------------------------------------------------------
INTERNET:  jim@n5ial.chi.il.us  |  grahj@gagme.chi.il.us  |  j.graham@ieee.org
ICBM:  41.70N 87.63W                    UUCP:  gagme!n5ial!jim@clout.chi.il.us
AMATEUR RADIO: (unstable...back after I've moved)          AMTOR SELCAL:  NIAL
------------------------------------------------------------------------------

Newsgroups: comp.dcom.modems
From: sja@world.std.com (Stuart J Adams)
Subject: Looking for Wireless Modems for Handheld PC
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 18 Nov 1992 04:52:32 GMT

I am looking for a wireless modem/network interface for a handheld
type PC.  (ideally in the form of a PCMCIA card).

Thanks,
Stuart Adams
sja@world.std.com
From: jma@reef.cis.ufl.edu (John 'Vlad' Adams)
Newsgroups: comp.dcom.modems
Subject: Re: Why is Supra able to sell?
Date: 20 Nov 92 03:49:46 GMT
Organization: Univ. of Florida CIS Dept.

Did st1r8@elroy.uh.edu really type:
}  is unreliable.  The Dual Stanards cost too much and USR is getting
}  much too much money than their worth.  If USR would sell the Dual
}  at a resonable price, they might sell a whole lot more!  (They should
}  bring their list price for the Dual down to the sysop price, and the
}  sysop price half of what it is now).

As a sysop who recently purchased the 16.8k DS, I'm happy with the
price. $464 is more than a sysop ZyXEL, but then I get the best of
both worlds - connectivity to the V.32bis world as well as to the
thousands that own HSTs.  If I had purchase the ZyXEL, I would have
alienated many high speed HST callers, and I have more HST callers
than V.32/V.32bis callers.  In addition, many support boards for
software are HST-only.  This is changing, granted, but still a factor
to the sysop for consideration.
-- 
    _   Who:    John 'Vlad' Adams  (squig)  Scott T. Downtrodder III)
 _ //   Where:  jma@cis.ufl.edu    -or-    jadams@coral.senod.uwf.edu
 \X/    Why:    Lead us not into tempation - we'll find it ourselves!
Newsgroups: comp.dcom.modems
From: tpang@fraser.sfu.ca (Tsui Ting Debbie Pang)
Subject: Re: Experience with Digicomm? (Not Digicom)
Keywords: digicom, v.32bis, scout
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Wed, 18 Nov 1992 12:29:02 GMT

At that price $199. I think it is more likely an external? The previous
articles don't say which. I read someone on the net selling internal
model for that price. Wasn't it a while ago, some talks about selling
things commercially on the net here?

If it's external, then it must be the cheapest v.32bis modem I've ever seen.

I got a ZyXEL 1496E some time ago, and very happy, with their promotion
BBS contest discount, 40% off list.

David Tse
Newsgroups: comp.dcom.modems
From: tpang@fraser.sfu.ca (Tsui Ting Debbie Pang)
Subject: REPOST: Modems reviews/comparisons/polls
Summary: ZyXEL stands out! Supra so so. Gateway worst.
Keywords: reviews,comparisons,polls,Supra,ZyXEL,PPI,testing
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Thu, 19 Nov 1992 08:31:16 GMT

I received several requests about the modems comparisons, reviews and polls
article posted here a while ago. Since some have missed it, and one mail
bounced (Yes, you, P. Palais (?), your mail bounced), I am reposting this
informative and good article. So here you go again.

[begin article]
From: larry@gator.rn.com (Larry Snyder)
Subject: Re: Why is Supra able to sell?
Organization: The Gator Conferencing System 219-289-3745 
Date: Sun, 22 Nov 1992 22:16:49 GMT

bill@unixland.natick.ma.us (Bill Heiser) writes:

>What's the net opinion about the WORLDblazer?  Is it worth the extra money
>(to get the SuperPEP) over something like the T3000?

I say yes -- if you need to support PEP and v.32bis -- this
is the only modem for the job.  Now, if you don't need PEP
support, then by all means forget the WB.

TurboPEP regardless of what you've seen here, offers better
UUCP throughput on dialup lines over v.32bis.

-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry
From: robsch@robkaos.GUN.de (Robert Schien)
Newsgroups: comp.dcom.modems
Subject: Re: Any Digicom Scout+ bugs?
Date: 21 Nov 92 23:10:49 GMT
Organization: Private Site, Essen, Germany
X-Newsreader: TIN [version 1.1 PL7]


Well, after a ROM upgrade. My Digiscout+ works quite fine. I found only
the following effects:
When entering local mode from a working connection (you know the usual +++)
and entering AT*O (to see the line quality) and then ATO to get back
to the connection, ATO yields ERROR the first time. Entering another ATO
gives the desired result.
I had problems to connect to a Twincom BEFORE the ROM update.
My current ROM version (ATI1) is 2A09/2930. 
BTW, is someone faxing using a Digiscout+ under UNIX ? The problem
is that netfax is not working, because netfax requires Class 2 commands and
the Scout+ supports only Class 1.
But to summarize, the Scout+ is a very good modem.
-- 
Robert Schien    robsch@robkaos.GUN.de
"To err is human, to really foul things up requires a computer"
Newsgroups: comp.dcom.modems
From: m@crito.stanford.edu (M Carling)
Subject: Re: Worldblazer fax upgrade
Reply-To: mcarling@NetForce.com (M Carling)
Organization: DSO, Stanford University
Date: Thu, 19 Nov 92 01:42:29 GMT

In article <1992Nov17.022349.24791@uhura.neoucom.edu>  
wtm@uhura.neoucom.edu (Bill Mayhew) writes:
> I sure would be
> nice to have fax software available for a workstation system (Sun,
> DEC, HP, etc..), but that is probably daydreaming.

A fax driver for NeXT that supports T3000s and Worldblazers is under  
development.

M Carling
Director, Bay Area NeXT Group
General Manager, NetForce Inc. 
Newsgroups: comp.dcom.modems
From: kbass@gmuvax2.gmu.edu (Ken Bass)
Subject: Re: Info on: Infotel, Zoom, or Zyxel
Organization: George Mason University, Fairfax, Va.
Date: Thu, 19 Nov 1992 16:33:12 GMT

In article <of0I6dO00Uh_444ltZ@andrew.cmu.edu> Kwan-Ju Chen <kc2x+@andrew.cmu.edu> writes:
>I agree ZyXEL is a better modem.
>
>I dumped my SUPRA v32bis.
>
>

I agree. Dump a im Practicle Periph.

-- 
Ken Bass (kbass@gmuvax2.gmu.edu)              |   Telecommunications  
George Mason University                       |   Techniques Corp, 
Student, Department of Electrical Engineering |   Software Engineer 
Newsgroups: comp.dcom.modems
From: michel@vette.colorado.edu (Michel Lesoinne)
Subject: AT&T's 28,800
Reply-To: michel@vette.colorado.edu (Michel Lesoinne)
Organization: University of Colorado, Boulder
Date: Mon, 16 Nov 1992 09:10:05 GMT

Is that speed available on the 3820 by upgrade ? After all, the 3820 was quite expensive
and is upgradable through a simple phone call. If the answer is yes, I'll be happy I bought
an AT&T Paradyne. If it is no, I'll be sad for the rest of my days...

Michel
From: tnixon@hayes.com
Newsgroups: comp.dcom.modems
Subject: Re: ZyXEL: Fall Forward? Yes or No?
Date: 17 Nov 92 11:28:56 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Nov17.063557.22167@engr.uark.edu>, hbj@engr.uark.edu
(Bernard Johnson) writes: 

> geoff@zswamp.UUCP (Geoffrey Welsh) writes:
>>   *All* V.32bis modems must support fallback and fallforward requests.  
>>However, they are not obliged to honour them (i.e., they may refuse and insist 
>>on keeping the current speed), 
> 
> I really wouldn't call that supporting it then.  The way I understood the spec
> was that the modem was not required to initiate a fall{back/forward} but must
> honor one if requested by the connected modem.

No, Mr. Welsh is correct.  The standard requires a V.32bis modem 
that receives a rate renegotiation request to respond to that 
request.  The request includes a bitmap of speeds acceptable to the 
initiator (usually, the desired speed and all lower speeds); the
response includes a bitmap of speeds acceptable to the responder. 
These bitmaps are "ANDed" together.  If the result is 00000, the
call is disconnected.  If the result is non-zero, the speed changes 
to the highest speed in common between the those indicated by the 
initiator and those indicated by the responder.

There are several situations in which a responder might want to not 
accept a rate renegotiation: it might be receiving line noise not 
apparent to the initiator; it's DTE might be connected in plain old 
async mode (&Q0) without flow control, in which case speed changing 
is impossible; it might be a synchronous modem being externally 
clocked, in which case speed changing is also impossible.  The 
standard simply cannot require a modem to change speeds if it is 
impossible or inappropriate to do so.  All the standard can do is 
specify how it is done, but it must be left up to the modems, based 
on line conditions and application requirements, to decide whether 
or not a particular request will be accepted.

-- 
Toby Nixon, Principal Engineer      | Voice   +1-404-840-9200  Telex 401243420
Hayes Microcomputer Products, Inc.  | Fax     +1-404-447-0178  CIS   70271,404
P.O. Box 105203                     | BBS     +1-404-446-6336  AT&T    !tnixon
Atlanta, Georgia  30348             | UUCP uunet!hayes!tnixon  Fido   1:114/15
USA                                 | Internet                tnixon@hayes.com