HDTenEightyP/NetNews huggingface dataset:
From: uucpmap@cowpas.waffle.atl.ga.us (USA-GA UUCP Mapping Project Coordinator)
Newsgroups: comp.mail.uucp
Subject: Re: problems with the UUCP maps--duplicate n
Date: Tue, 26 Jan 1993 08:46:55 GMT
Organization: COW Pastures
X-Newsreader: Tin 1.1 PL4

dawson@willard.atl.ga.us (Willard Dawson) writes:
: tep@engr.uark.edu (Tim Peoples) writes:
: 
: >    This all sounds like a great idea, but; I'm not sure how each of the
: > regional map coordinators handles map submissions.  Could they be able to
: > keep up with EACH of their map entries being resubmitted every month?
: > Maybe we should hear from one of them.  Any takers??
: 
: Automate, automate, automate.  We're talking "computers,"  right!?
: 
: Surely enough programmed map-record validation can be done to handle the
: process by now?  Or, do map moderators simply eye-ball new entries?

	I am quite sure that most map coordinators don't use any automation
at all.  I am investigating automation, but have not implemented it yet.

	A good guideline is that any map entry should be updated 6 to 12
months, even if it doesn't contain new information.  It gives the mapping
project coorindator an indication that your site is still alive.

	If you do have a change in connectivity, then it is always a good
idea to resubmit a new map entry as soon as possible.

	Here's how the process works.

	1.) New/updated map entries are collect, minor editing is done
	    (i.e., forgot tabs in entry, etc.)

	2.) cat them together into map files

	3.) UUCP/UUSEND/FTP them to rutgers.edu

	4.) Rutgers uses automation to check and see if the pathalias
	    data is correct.  and all nodes can be reached.

	5.) Map is shared, and posted to comp.mail.maps

-- 
Charles Stephens
USA-GA UUCP Mapping Project Coordinator
uucpmap@cowpas.waffle.atl.ga.us
From: dawson@willard.atl.ga.us (Willard Dawson)
Newsgroups: comp.mail.uucp
Subject: Re: problems with the UUCP maps--duplicate n
Date: Sat, 23 Jan 93 21:58:03 EST
Organization: Willard's House BBS, Atlanta, GA -- +1 (404) 664 8814

tep@engr.uark.edu (Tim Peoples) writes:

>    This all sounds like a great idea, but; I'm not sure how each of the
> regional map coordinators handles map submissions.  Could they be able to
> keep up with EACH of their map entries being resubmitted every month?
> Maybe we should hear from one of them.  Any takers??

Automate, automate, automate.  We're talking "computers,"  right!?

Surely enough programmed map-record validation can be done to handle the
process by now?  Or, do map moderators simply eye-ball new entries?

> +--------------------------------------+-------------------------------------
> | Tim Peoples                          | The time has come the hacker said   
> | tep@engr.uark.edu                    | to talk of many things,             
> | Dept. of Computer Systems Engineering| of simms and sockets and semaphores 
> | University of Arkansas, Fayetteville | of processes and pings....          
> +--------------------------------------+-------------------------------------
> |    I need no disclaimer; nobody listens to what I have to say anyway!!     
> +----------------------------------------------------------------------------
> 


-- 
dawson@willard.atl.ga.us (Willard Dawson)
gatech!vdbsan!willard!dawson
emory!uumind!willard!dawson
Willard's House BBS, Atlanta, GA -- +1 (404) 664 8814
Newsgroups: comp.mail.uucp
From: dave@revcan.rct.ca (David Blackwood)
Subject: Re: problems with the UUCP maps--duplicate node names
Organization: Revenue Canada, Taxation; Office Communications Division
Date: Thu, 28 Jan 1993 21:18:49 GMT

In article <C16D9K.pA@revcan.rct.ca> dave@revcan.rct.ca (David Blackwood) writes:
>Automatic expiry of map entries after a fixed period of time.  If you
>don't renew your map entry by resubmitting it at least annually then it
>simply gets dropped.  That may not solve the duplicate name problem but
>it would certainly go a long way toward eliminating non-existent and
>inactive sites.

Since I made the above comment, perhaps I should expand upon it.  By "a
fixed period of time" I didn't mean a month.  Six months, a year, or
even two years might not be unreasonable.  All map entries carry a
"modified on" date (#W) and an administrative e-mail address (#E).  A
simple shell script could generate an e-mail message to the
administrative address [5 | 11 | 23] months after the "modified on"
date to remind the administrator to submit a new map.  A similar shell
script could delete any entry that carries a "modified on" date of more
than [6 | 12 | 24] months ago.

Properly run sites should be reviewing and updating their map entries on
a semi-regular basis anyway.  Automatic expiry of entries should not
generate any more work for a coordinator than there should be already
and obviously the answer to the more work problem is greater automation.

Should we do it?  Driver's licenses do expire, even if you stop driving
and don't notify them.  House addresses also expire if the house no
longer exists (a map entry equates to a house not to a resident of that
house).  Would it solve the duplicate name problem - no.  Would it
improve mail connectivity - probably.

On the duplicate name issue, that could and should be resolved by the
map coordinators refusing to register a name that already exists in the
maps, not just in the #N line but anywhere in the connectivity
information as well.  (Perhaps connections to unregistered sites
shouldn't be permitted either).
-- 
D. J. Blackwood			Room 1139, 400 Cumberland Street
Systems Integration Manager	Ottawa, Ontario, Canada  K1A 0L8
Office Communications Division	voice: +1 613 957 9305, fax: +1 613 952 1095
Revenue Canada, Taxation	email: uunet.ca!revcan!dave, dave@revcan.rct.ca
From: ian@airs.com (Ian Lance Taylor)
Newsgroups: comp.mail.uucp
Subject: Re: Recursive UUX. Is it possible?
Date: 21 Jan 93 05:11:59 GMT
Organization: Infinity Development, Waltham, MA

alexz@glas.apc.org (Alex V. Zaytsev) writes:

>would anybody advise how to run recursive uux?  Is it possible
>at all?

>What I mean is that:

>uux -r - "$ourneighbor!uux $non_neighbor_system!$cmd" < $from-file ?

By default most implementations of UUCP will not permit remote systems
to execute uux.  If you can avoid that problem, then you need to know
that any arguments with exclamation points need to be parenthesized so
that they are not interpreted as remote file names.  You need
something like
    uux - $ourneighbor!uux '($non_neighbor_system!$cmd)' < $from_file

The next version (1.04) of Taylor UUCP will support
    uux - $ourneighbor!$non_neighbor_system!$cmd < $from_file
-- 
Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message:
`` `The world can grow into an ordered place where all are equal before
    the law.  And the law is just.  Honest.  Without graft.'
   `Is that so important if you are starving?' ''
From: thomas@mvac23.UUCP (Thomas Lapp)
Newsgroups: comp.mail.uucp
Subject: Re: More problems with the UUCP maps
Date: Wed, 20 Jan 93 22:09:29 EST
Organization: MultiVac23, Newark, DE, U.S.A.

fenner@postscript.cs.psu.edu (Bill Fenner) writes:

> Mail went into a black hole (no
> bounce, no warnings, no nothing):     62   (34%)
> 

In the case of mvac23, I have it set up so that it doesn't automatically
bounce messages which are addressed to non-existant accounts.  It goes
into a failure bin, which I check every so often and manually "fix",
since it is usually a munge of a good address.  So rather than
frustrating someone with a bounce, I try to get the mail delivered.
                         - tom
--
internet     : mvac23!thomas@udel.edu  or  thomas%mvac23@udel.edu (home)
             : lapp@cdhub1.dnet.dupont.com (work)
OSI          : C=US/A=MCI/S=LAPP/D=ID=4398613
uucp         : {ucbvax,mcvax,uunet}!udel!mvac23!thomas
Location     : Newark, DE, USA

Newsgroups: comp.mail.uucp
From: erik@til.com (Erik Horstkotte)
Subject: Re: problems with the UUCP maps--duplicate n
Reply-To: erik@til.com
Organization: Togai InfraLogic, Inc.
Date: Thu, 21 Jan 1993 19:19:02 GMT

In article pA@revcan.rct.ca, dave@revcan.rct.ca (David Blackwood) writes:
>Automatic expiry of map entries after a fixed period of time.  If you
>don't renew your map entry by resubmitting it at least annually then it
>simply gets dropped.  That may not solve the duplicate name problem but
>it would certainly go a long way toward eliminating non-existent and
>inactive sites.

I, for one, wouldn't have *any* problem with having to send a new map entry
in *monthly*.  After all, it's just a trivial cron job, and it would solve
the obsolete entry problem.
---
Erik Horstkotte, Togai InfraLogic, Inc.
The World's Source for Fuzzy Logic Solutions (The company, not me!)
erik@til.com, gordius!til!erik - (714) 975-8522
info@til.com for info, fuzzy-server@til.com for fuzzy mail-server
From: uucpmap@cowpas.waffle.atl.ga.us (USA-GA UUCP Mapping Project Coordinator)
Newsgroups: comp.mail.uucp
Subject: Re: problems with the UUCP maps--duplicate n
Date: Mon, 25 Jan 1993 02:28:06 GMT
Organization: COW Pastures
X-Newsreader: Tin 1.1 PL4

dawson@willard.atl.ga.us (Willard Dawson) writes:
: tep@engr.uark.edu (Tim Peoples) writes:
: 
: >    This all sounds like a great idea, but; I'm not sure how each of the
: > regional map coordinators handles map submissions.  Could they be able to
: > keep up with EACH of their map entries being resubmitted every month?
: > Maybe we should hear from one of them.  Any takers??
: 
: Automate, automate, automate.  We're talking "computers,"  right!?
: 
: Surely enough programmed map-record validation can be done to handle the
: process by now?  Or, do map moderators simply eye-ball new entries?

	I am quite sure that most map coordinators don't use any automation
at all.  I am investigating automation, but have not implemented it yet.

	A good guideline is that any map entry should be updated 6 to 12
months, even if it doesn't contain new information.  It gives the mapping
project coorindator an indication that your site is still alive.

	If you do have a change in connectivity, then it is always a good
idea to resubmit a new map entry as soon as possible.

Newsgroups: comp.mail.uucp
From: lytras@avalon.physik.unizh.ch (Apostolos Lytras)
Subject: Taylor UUCP and Ultrix 4.0 (!?)
Organization: Informatik Club d. Universitaet, Zuerich
Date: Sun, 24 Jan 1993 05:12:30 GMT

Hi

I tried to install Taylor UUCP (gamma 1.04) on our Ultrix 4 DECsystem,
which compiled fine (with a few warnings, but mostly not worrying ones).
However, when I try to run uucico (from a shell and as the shell invoked
by /bin/login), it exits before even saying "Shere". 

Can anyone point me to the problem (I already checked the docs and the
man pages)? Please answer by mail. Thanks.

- Apostolos

PS: I use ULTRIX_SPOOLDIR and TAYLOR_CONFIG, in case you were going to
    ask... AND the original uucp binaries are still where they are sup-
    posed to be... I have only incoming uucp connections, there is no
    dialing out to be handled.
-- 
Apostolos Lytras, Informatik Club der Uni Zuerich, Sys Admin
Internet: lytras@ifi.unizh.ch          |     lytras@avalon.physik.unizh.ch 
          lytras@amiga.physik.unizh.ch |        jab@ezinfo.vmsmail.ethz.ch
DECnet:   EZINFO::JAB                  |    PSI:      PSI%47931149412::JAB
From: Christophe.Wolfhugel@grasp.insa-lyon.fr (Christophe Wolfhugel)
Newsgroups: comp.mail.uucp
Subject: Re: problems with the UUCP maps--duplicate node names
Date: 26 Jan 1993 18:51:39 +0100
Organization: INSA Informatique (GRASP), Lyon, France
NNTP-Posting-Host: grasp1.univ-lyon1.fr

In article <H.8BlefaszZeQ@red.uucp> terry%red@lawton.lonestar.org writes:
>I for one am against renewing map addresses.  Its like applying for the same
>street address.  

Except that your house is probably not an annex of the post office, so
when you move snail-mail will continue to be delivered to others.

In the UUCP maps many non-existant, obsolete entries cause misrouting
of mail. Even without warnings as the error message from a misconfigured 
relay might get misrouted...

Perhaps this problem should be put in the "unsolvable ones" locker ?

-- 
Christophe Wolfhugel    |    Email: Christophe.Wolfhugel@grasp.insa-lyon.fr
Newsgroups: comp.mail.uucp,comp.os.linux,can.uucp,tor.uucp,ont.uucp
From: cfs@cowpas.waffle.atl.ga.us (Charles Stephens)
Subject: Re: Taylor UUCP and loss of carrier...
Organization: COW Pastures
Date: Thu, 28 Jan 1993 05:09:17 GMT
X-Newsreader: Tin 1.1 PL4

marc@r-node.pci.on.ca (Marc G Fournier) writes:
: Hi...
: 
: 	I have Taylor UUCP installed under Linux on my system and
: am having a problem with dropping carrier.  If my system is talking
: to another and, for some undetermined reason,  it drops carrier, and
: uucico doesn't seem to recognize it and just hangs.
: 
: 	I don't if it is a bug in linux still, or if it is something
: I'm missing in the config files or what...I've tried all the timeout
: variables that i can find, to no avail.
: 
: 	Ideas? Suggestions? Oh ya...the modem is a Telebit Worldblazer,
: Linux kernel 0.99pl4...taylor uucp...I'm not sure.

	THIS ONLY APPLIES TO "NEW STYLE TAYLOR" CONFIG FILES:  Add
the carrier true in the port file.  This should make Taylor see the 
CD change.

-- 
Charles Stephens
cfs@cowpas.waffle.atl.ga.us
"And they say USENET is worthless..."  --Unknown
Newsgroups: comp.mail.uucp
From: fenner@postscript.cs.psu.edu (Bill Fenner)
Subject: Re: More problems with the UUCP maps
Organization: Penn State Computer Science
Date: Mon, 25 Jan 1993 02:57:08 GMT

In article <1993Jan19.124933.1397@globv1.hacktic.nl> peter@globv1.hacktic.nl (Peter Busser) writes:
|The underlying assumption you made is that every mail package returns bounces
|when it can't find the addressed user. Are there any statistics that support
|this assumption?

No, I based it on my experience.  The only packages I've ever seen that do
not return bounces to the sender when they cannot find the user are MS-DOS
mailers.

|Such a postmaster probably wouldn't see the ``kicks'' and hit the
|"delete" key instead of the "bounce" key.

Well, I explained what the purpose of the mail was in the body of the message,
so if they were interested in contributing to the survey, they would send me
a message.  In fact, I got three manual bounces during the course of the
survey.

  Bill
From: barr@pop.psu.edu (David Barr)
Newsgroups: comp.mail.uucp
Subject: Re: problems with the UUCP maps--duplicate node names
Date: 26 Jan 93 15:10:33 GMT
Article-I.D.: atlantis.jv21H8_45c
Organization: Penn State Population Research Institute

In article <H.8BlefaszZeQ@red.uucp> terry%red@lawton.lonestar.org writes:
>This idea sounds good until you consider the amount of work involved.  How many
>sites are there?

About 20714, by my count.  Not that many, really.  I estimate a third of
these are bogus.

>  Each one of us placing a call on a map keeper.  I guess it 
>could be automated.  But then, so could checking for dupes.

	Duplicate entries are only a minor problem compared to the number
of sites that have since disappeard, with no one to tell the map project
that they left.

>I for one am against renewing map addresses.  Its like applying for the same 
>street address.  Geese.

It's not like that at all.  When you move and you get a new street address,
does your mail automatically all get forwarded there?  Does it really get
used for mail at all?  At least in the US, most people use the phone book
for addresses, not your county or postal records.  Your analogy is thin.

>  I don't even have to renew my drivers license more 
>than once every five years.

So?  And how accurate is the information on your driver's license?  My
current driver's license has had my address wrong for the majority of
the time I've had it.  In fact, I've gone through at least 4 address
changes during its lifetime.  Good thing I don't have to trust the
information on my driver's license for my mail.

>Then of course you have the problem of an administative error where a whole 
>block of map addresses get screwed up.

Where did this come from?  What's to stop this from happening now?
You're pulling arguments out of thin air.

>  I tell you, your proposal could become a night mare.

I'll clue you in.  It's already a nightmare.

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
A .sig quote is like a summer job, okay for a few months but not much more.
From: kherron@ms.uky.edu (Kenneth Herron)
Newsgroups: comp.mail.uucp
Subject: Re: Internet/Prodigy
Date: 26 Jan 93 16:29:09 GMT
Article-I.D.: ms.C1Gz4M.84p
Distribution: na
Organization: University Of Kentucky, Dept. of Math Sciences

joe@oldman.UUCP (Joseph P. Cain) writes:

>I am not sure if this is the correct newsgroup for my request but
>what I am looking for are internet users who are also on Prodigy
>who can forward mail to Prodigy addresses for me.

Considering that Prodigy charges a per-message fee for all messages
over x (30?) per month, you're not likely to find someone offering this
service.

>I am also looking for users who can relay mail to non computer
>persons by voice line in their area. This would be similar to a
>service currently provided by amateur radio traffic networks and
>would be pleasant to have available on internet. 

Geez.  Spend a buck and call the person yourself.  Most of us have
lives, you know.
-- 
Kenneth Herron                                            kherron@ms.uky.edu
University of Kentucky                                       +1 606 257 2975
Dept. of Mathematics "Your ball goes over them, it sails off the edge into a
huge cauldren of fire-breathing dragons."  "And they call this a par three?"
From: sjsobol@waffle.tiny.com (Steven J. Sobol)
Newsgroups: comp.mail.uucp
Subject: Re: problems with the UUCP maps--duplicate node names
Date: Fri, 22 Jan 93 17:03:32 EST
Organization: The Tiny Software Company, Cleveland, OH

dave@revcan.rct.ca (David Blackwood) writes:

> >Comments or suggestions?
> 
> Automatic expiry of map entries after a fixed period of time.  If you
> don't renew your map entry by resubmitting it at least annually then it
> simply gets dropped.  That may not solve the duplicate name problem but
> it would certainly go a long way toward eliminating non-existent and
> inactive sites.

But then there would be other map entries which reference a
now-nonexistent map entry.

I like the idea that if you don't send in a new entry every <x> months
you get deleted.


--

      The Tiny Software Company      Steve Sobol   sjsobol@tiny.com
              Computer operator down. Please call back later!
Newsgroups: comp.mail.uucp
From: uucpmap@cowpas.waffle.atl.ga.us (USA-GA UUCP Mapping Project Coordinator)
Subject: Re: problems with the UUCP maps--duplicate n
Organization: COW Pastures
Date: Tue, 26 Jan 1993 08:49:44 GMT
X-Newsreader: Tin 1.1 PL4

dawson@willard.atl.ga.us (Willard Dawson) writes:
: tep@engr.uark.edu (Tim Peoples) writes:
: 
: >    This all sounds like a great idea, but; I'm not sure how each of the
: > regional map coordinators handles map submissions.  Could they be able to
: > keep up with EACH of their map entries being resubmitted every month?
: > Maybe we should hear from one of them.  Any takers??
: 
: Automate, automate, automate.  We're talking "computers,"  right!?
: 
: Surely enough programmed map-record validation can be done to handle the
: process by now?  Or, do map moderators simply eye-ball new entries?

	I am quite sure that most map coordinators don't use any automation
at all.  I am investigating automation, but have not implemented it yet.

	A good guideline is that any map entry should be updated 6 to 12
months, even if it doesn't contain new information.  It gives the mapping
project coorindator an indication that your site is still alive.

	If you do have a change in connectivity, then it is always a good
idea to resubmit a new map entry as soon as possible.

	Here's how the process works.

	1.) New/updated map entries are collect, minor editing is done
	    (i.e., forgot tabs in entry, etc.)

	2.) cat them together into map files

	3.) UUCP/UUSEND/FTP them to rutgers.edu

	4.) Rutgers uses automation to check and see if the pathalias
	    data is correct.  and all nodes can be reached.

	5.) Map is shared, and posted to comp.mail.maps

-- 
Charles Stephens
USA-GA UUCP Mapping Project Coordinator
uucpmap@cowpas.waffle.atl.ga.us
From: jdb@erato.iowa-city.ia.us (John D. Boggs)
Newsgroups: comp.mail.uucp
Distribution: world
Subject: Re: problems with the UUCP maps--duplicate n
Date: Tue, 26 Jan 93 09:02:14 +0100

From article <1993Jan26.010957.28527@til.til.com>, by erik@til.com (Erik Horstkotte):
> To what extent can this entire
> procedure be automated?  To what extent are the current map entries checked
> by the rutgers team?  I suspect that they aren't checked at all.

I suspect that they are, because mine have come back with minor changes
in them (i.e. contact listed as postmaster@erato rather than jdb@erato).
From: wanderer@tcsi.appleton.mil.wi.us (K.T. Wieringa)
Subject: Re: problems with the UUCP maps--duplicate node names
Newsgroups: comp.mail.uucp
Distribution: world
X-Newsreader: TIN [version 1.1 PL6]
Date: 26 Jan 93 21:40:37 CST
Organization: The River

Terrence R. Redding (terry@red.uucp) wrote:
: In <93012110471@erato.iowa-city.ia.us>, John D. Boggs writes:
: >From article <C16D9K.pA@revcan.rct.ca>, by dave@revcan.rct.ca (David Blackwood):
: >> 
: >> Automatic expiry of map entries after a fixed period of time.  If you
: >> don't renew your map entry by resubmitting it at least annually then it
: >> simply gets dropped. 
: >
: >Hear hear!  I second the motion.  How do we get something like this
: >implemented?
: >
: This idea sounds good until you consider the amount of work involved.  How many
: sites are there?  Each one of us placing a call on a map keeper.  I guess it 
: could be automated.  But then, so could checking for dupes.
: 
: I for one am against renewing map addresses.  Its like applying for the same 
: street address.  Geese.  I don't even have to renew my drivers license more 
: than once every five years.


In V1.16d of Matt Dillons UUCP for Amiga we have a batch mail server
utility that does something like this.  

To use the server you have to register your site with the other site's BMS
server once (in this case -  submit a map entry).  This registration times 
out after a specified number of days but the bms utility generates a short
'still here' email message periodically until you either go down or manually 
terminate the connection.

Something along these lines might be considered.  

You might also try getting it to scan the log file to automatically pass an 
update on connections actually in use; config file to verify site and domain,
etc.

---
wanderer@tcsi.appleton.mil.wi.us

Xref: sparky comp.mail.uucp:2624 news.software.readers:2909 vmsnet.uucp:890
From: marc@r-node.pci.on.ca (Marc G Fournier)
Subject: Taylor UUCP and loss of carrier...
Organization: R-node Public Access Unix - 1 416 249 5366
Date: Tue, 26 Jan 1993 21:55:10 GMT

Hi...

	I have Taylor UUCP installed under Linux on my system and
am having a problem with dropping carrier.  If my system is talking
to another and, for some undetermined reason,  it drops carrier, and
uucico doesn't seem to recognize it and just hangs.

	I don't if it is a bug in linux still, or if it is something
I'm missing in the config files or what...I've tried all the timeout
variables that i can find, to no avail.

	Ideas? Suggestions? Oh ya...the modem is a Telebit Worldblazer,
Linux kernel 0.99pl4...taylor uucp...I'm not sure.

Thanks...

marc

-- 
Marc G. Fournier      | R-node Public Access Unix running Linux 0.99p4
Etobicoke, Ontario    | 416-249-5366   24hrs 7 days/week   network email
voice: 249-4230       | shell accounts       1600+ newsgroups       FREE
marc@r-node.pci.on.ca | Telebit WorldBlazer/SupraModem2400/Cardinal 2400 
Newsgroups: comp.mail.uucp