HDTenEightyP/NetNews huggingface dataset:
From: binh@sequent.com (Binh Thai Vu)
Newsgroups: or.forsale
Subject: 86 CHEV S-10 BLAZER 4X4 FOR SALE
Date: 8 Apr 92 15:57:53 GMT
Article-I.D.: sequent.1992Apr8.155753.9863
Distribution: or
Organization: Sequent Computer Systems, Inc.

Engine type         : 2.8L V6 FI (recently tune-up carburator).

Transmission        : recently REBUILT with 12K mile warranty, AT with OD.

Tires               : 4 brand new Firestone.

Brakes              : recently done when bought tires.      

Mileage             : 75K (freeway trips).

Options             : Tahoe package with A/C, PS, C/C, tinted glass, tilt
                      steering wheel, rear defog, AM/FM stereo cassette...

Color               : light blue

Reason for sale     : home payment

Price               : asking $5,750 or best offer.

Please contact me at:

Binh T. Vu                            home: (503) 644-5616
Sequent Computer Systems, Inc.        work: (503) 578-3219
15450 S.W. Koll Parkway               email: binh@sequent.com
Beaverton, OR 97006
Xref: sparky or.forsale:812 pdx.forsale:1292 pnw.forsale:675
From: tmajni@sequent.com (Tim Majni)
Newsgroups: or.forsale,pdx.forsale,pnw.forsale,ba.forsale
Subject: JBL speakers for sale
Date: 7 Apr 92 00:04:05 GMT
Article-I.D.: sequent.1992Apr7.000405.26800
Organization: Sequent Computer Systems Inc.


JBL L250 speakers for sale.

    Excellent condition (no boxes)
    7 years old.
    Walnut finish.
    Tall: about 5 feet, triangular.
    Big sound: 4-way with 18" woofers.
    Sold new for $3000.

    Asking $900.

    Tim Majni
    home: 591-8221
    work: 578-5194
    email: tmajni@sequent.com
From: arnief@sail.LABS.TEK.COM (Arnie Frisch)
Newsgroups: or.forsale,tek.forsale
Subject: Misc. Camera Equipment for Sale
Keywords: Oldies but goodies
Date: 9 Apr 92 15:47:24 GMT
Article-I.D.: sail.11785
Followup-To: poster
Distribution: or
Organization: Tektronix Inc., Beaverton, Or.


Canon IVS2 35mm single window rangefinder camera, vintage 1953.
Interchangeable lenses (Leica mount), including 50mm f1.8 and 135mm f4
(with finder).  It works, and the optics and mechanics are very, very
good.  In excellent condition.  Best offer takes it.

Olympus Pen FT half frame 35mm single lense reflex with 40mm f1.4 lens,
through the lens metering, interchangeable lenses.  A little gem.  In
excellent condition.  Make offer.

Bolex 233 Super 8 movie camera with 9-30mm f1.9 varifocal lense in
original styrofoam packing and clip-on movie light, pistol grip, etc.
Make my day!

Arnie Frisch
627-7544 work
645-4566 home
Xref: sparky vmsnet.uucp:380 vmsnet.networks.tcp-ip.wintcp:98
From: msieweke@hayes.com
Newsgroups: vmsnet.uucp,vmsnet.networks.tcp-ip.wintcp
Subject: Re: help - forwarding mail from TCP/IP to uucp
Date: 8 Apr 92 15:54:14 GMT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Apr7.161138.1912@inland.com>, 
   allebrandi@inland.com (Tom Allebrandi) writes:
> 
> Have you tried this:
> 
> [OUTBOUND-FROM]
> wins%"*@*"	\001@hayes.com
> 

This is the [OUTBOUND-FROM] section of my rewrite rules:

wins%"*@*"              \001@hayes.com
WINS%"*@*"              \001@hayes.com
hayes1::wins%"*@*"      \001@hayes.com
HAYES1::WINS%"*@*"      \001@hayes.com
*@*                     \001
*::*                    \002

None of these have any obvious effect.  I may have to break down and
read the mail rewrite source code.  Thanks for the idea, though.
-- 
Mike Sieweke                            ...!uunet!hayes!msieweke
Hayes Microcomputer Products            msieweke@hayes.com
Norcross, Georgia                       hayes!msieweke@uunet.uu.net
"I've never seen so many people obsessed with the trivial!"
   - a co-worker after his first time reading news
Xref: sparky vmsnet.uucp:381 vmsnet.networks.tcp-ip.wintcp:100
Newsgroups: vmsnet.uucp,vmsnet.networks.tcp-ip.wintcp
Subject: Re: help - forwarding mail from TCP/IP to uucp
From: allebrandi@inland.com (Tom Allebrandi)
Date: 9 Apr 92 09:08:33 CST
Organization: Inland Steel Company; East Chicago, IN

In article <5442.29e31726@hayes.com>, msieweke@hayes.com writes:
> This is the [OUTBOUND-FROM] section of my rewrite rules:
> 
> wins%"*@*"              \001@hayes.com
> WINS%"*@*"              \001@hayes.com
> hayes1::wins%"*@*"      \001@hayes.com
> HAYES1::WINS%"*@*"      \001@hayes.com
> *@*                     \001
> *::*                    \002
> 
> None of these have any obvious effect.  I may have to break down and
> read the mail rewrite source code.  Thanks for the idea, though.


Are you running the latest version of the software? The code that
recognizes the presence of the foreign transport selector (wins%) is
supposed to be passing the entire from address to the rewriter. If it's
not doing that, it's a bug.

However, the code did not always do this. I thought I made it do this
in 1.2 but it might have been later.

Also, the rewriter downcases everything so you don't need the uppercase
forms. However, it seems to me that that was not always true and was
something that was fixed in later releases.

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | Chairperson - VMSnet Working Group, DECUS VAX SIG
East Chicago, IN           | Internet:  allebrandi@inland.com
219 399 6306               | UUCP:      ...!uunet!inland!allebrandi
                           | DECUServe: allebrandi
Newsgroups: vmsnet.uucp
From: gaeta@picker.com (Jay Gaeta)
Subject: Re: DECUS UUCP - New user questions
Organization: Picker International, Inc.
Date: Mon, 6 Apr 1992 16:39:24 GMT

In article <1992Apr1.200351.394@cmkrnl.com> jeh@cmkrnl.com writes:
>> My question: The throughput when communicating with a Unix system's uucp,
>> and T2500 modem is lower than what is typical in Unix-Unix communication.
>> I see rates of 1,000 - 1300 bytes/sec (either direction).  I am wondering
>> if there is anything I can do to improve the performance (tuning param,
>> modem register changes, etc.); I typically see 1800-2000 bytes/sec.
>
>I have never heard reports that a T2500 in PEP/uucp spoofing mode can achieve
>better than 1400 char/second.  The raw modulation rate is faster than that but
>1400 char/second is what you get in actual use.  If you are doing better,
>with ANY hosts, I and a whole lot of folks over in comp.dcom.modems would like 
>to hear about it.  

You are correct, my mistake...

>In other words... under what configuration are you seeing 1800-2000 char/sec?

The 1800-2000 char/sec figure was probably for small text files that fit
inside the various buffers along the way.  It looks better than it really
is.  Somehow those figures got stuck in my head, and in typical fashion,
I repeatedly tested the DECUS UUCP setup and not the Unix UUCP stuff.

I ran a quick test and it looks like the DECUS UUCP is at least as fast
as the Unix BNU set up here.  I was too quick to post a question.  Hope
I did not confuse anyone (besides myself that is). 

>One other comment -- if you are tempted to try V.32bis for greater throughput,
>beware line quality problems.  V.32bis seems to have a very slight edge over
>PEP -- with good-quality lines.  But almost everyone agrees that PEP will keep 
>moving data at respectable speeds under line conditions that make V.32bis fall
>flat on its face.  This is an important factor for your application -- 
>international calls.  

I have experimented with V.32bis, and I agree.  PEP works reliably with
international calls, V.32bis fails on occassion when a poor quality line
is obtained.  PEP fits our needs better.

>Try running MONITOR MODES while receiving and sending a few large files, and
>report the results.  (Naturally, with no other significant loads on the 
>system!  ie, don't let the VAXstation user rebuild that 10000-page TeX document
>while you're running the test...)
>

Some tweeking on this end gave us routinely 1385 chars/sec DECUS UUCP ->
BNU UUCP, and 1295 BNU UUCP -> DECUS UUCP.  On international calls it
varies between 550-650 chars/sec (it is about the same for DECUS UUCP as
for BNU UUCP).

I'll try a few more tests before moving on to other duties, but in general
I am satisfied that the performance I see is comparable to what you suggest
is typical.

Thanks for the reply, and the advice.  Thanks again for making the DECUS
UUCP package available to the rest of us.  Let me know if can be of help
to you sometime.

-- 
Jay Gaeta (216)-473-2441                   e-mail uucp:     uunet!picker!gaeta
Picker International, Inc.                 e-mail internet: gaeta@picker.com
595 Miner Rd, Highland Heights, OH  44143
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.uucp
Subject: Re: suggested minor fix to SYSDEP.C
Date: 8 Apr 92 09:46:09 GMT
Organization: Mitech Corporation, Concord MA

In article <1992Apr7.103429.11710@infocomm.com>, mark@infocomm.com writes:
> You wouldn't happen to be running over LAT connected terminals, and/or have
> VT's enabled. . .

VAXSTATION-2000 VMS 4.7, and yes, I do have SET TERM/DISCON/PERM on my TT line.

> Note, the routine that flushes the tty input was called directly from the
> routine that issues the hangup.  The call to sleep in the hangup routine
> remains since it was NOT the culprit.

OK. I may not have enough before/after testing to show that changing 
sleep to msleep really helped me. And even if it did help me you
obviously have a real understanding of what is really going on...
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.uucp
Subject: suggested minor fix to SYSDEP.C
Date: 7 Apr 92 09:11:39 GMT
Organization: Mitech Corporation, Concord MA

Here is a suggested small improvement to SYSDEP.C, which may have already
been done (I haven't seen the latest sources).

There are a couple calls to the VAXCRTL sleep function. It has been my
observation that under certain conditions (related to use of HIBER, AST's,
event flags, whatever) a sleep(6) can turn into something that never
wakes up. Maybe it is a bug that is only in my old VAXCRTL (VMS 4.7).

The bug manifested itself for me when sometimes when carrier is
lost during a file transfer a "Dropping DTR" turns into an indefinite sleep.

Anyway, I think that changing sleep(6) into msleep(6000) is a good idea
in any case, following what seems to be the general suggestion from DIGITAL
support people, to avoid the VAXCRTL whenever possible. 

-gjc
From: lhotka@abel.incstar.com
Newsgroups: vmsnet.uucp
Subject: Getting across DECnet from uucp
Date: 10 Apr 92 16:58:19 GMT
Article-I.D.: abel.2791.29e5c92b
Organization: INCSTAR Corp, Stillwater MN

I know, I know, you should never post in anger or frustration, but REALLY!!

For the past hour and a half I have been trying to get uucp to let me mail
across decnet by putting a wide variety of rewrite rules in the rewrite rules
file.  All to absolutely no avail...

I have a MVII running DECUS uucp - ABEL.

I have a 6410 connected by decnet - ADAM.

I try sending mail to uucp%"user@adam.incstar.com" and it is an invalid
Internet or uucp address - makes sense.

In the OUTBOUND-TO section I add a rule

	*@adam.incstar.com	adam::\001

This seems logical to me somehow, but gets me nowhere fast.  I assume I am
missing something really simple and easy here...  I have tried rules in other
areas and other forms, but nothing seems to matter.

We run MX as well - hence I never actually ran into this until I tried to
forward a message from ANU News which doesn't use MX to send mail apparently
and find that the uucp% mail system just doesn't appreciate my decnet
machine...

Sorry if this is a bit curt, it is frustrating...  Any help will be VERY
appreciated.  Thanks.

 Rockford Lhotka                                INCSTAR Corp
 Applications Project Leader                    1990 Industrial Blvd
 lhotka@incstar.com                             PO Box 285
 612/779-1701                                   Stillwater, MN 55082
           >>>Amiga - The computer for the creative mind<<<
Newsgroups: vmsnet.uucp
Subject: RE: uucico.exe with large pkt and window support
From: jeh@cmkrnl.com
Date: 5 Apr 92 22:14:09 PDT
Organization: Kernel Mode Consulting, San Diego CA

In article <1992Mar18.133717.375@cmkrnl.com>, jeh@cmkrnl.com writes:
> In article <00957B638EB20D60.21A01642@dallas.sil.org>, Dan McDonald <mcdonald@dallas.sil.org> writes:
>> [...]
>> I also have a "simple" question: What calculation do I make to determine how big 
>> TTY_ALTYPAHD should be.  I figured it would be b*w+fudge_factor, and so figured 
>> that with a TTY_ALTYPAHD of 2064 I could handle 256*7 = 1792 => cushion of 272 
>> ought to be plenty, but I started taking lots of errors when I had it that high 
>> - any clues as to what I am doing wrong?
> 
> You got *more* errors with a *larger* typeahead buffer?   Sounds like maybe
> the terminal driver isn't handling very big typeahead buffers well.  

Mr. McDonald wrote to me to tell me that they had always had the typeahead
buffer that high (since installation of All-in-One, though I'll be damned if I
can figure out why All-in-One should need a nonstandard typeahead buffer), that
the "more errors" was with larger packet and window sizes.  

I am coming to the conclusion that the VMS terminal driver just doesn't do very
well with large typeahead buffers -- at least not when large buffers are used
to any great degree.  

The thing that worries me the most about the reports I've gotten so far are 
the reports of accvio's *immediately upon startup* of uucico.exe, before much
data has been read or written.  I can't duplicate it here.  I even added some
code to "test" the first and last bytes of each buffer after it's allocated
(we allocate almost 20 buffers, all told), and this test passes fine.  

Since we are only about a month away from Spring Symposium time, which is when
we want the new release to be ready, I think I'm going to have to back out the
large packet/window extensions for the "production" code.  I will likely
include a second version of uucico, one which includes the large packet/window
extensions -- that way, if it doesn't work, people will still be able to run. 

But a full debugging of this code is not going to get done in the upcoming 
month!  I really won't be happy until I understand the accvio's -- just saying
"I can't duplicate them here" isn't sufficient.  

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protool guru, VMSnet (DECUS uucp) Working Group, and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh

"There's no security... where's the challenge?!?"  -- Bruce Ellis, _Stuck 
	Inside of Unix with the VMS Blues Again_
From: munroe@dmc.com (Dick Munroe)
Newsgroups: vmsnet.uucp
Subject: gclock ast's with new uucico.
Date: 8 Apr 92 07:31:58 EDT
Organization: Doyle Munroe Consultants, Inc., Hudson, MA

I have a problem with the new UUCICO.  More times than not when attempting to
connect to UUNET, I can't get through (it SELDOM fails when using the old
UUCICO).  When I attempt to force a connection I get:

Sending: 0x10 U g 0x00
QIO data/req: 80/68 rd: 132/23 rah: 12/47
07:23:00.73       rcv_ctl() xwmax set to 3
07:23:00.74       rcv_ctl() xbmax set to 64
07:23:01.01       rcv_ctl() xwmax set to 3
p:uucp => h:uunet   [04/08-07:23:01-000003cd]   Startup ok     (g, xmt w=3,
b=64
) u:SYSTEM
p:uucp >> h:uunet   [04/08-07:23:02-000003cd]   We want to send (S
D.thehulkA895
3 D.thehulkA8953 thehulk!uucp - D.thehulkA8953 0666 ) u:thehulk!uucp
07:23:07.43 1   * gclock_ast() tmo awtg ack of pkt
07:23:07.43 2   * gclock_ast() tmo awtg ack of pkt
07:23:12.43 1   * gclock_ast() tmo awtg ack of pkt
07:23:12.43 2   * gclock_ast() tmo awtg ack of pkt
07:23:17.43 1   * gclock_ast() tmo awtg ack of pkt
07:23:17.43 2   * gclock_ast() tmo awtg ack of pkt

And eventually the connection disconnects.

I switch to the old one and try again and it works just fine.

I'm running with altypahd=4096, maxbuf=8196, uunet to default since I'm running
TB+ modems and they always negotiate 3/64.

This doesn't ALWAYS happen, but it locked up my communication to uunet pretty
much all day yesterday.  I'll forward the log files to anybody who's
interested.
-- 
Dick Munroe				Internet: munroe@dmc.com
Doyle Munroe Consultants, Inc.		UUCP: ...uunet!thehulk!munroe
267 Cox St.				Office: (508) 568-1618
Hudson, Ma.				FAX: (508) 562-1133

GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection.
Newsgroups: vmsnet.uucp
Subject: Re: Problem with new uucico.
From: don@rata.vuw.ac.nz (Don Stokes)
Date: Wed, 8 Apr 1992 03:43:35 GMT
Organization: Victoria University of Wellington

jeh@cmkrnl.com writes:
> In article <00957C26.B49123E0.14574@infores.wha.ma.us>, Jim Carey <jcarey@infores.wha.ma.us> writes:
> > I tried the new uucico, with less than wonderful results (trimmed to fit):
> > p:uucp [03/17-13:41:06] * Other end not sndg (getdata tmo awtg rcvd data) u:-

Here's another report.  VAXstation II with DHV11, talking to an HP3000 
running HP/UX.  With window size set to 7 and packet size set to 128, all
is well.  If I change a packet size of 256, I get the above results.

I haven't given it a proper thrashing -- if/when I do, I'll report my 
findings.

--
Don Stokes, ZL2TNM (DS555)                      don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre          don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand.           +64-4-495-5052
From: andre@hern.stonemarche.org
Newsgroups: vmsnet.uucp
Subject: Re: gclock ast's with new uucico.
Date: 11 Apr 92 13:50:16 GMT
Article-I.D.: hern.1992Apr11.095017.1997
Organization: Hern the Hunter, Stonemarche (NH)

I, as well, now use the new uucico.
While I can get it to use a window size of 7,
I can't get it to let me use a buffer size of
greater than 64.  When I do, it hangs, and then times out.

Data:
VMS 	5.4
uucico	cmkrnl-x1.3b

					Andre'
-- 
andre@stonemarche.org				Andre' Wood
andre@hern.stonemarche.org			POBox 305,
...!dartvax!hern!andre				Greenfield, NH, 03047
...!uunet!{bytepb,virgin}!hern!andre
From: vaughan@sjh.org
Newsgroups: vmsnet.uucp
Subject: Re: UUCP and AT&T Mailers (Query)
Date: 8 Apr 92 18:46:39 GMT
Article-I.D.: sjh.1992Apr8.144639.549
Distribution: na
Organization: St. Joseph Hospital, Cheektowaga NY

In article <1992Apr7.161527.1913@inland.com>, allebrandi@inland.com (Tom Allebrandi) writes:
> In article <1992Mar31.231026.534@sjh.org>, vaughan@sjh.org writes:
>> -- 
>>   Has anyone gotten satisfactory comunications between Decus UUCP and
>> AT&T's nonsense PMX Mail or ATTMail?  I can do it, but their headers seem
>> to confuse both Decus UUCP and PMDF 4.0.  I end up without a host in the
>> return address from a neighboring host, but all is well if it is more than
>> one hop away.
>> 
> 
> A couple of years ago, there was a rumor that AT&T was about to release
> a version of UUCP Mail that violated the "no blank lines before the
> headers" rule. I never heard anymore about it so I never bothered to do
> anything about it.
> 
> Note that some [my opinion] misconfigured versions of MMDF generate
> blank lines before the headers....
One of my neighbors does this same behavior, maybe this is why?

> 
> Could this be the problem?
> 
Well I checked the headers on an AT&T machine using the PMX mailer, the headers
on that machine do not have a blank line.  I cannot say what happens to them
when the arrive in the spool directory, I can't _delete_ protect the spool
directory until maybe at night and trap the headers as they arrived.

Here is a sample of how they look: (an old one but the behavior is the same)

From:	UUCP%"mailroom" 16-JUL-1990 10:39:21.25
To:	sjhvax!vaughan
CC:	
Subj:	

Received: from h02924 by sjhvax.UUCP (DECUS UUCP w/Smail);
          Mon, 16 Jul 90 10:39:17 EDT
Message-Version: 2
>To: sjhvax!vaughan 
From: mailroom
Date: Mon Jul 16 10:32:20 EDT 1990
UA-Content-ID: <PMX-TERM-2.01-500270-h02924-mailroom-5>
End-of-Header: 
Email-Version: 2
UA-Message-ID: <PMX-TERM-2.01-h02924-mailroom-2>
To: sjhvax!vaughan
End-of-Protocol: 
Content-Type: multipart
Content-Length: 57482  


-- 
Internet: vaughan@sjh.ORG
UUCP    : ..!{ames!canisius,doh1c,sigmast,ub}!sjhvax!vaughan
SMSNET  : 40961::vaughan                
Where   : Tom Vaughan / Mgr. Comp. Ops./ St. Joseph Hospital /Cheektowaga N.Y.
--
Newsgroups: vmsnet.uucp
Subject: RE: Getting across DECnet from uucp
From: Dan McDonald <mcdonald@dallas.sil.org>
Date: Mon, 13 Apr 92 08:30:14 CST
Reply-To: vmsnet@DRYCAS.CLUB.CC.CMU.EDU
Organization: The Internet
Resent-From: vmsnet-request@DRYCAS.CLUB.CC.CMU.EDU
Resent-Date: Mon, 13 Apr 1992 10:16 EDT
Errors-To: vmsnet-request@DRYCAS.CLUB.CC.CMU.EDU
Resent-Message-Id: <01GISMXCM0DS000XLL@DRYCAS.CLUB.CC.CMU.EDU>
X-Vms-To: IN%"lhotka@abel.incstar.com", IN%"vmsnet@DRYCAS.CLUB.CC.CMU.EDU"
X-Vms-Mail-To: uucp%"vmsnet@DRYCAS.CLUB.CC.CMU.EDU"
X-Vms-Mail-Cc: UUCP%"lhotka@abel.incstar.com"

>For the past hour and a half I have been trying to get uucp to let me mail
>across decnet by putting a wide variety of rewrite rules in the rewrite rules
>file.  All to absolutely no avail...

I tried for a couple of weeks to get something similar to work here: no avail.  
My eventual solution was to stick a port from a un*x box on a terminal server, 
offer it as a LAT service, and let un*x route the "dial-up" uucp using MMDF.  I 
couldn't even come up with a way to establih similar LAT connections between 
VAXen to cut the un*x box completely out of the picture.

[...]
>In the OUTBOUND-TO section I add a rule
>
>	*@adam.incstar.com	adam::\001
>
>This seems logical to me somehow, but gets me nowhere fast.  I assume I am
>missing something really simple and easy here...  I have tried rules in other
>areas and other forms, but nothing seems to matter.

Try putting it in INBOUND-TO and adding .incstar.com to your map entry.  Tnat's 
as close as I ever got to making anything work here.  I think that actually 
formed the message, but I would end up with too many DECNET hops due to more 
forwarding on the distant end.

******************************************************************************
Dan McDonald                    * UUCP      ...utacfd!dalsil!mcdonald
Dallas Computer Services	* Internet  mcdonald@dallas.sil.org
Summer Institute of Linguistics *  - or -   danmc@txsil.lonestar.org
7500 W Camp Wisdom Rd           * SILnet    DAN.MCDONALD@A1@DALLAS
Dallas, TX 75236                * FAXnet    (214)709-3387
USA                             * POTSnet   (214)709-3389
******************************************************************************
x.400: C=US; ADMD=WESTERN UNION; O=SIL; DDA.ELN=62897168
      include "VMS MAIL: DAN.MCDONALD" in text for automated delivery :-(
maybesomedaynet: a:ATTMAIL; p:SIL; o:SIL; s:MCDONALD; g:DAN
******************************************************************************
Newsgroups: vmsnet.uucp
Subject: New uucico works here
From: n6vbg@debisa (Javier Henderson)
Date: 9 Apr 92 20:38:29 PST
Organization: What, me organized???

In lieu of all the problems people seem to be having with the new uucico,
I'd like to mention that I've been using it without any problems ever since
Jamie posted it.

Here are the particulars...

VAX 2000
VMS 5.4-1
UUCP 1.2b
TYPAHDSZ 1024
ALTYPAHDSZ 2048
w7b512

______________________________________________________________________________
Javier Henderson, N6VBG | Beat the 55mph limit...learn to fly!
n6vbg%debisa@mccall.com |