lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (08/29/89)
[ Followups are in news.admin ... ] I was going to bring this up a while ago, but thought "it's not that big of a problem." The following posting made me change my mind. In article <1989Aug21.124002.11054@robohack.uucp> woods@robohack.UUCP (Greg A. Woods) writes: >#N robohack [ ... ] ># NOTE: I've used DEDICATED to mean those sites who's mail is ># delivered immediately, and DIRECT for those queued 'til the next ># uudemon.hour run. It seems to me that everyone has assigned their own arbitrary definitions to DIRECT, DEMAND, HOURLY, etc., that bear no relation to the definitions in the README file posted to comp.mail.maps. In particular, everyone seems to use DIRECT when in fact they should be using HOURLY. I recently scanned through the Canadian maps, and found this to be the case for about 85% of the sites I am familiar with. It turns out that the "well connected" sites (using Gene Spafford's definition) are the most likely to be guilty of this practise. The result is, I'm starting to see some sub-optimal paths being generated. Take the case where 'a' and 'b' both claim DIRECT connections to 'c', and 'mysite' consider 'a' and 'b' to be HOURLY links. There is a 50% chance that pathalias will generate a route through either of 'a' or 'b' on the way to 'c'. As it turns out, the b!c link is a truly DIRECT connection, whereas a!c is in fact an HOURLY call. You get the idea ... As if that's not bad enough, I now find that on demand local calls are now weighted as DEDICATED. Does that mean that my 9600bps dedicated line between atha and aunro is actually a LOCAL+FAST link? Think about it ... -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA CTIX-USERS has moved to: ctix-users[-request]@cs.AthabascaU.CA
woods@robohack.uucp (Greg A. Woods) (08/29/89)
In article <1059@aurora.AthabascaU.CA> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: > [ Followups are in news.admin ... ] Which didn't work too well, I had to chop news.config from the Newsgroups line. :-) > I was going to bring this up a while ago, but thought "it's not that big > of a problem." The following posting made me change my mind. I nearly started a discussion on this topic a long while back (2 years or so) as well. > In article <1989Aug21.124002.11054@robohack.uucp> woods@robohack.UUCP (Greg A. Woods) writes: > >#N robohack > [ ... ] > ># NOTE: I've used DEDICATED to mean those sites who's mail is > ># delivered immediately, and DIRECT for those queued 'til the next > ># uudemon.hour run. > > It seems to me that everyone has assigned their own arbitrary > definitions to DIRECT, DEMAND, HOURLY, etc., that bear no relation > to the definitions in the README file posted to comp.mail.maps. > In particular, everyone seems to use DIRECT when in fact they > should be using HOURLY. I recently scanned through the > Canadian maps, and found this to be the case for about 85% of > the sites I am familiar with. It turns out that the "well connected" > sites (using Gene Spafford's definition) are the most likely to be > guilty of this practise. Most of my connections are what one would philosophically call DEMAND. I guess with respect to the README, they are DIRECT. First off, my uucp polling scheme has no concept of hourly (in the bigger picture). Second, with respect to mail delivery, my system will attempt to punch through on a tight polling schedule once work is queued to go. For the best rated sites this is every 20 mins. Remember that with HDB, work cannot be queued till the next regular poll (without adjusting the time field in Systems), but is only queued until the next run of uusched. If you look at my map entry, you will find one site labeled HOURLY, and that's 'cause they call me at least once per hour except from 9 to 5, but do not accept calls. In order to fudge my paths generation, I want some sites to be a bit less than DEMAND. Perhaps DAILY/4 or EVENING/2 or something would have been closer. The problem turns out to be a conflict between both the real world and the README, and between the README and smail2.5. I suppose I could change the #define in smail such that mail will only be queued with a cost of HOURLY or more (i.e. >=500), but that would also be misleading. All in all, I have achieved the desired result in my own pathalias output, and that's what counts, no? :-) > The result is, I'm starting to see some sub-optimal paths being > generated. Take the case where 'a' and 'b' both claim DIRECT > connections to 'c', and 'mysite' consider 'a' and 'b' to be HOURLY > links. There is a 50% chance that pathalias will generate a route > through either of 'a' or 'b' on the way to 'c'. As it turns out, > the b!c link is a truly DIRECT connection, whereas a!c is in fact > an HOURLY call. You get the idea ... Of course this would be easy if we all used the same definitions. However, what I'm saying, both here, and by explicitly commenting upon my actions in my map entry, is that the definitions are no longer sufficient. They are also very misleading, unless you also read the numbers. In fact, if you use the definition of cost: "measured very roughly in elapsed time"; the costs I have defined in my map are more than likely very nearly right, if not pessimistic, except for adjustments made manually to keep the load down on certain links. There have always been sub-optimal paths generated from the map data, no matter where you are, unless you connect to 1/2 the known universe. -- Greg A. Woods woods@{robohack,gate,tmsoft,ontmoh,utgpu,gpu.utcs.Toronto.EDU,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario; CANADA
mason@tmsoft.uucp (Dave Mason) (08/29/89)
In article <1989Aug29.130347.10673@robohack.uucp> woods@robohack writes: >also be misleading. All in all, I have achieved the desired result in >my own pathalias output, and that's what counts, no? :-) Not sure exactly what the smiley is for here, but you should tune your Path.local file (or whatever) to get the pathalias output you want. Your published maps should reflect the real costs, downgraded perhaps to avoid paths you don't want the whole world to use. (I.e. if I did lots of work with Australia I might have: tmsoft munnari(DIRECT) in my Path.local file, but tmsoft munnari(HOURLY*2) in my published map entry, because I don't want all North American and European traffic siphoned off through my site, though I might be willing to carry a bit of local traffic bound that way). ../Dave (Disclaimer: I do not have any real or imagined link to munnari, so don't go & change your routing tables :-)
kls@ditka.UUCP (Karl Swartz) (08/31/89)
In article <1059@aurora.AthabascaU.CA> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: >># NOTE: I've used DEDICATED to mean those sites who's mail is >># delivered immediately, and DIRECT for those queued 'til the next >># uudemon.hour run. >It seems to me that everyone has assigned their own arbitrary >definitions to DIRECT, DEMAND, HOURLY, etc., that bear no relation >to the definitions in the README file posted to comp.mail.maps. >It turns out that the "well connected" >sites (using Gene Spafford's definition) are the most likely to be >guilty of this practise. Perhaps the worst offender of all, in view of its number of links, is uunet. I posted something about this a while back; they list nearly all their links as DEMAND when in fact this bears very little resemblence to reality -- I know of several sites whose connections from uunet are listed as DEMAND yet they poll uunet once a night, at best. Rick Adams' reply: "DEMAND indicates a high quality, reliable path through which the receiving site wants to receive a lot of traffic." For nearly everybody else that I know of it indicates a reasonable degree of expediency, which certainly doesn't match a once-nightly poll. You'd think a site like uunet (and the other well-connected sites) would try to set a *good* example, not a bad one. Rick also said that sites are ALL (Rick's emphasis) told that they will be marked as DEMAND the request otherwise. For one thing, this is a really poor default, and for another, when I asked the postmasters of several sites that had recently gotten uunet links neither one of them had been told anything about map costs. As I said in my earlier article, I'm not trying to pick on uunet, but I think in this case they are very wrong. (Note to fellow map tinkerers: you can't get away with tossing a simple 'dead {uunet}' or 'adjust {uunet(EVENING)}' in your local pathalias input since most international links will then try to go thru obscure backdoor paths.) >As if that's not bad enough, I now find that on demand local calls >are now weighted as DEDICATED. Does that mean that my 9600bps dedicated >line between atha and aunro is actually a LOCAL+FAST link? I still use PC Pursuit for some connections. Since I don't use PC Pursuit for anything other than uucp perhaps I should mark all those links as DEDICATED. 8-) -- Karl Swartz |UUCP uunet!lll-winken!ames!hc!rt1!ditka!kls 1-505/667-7777 (work) |Internet kls@rt1.lanl.gov 1-505/672-3113 (home) |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
kls@ditka.UUCP (Karl Swartz) (09/02/89)
In article <1989Aug29.130347.10673@robohack.uucp> woods@robohack.UUCP (Greg A. Woods) writes: >I suppose I could change the #define in smail such that mail will only >be queued with a cost of HOURLY or more (i.e. >=500), but that would >also be misleading. Why would that be misleading? That's what I've done here on ditka and it works just fine. Ditka's actions follow what one would expect from the map data given the published cost definitions (and not some I made up). How might that be misleading? >All in all, I have achieved the desired result in >my own pathalias output, and that's what counts, no? :-) Not if you screw up other sites in the process. >They are also very misleading, unless you also read the numbers. For some values, yes. HOURLY does not strike me as begin rougly four times as fast as EVENING, for example. But for the lower costs the values seem fairly reasonable to me. >In fact, if you use the definition of cost: "measured very >roughly in elapsed time"; the costs I have defined in my map are more >than likely very nearly right Nonsense. Quite a few sites (properly) use DEDICATED for links over the Internet. By your (mis) use of DEDICATED to represent on-demand dial up links are you suggesting that these are as fast as a leased T1 or similar line? With the possible exception of some extremely slow cases it just isn't so. >There have always been sub-optimal paths generated from the map data, >no matter where you are, unless you connect to 1/2 the known universe. Is that supposed to be an excuse for doing your part to make the situation even worse than it already is? -- Karl Swartz |UUCP uunet!lll-winken!ames!hc!rt1!ditka!kls 1-505/667-7777 (work) |Internet kls@rt1.lanl.gov 1-505/672-3113 (home) |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
cme@cloud9.Stratus.COM (Carl Ellison) (09/05/89)
re. DEDICATED, DIRECT, HOURLY, POLLED, .... It sure does seem ad hoc. Has anyone considered enriching the format definition to include floating point numbers = the number of hours an incoming message could expect to wait before being handed on to the next machine? This could live alongside the current ad hoc English words until they die out. Meanwhile, the actual expected wait time could be measured on each machine and updated measurements provided with every map update -- or triggering a map update if there's a radical change. --Carl Ellison UUCP:: cme@cloud9.Stratus.COM SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752 Disclaimer:: (of course)
woods@robohack.uucp (Greg A. Woods) (09/06/89)
[ I apologize in advance for the amount of quoting in this article, but there's a fair bit of mis-information in this discussion, and I want to make it clear who is saying what. ] In article <3924@ditka.UUCP> kls@ditka.UUCP (Karl Swartz) writes: > In article <1989Aug29.130347.10673@robohack.uucp> woods@robohack.UUCP (That's ME!) writes: > > I suppose I could change the #define in smail such that mail will only > > be queued with a cost of HOURLY or more (i.e. >=500), but that would > > also be misleading. > > Why would that be misleading? That's what I've done here on ditka > and it works just fine. Ditka's actions follow what one would > expect from the map data given the published cost definitions (and > not some I made up). How might that be misleading? What would (is) be misleading would be (is) the fact that the behavior of my (your) smail does not reflect my (your) declared 'costs'. In my case it's misleading anyway, because of the way I schedule uucp jobs to try every 20 minutes best case, and every 40 minutes worst case. (HDB uucp, with retry times between 10 and 30 minutes, and with uusched running every 20 minutes.) (I've already said this, but it didn't seem to sink in.) I am collecting some data in order to graph the throughput of my system. At any rate, I think I've made a fair guess as to the through-put and capacity of my system. > > All in all, I have achieved the desired result in > > my own pathalias output, and that's what counts, no? :-) > > Not if you screw up other sites in the process. I haven't screwed up anyone, except perhaps myself. Should I declare a connection between two well connected, commonly used sites, my wee 2400 bps. modem might just get swamped. > > They are also very misleading, unless you also read the numbers. > > For some values, yes. HOURLY does not strike me as begin rougly > four times as fast as EVENING, for example. But for the lower > costs the values seem fairly reasonable to me. > > > In fact, if you use the definition of cost: "measured very > > roughly in elapsed time"; the costs I have defined in my map are more > > than likely very nearly right > > Nonsense. Quite a few sites (properly) use DEDICATED for links > over the Internet. By your (mis) use of DEDICATED to represent > on-demand dial up links are you suggesting that these are as > fast as a leased T1 or similar line? With the possible exception > of some extremely slow cases it just isn't so. If you'd read the README, you'd find the costs have been artificially increased by a large factor to account for an assumed delay in setting up a connection. The cost has very little to do with transmission speeds, as you'd know if you had noted the adjustments made by HIGH, LOW, and FAST are almost insignificant. In my case the "cost" (in terms of time delayed) of setting up a connection is actually quite low. Of course when the cost of making a connection drops to nil (as I believe it will in the future), as well as the increasing volume of traffic we will no doubt experience, the speed of transmission will become one of the major factors in determining route costs. By this time the routing will hopefully be a function of the network, not the transfer agent. I've made a _very_ rough guess as to the average elapsed time when mailing through my system. I will continue to adjust my published costs published as further statistics are available, since my modem usage will continue to vary in the future. I have taken a stand in this issue by publishing my map with an explanation of my actions. I had hoped this would provoke a discussion, as it indeed has. I hope the final result will be a re-evaluation of the definition of costs for published connections. (Are you listening Peter (assuming you still have interests in pathalias)?) The networks now in use, and the vast increase in numbers of point to point connections, not to mention the order of magnitude increase in sites, paints a dramatically different picture of "USENET" than was envisioned only a few years ago. -- Greg A. Woods woods@{robohack,gate,tmsoft,ontmoh,utgpu,gpu.utcs.Toronto.EDU,utorgpu.BITNET} +1-416-443-1734 [h] +1-416-595-5425 [w] Toronto, Ontario; CANADA
cme@cloud9.Stratus.COM (Carl Ellison) (09/08/89)
In article <6064@ficc.uu.net>, sms@ficc.uu.net (Stanley M. Sutton) writes: > Why not just use minutes? Integers are easier to track than floating. Integers are OK, but you'd probably want 1 second resolution rather than minutes. I've seen some hops take only seconds according to the routing histories I've read. > However, the mean time for transfer may not be as useful as some of the > terms, if they are consitently used. You'll have a hard time convincing me of that. The words convey only the frequency of outgoing calls from which mean waiting time is inferred. Routing decisions care only about waiting time. The words are few and therefore, the quantification of waiting times is gross. If there's some reason to make measured waiting times more coarsely quantified, that can be done numerically. If a system administrator wants to lie about connectivity, s/he can do so as easily with numbers as with words. If the desire is to tell the truth, then a real measurement sure beats a numerical guess followed by a guess of a word to match the guessed number. --Carl Ellison UUCP:: cme@cloud9.Stratus.COM SNail:: Stratus Computer; 55 Fairbanks Blvd.; Marlborough MA 01752 Disclaimer:: (of course)
karl@ficc.uu.net (Karl Lehenbauer) (09/08/89)
In article <3872@ditka.UUCP>, kls@ditka.UUCP (Karl Swartz) writes: > Perhaps the worst offender of all, in view of its number of links, > is uunet. I posted something about this a while back; they list > nearly all their links as DEMAND when in fact this bears very > little resemblence to reality -- I know of several sites whose > connections from uunet are listed as DEMAND yet they poll uunet > once a night, at best. One thing about uunet trying to list all of its uucp neighbors with the same value, from fooling around with different values for the link between sugar and uunet and running them through pathalias, if the link is substantially downgraded, you end up generating routes to uunet that are not direct from your site to uunet. uunet could end up routing stuff to you indirectly as well, if they allow that condition to occur. (They will honor a site's request for a value other than DEMAND) Now you might say that's the way it should be, but for a subscriber service like uunet, it is desirable that their customers connect directly, hence paying their own way. -- -- uunet!ficc!karl "Have you debugged your wolf today?"
kls@ditka.UUCP (Karl Swartz) (09/10/89)
In article <6093@ficc.uu.net> karl@ficc.uu.net (Karl Lehenbauer) writes: >One thing about uunet trying to list all of its uucp neighbors with the same >value ... if the link is substantially >downgraded, you end up generating routes to uunet that are not direct from >your site to uunet. That makes perfect sense. It even makes *some* sense that the cost is fairly low, since folks with uunet connections probably want their mail to come that way instead of via backroads. The trouble is that it also affects paths to non-subscribers. I would certainly object if one of my neighbors had a uunet link, marked as DEMAND but only polled every night or so, and consequently caused a great deal of *my* mail to be delayed. The solution to this is simple: the default should be a term- inal link, e.g. uunet <subscriber>(DEMAND) The subscriber encourages mail via the uunet without causing any backup for neighbors for whom better paths really exist and who *want* those better paths to be used. -- Karl Swartz |UUCP {ames,lll-winken}!pacbell!ditka!kls 1-505/672-3113 |Internet kls@rt1.lanl.gov |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
chip@ateng.com (Chip Salzenberg) (09/12/89)
According to kls@ditka.UUCP (Karl Swartz): >The solution to this is simple: the default should be a term- >inal link, e.g. > uunet <subscriber>(DEMAND) This would be a good solution, except that it doesn't work. If sites that have registered domain names -- like this one -- advertise a terminal link from uunet to the domain gateway, then only mail to the gateway will be delivered via that link. All mail to subdomains will go via some other route. Take us for example: uunet ateng(DEMAND) ateng .ateng.com Now mail to `user@border.ateng.com' is delivered via uunet. But if we do: uunet <ateng>(DEMAND) ateng .ateng.com then mail to `user@ateng.uucp' is delivered via uunet; but mail to `user@border.ateng.com' goes via Podunk. -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg at A T Engineering; <chip@ateng.com> or <uunet!ateng!chip> "If you push something hard enough, it will fall over." -- Fudd's First Law of Opposition
lyndon@auvax.uucp (Lyndon Nerenberg) (09/12/89)
woods@robohack.uucp (Greg A. Woods) writes: >I have taken a stand in this issue by publishing my map with an >explanation of my actions. I had hoped this would provoke a >discussion, as it indeed has. I hope the final result will be a >re-evaluation of the definition of costs for published connections. >(Are you listening Peter (assuming you still have interests in >pathalias)?) What I think we are all starting to agree on is that the labels currently in use don't reflect reality. My argument is that perhaps the idea of labels should be scrapped, and real numbers used instead. What these numbers represent is what must be decided. As I've said before, I think there are two likely candidates: the cost per kilobyte to send over the link, or the average delay to deliver a message over the hop (including time spent in the queue waiting for a poll). The more I think about this, the more I'm inclined to favour the later method, since sites worried about costs probably won't publish any links that they consider expensive. Since "expensive" is in the eye of the beholder (or the nearest bean counter), the cost per Kbyte weighting becomes meaningless. What's to say we can't start expressing site weightings in average minutes to deliver? With the cooperation of the mapping project, the existing maps could be converted based upon an agreed upon mapping to the new system (e.g. HOURLY -> 60, DIRECT -> 30, ...) [No flames on the EXAMPLE conversion, please :-) We can work that out later. ] Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA CTIX-USERS has moved to: ctix-users[-request]@cs.AthabascaU.CA
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (09/12/89)
[ note followups are pointed at news.admin ] sms@ficc.uu.net (Stanley M. Sutton) writes: >However, the mean time for transfer may not be as useful as some of the >terms, if they are consitently used. I.E., once a day would be a mean >time of 720 minutes for random calls, but someone who called in 10 mins >before the forward every day would only see a 10 min delay. When the >software at the site caluclates the mean time, how should it do it? >Worst case or calculated? What you're publishing is the average time for YOUR site to deliver to the next hop. When someone else calls you isn't really under your control. (What if he misses that poll? Is it then a 70? or a 35? or a ...) There are scripts available that provide calculated map weightings based on the uucp log information. They could be converted to the new system easily enough. The question is: will this feedback into the map postings induce self-oscillation? [ Death of net predicted :-) ] -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA CTIX-USERS has moved to: ctix-users[-request]@cs.AthabascaU.CA
dan@ccnysci.UUCP (Dan Schlitt) (09/12/89)
In article <1090@aurora.AthabascaU.CA> lyndon@auvax.uucp (Lyndon Nerenberg) writes: > >What I think we are all starting to agree on is that the labels currently >in use don't reflect reality. My argument is that perhaps the idea of >labels should be scrapped, and real numbers used instead. What these >numbers represent is what must be decided. As I've said before, I think >there are two likely candidates: the cost per kilobyte to send over the >link, or the average delay to deliver a message over the hop (including >time spent in the queue waiting for a poll). It has been a while since I looked so my memory may be failing me, but I thought those labels were numbers. Like in #include DEMAND nnn and that you could just use numbers if you like or adjust them by adding or subtracting defined fiddle-factors. Since any monotonic sequence can be mapped into any other in a unique way, it seems that the real argument is about the factors which should be used to determine the relative weights for the links. Two such factors are mentioned above but there are others such as reliability of the link which you might want to consider. It seems that the previously agreed upon factors are nolonger agreed to and that with the increase rerouters and internet links they may not be relevant. What is needed is an agreement about the factors. The current small integers which underlie the current system are quite adequate to carry out the agreement once it is reached. But remember that we are talking about a uucp network --- there aren't any RFCs and there is no cenralized authority to enforce decisions --- so any agreement will continue to depend on the authors of the individual map entries just like it does now. -- Dan Schlitt Manager, Science Division Computer Facility dan@sci.ccny.cuny.edu City College of New York dan@ccnysci.uucp New York, NY 10031 dan@ccnysci.bitnet (212)690-6868
cme@cloud9.Stratus.COM (Carl Ellison) (09/12/89)
In article <1091@aurora.AthabascaU.CA>, lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: > > Why not integer minutes? Saves a new version of the software. Integer minutes is fine. It gives some granularity, OK for phone line hops, a little coarse for internet. The important thing, to me, is that all these numbers be actually measured rather than merely be guesses by the site administrator.
bdb@becker.UUCP (Bruce Becker) (09/12/89)
In article <1092@aurora.AthabascaU.CA> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: |[...] |There are scripts available that provide calculated map weightings based |on the uucp log information. They could be converted to the new system |easily enough. The question is: will this feedback into the map postings |induce self-oscillation? [ Death of net predicted :-) ] I was wondering my self about cyclic behavior of such systems. It's fairly likely to occur, so a method of tuning is needed. Perhaps the output weightings could be calculated with reference to a "suggested" value (i.e. DIRECT, DAILY, etc), with the tuning parameter to be the ratio of suggested to log data or something analagous... Where are such scripts? I'd be willing to mess with this if I didn't have to start from scratch... Cheers, -- \__/ Bruce Becker Toronto, Ont. w \@@/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/~/-e BitNet: BECKER@HUMBER.BITNET _< \_ Happiness is a warm gnu, yes it is - R. M. Soulman
lyndon@auvax.uucp (Lyndon Nerenberg) (09/20/89)
cme@cloud9.Stratus.COM (Carl Ellison) writes: >Integer minutes is fine. It gives some granularity, OK for phone line hops, >a little coarse for internet. My understanding is that Internet sites are not supposed to be passing UUCP "through traffic" from or to non-Internet sites. >The important thing, to me, is that all these numbers be actually measured >rather than merely be guesses by the site administrator. It already exists. Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA "I think every man should have a wife. You can't blame everything on the government." -- Jed Clampett
lyndon@auvax.uucp (Lyndon Nerenberg) (09/20/89)
bdb@becker.UUCP (Bruce Becker) writes: > Where are such scripts? I'd be willing to mess with > this if I didn't have to start from scratch... I've got this stuff sitting on a tape (somewhere). If anyone wants a copy, drop me a line. The code wasn't too polished, so it will need some cleaning up. I think it's specific to "old" uucp logfile formats. Modifications will be necessary for HDB and 4.3 uucp. [ Use the sig address - aurthanc's NNTP is generating bogus headers ... ] Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA "I think every man should have a wife. You can't blame everything on the government." -- Jed Clampett