🚀 go-pugleaf

In article <1989May6.220422.126@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes:
>It's been more than 24 hours since last was heard from attcan. It hasn't
>called here, and doesn't answer the phone when we call.
>
>Is it just telly, or have others had the same problem?

ncrcan has not heard from attcan since 11:40 am this morning (Saturday).
We have also not successfully contacted them since even earlier.

It's not just your problem, Evan.

Brian.


-- 
 +-------------------+--------------------------------------------------------+
 | Brian Onn         | UUCP:..!{uunet!attcan, watmath!utai}!lsuc!ncrcan!brian |
 | NCR Canada Ltd.   | INTERNET: Brian.Onn@Toronto.NCR.COM                    |
 +-------------------+--------------------------------------------------------+

In article <1989May6.220422.126@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes:
>It's been more than 24 hours since last was heard from attcan. It hasn't
>called here, and doesn't answer the phone when we call.
>
>Is it just telly, or have others had the same problem?

We're seeing the same thing.  Looks like they're down.
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

In article <1989May7.041643.29194@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <1989May6.220422.126@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes:
		^^^^^ [ed. note: are these article id's really necessary??
I mean, why is it necessary to encode the date in the ID?.  With the DNS and 
C news and rn, followup "In article..." messages never fit on one line 
anymore.  IMHO, it looks bad.]

>>It's been more than 24 hours since last was heard from attcan. It hasn't
>>called here, and doesn't answer the phone when we call.
>>
>>Is it just telly, or have others had the same problem?
>
>We're seeing the same thing.  Looks like they're down.

Is there not a redundant full feed into the Toronto area?  I thought that
both attcan and jarvis were bringing news in, and that most of the major
sites were exchanging news with each other. Why must the news stop when
attcan has problems?  Or is it that this is what ideally we would like
to have (ie the Toronto netnews reorganization).  What sort of progress
was made with this, anyways.   I know that ncrcan offered to be a major
player in it, but heard nothing back from anyone.

Brian.

-- 
 +-------------------+--------------------------------------------------------+
 | Brian Onn         | UUCP:..!{uunet!attcan, watmath!utai}!lsuc!ncrcan!brian |
 | NCR Canada Ltd.   | INTERNET: Brian.Onn@Toronto.NCR.COM                    |
 +-------------------+--------------------------------------------------------+

In article <1989May7.041643.29194@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> In article <1989May6.220422.126@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes:
> >It's been more than 24 hours since last was heard from attcan. It hasn't
> >called here, and doesn't answer the phone when we call.
> >
> >Is it just telly, or have others had the same problem?
> > We're seeing the same thing.  Looks like they're down.

Yes, attcan was down for a quick upgrade (details to follow) that
was complicated by an air conditioning problem in our Computer Room.
However, as of the wee hours of this morning (ie Sunday), attcan
was back to normal and/or better than before :-)

No mail or news should have been lost as a result of this downtime,
but just slightly delayed. 

We do however, have a new phone number for our slow (ie 2400 baud)
modems, though the high-speed numbers haven't changed.  I will be sending out
an e-mail to the system administrators of all our USENET neighbours listing our
current numbers, and had already confirmed the change with our few low speed
neighbours.

Downstream sites should expect quite a number of Megabytes today and
tomorrow as the flow of news gets back to normal.

Please call me if you have any questions or notice any glitches.  Thanks.

Regards,
	Bob
-- 
Bob Kyryliuk				PHONE:	(416) 756-5183
Manager, Special Projects		
National Technical Support		AT&T MAIL: ..!attmail!bkyryliuk
AT&T Canada Inc.			UUCP:{att|cuuxb|uunet|utzoo}!attcan!bob

In article <1389@ncrcan.Toronto.NCR.COM>
	   brian@ncrcan.Toronto.NCR.COM (Brian Onn) writes:
>In article <1989May7.041643.29194@utzoo.uucp>
>			     henry@utzoo.uucp (Henry Spencer) writes:
>>In article <1989May6.220422.126@telly.on.ca>
>>			     evan@telly.on.ca (Evan Leibovitch) writes:
>		^^^^^ [ed. note: are these article id's really necessary??
>I mean, why is it necessary to encode the date in the ID?. ... ]

C news generates longish Message-IDs because I didn't want to have a
sequence-number file, which can get truncated by a crash during
updating, and because Message-IDs are currently generated by a shell
script.  The current date and time combined with the shell's process id
(the last number before the "@") should keep Message-IDs unique.
Without the date, time or process-id, Message-IDs could collide.

However, there are reasons other than aesthetics for preferring short
Message-IDs, including limitations in dbm(3) on total key and data
lengths per block.  Furthermore, RFC 1036 (nee 850) only requires that
messages be unique for two years.  One could omit high-order digits of
the year or encode the information more compactly, perhaps printing
integers in radix 64 (e.g. <1989May7.041643.29194@utzoo.uucp> could be
expressed as <!e9`nl()+@utzoo.uucp>, saving 12 characters).
-- 
Geoff Collyer	utzoo!utstat!geoff, geoff@utstat.toronto.edu
It's all Henry's fault. (TM)

In article <1989May8.071129.19925@utstat.uucp>
			geoff@utstat.uucp (Geoff Collyer) writes:
>C news generates longish Message-IDs because I didn't want to have a
>sequence-number file, which can get truncated by a crash during
>updating, and because Message-IDs are currently generated by a shell
>script.  The current date and time combined with the shell's process id
>(the last number before the "@") should keep Message-IDs unique.
>Without the date, time or process-id, Message-IDs could collide.

Ok.. I can accept the attempt to eliminate corruption in the event
of a crash.

>However, there are reasons other than aesthetics for preferring short
>Message-IDs, including limitations in dbm(3) on total key and data
>lengths per block.  Furthermore, RFC 1036 (nee 850) only requires that
>messages be unique for two years.  One could omit high-order digits of
>the year or encode the information more compactly, perhaps printing
>integers in radix 64 (e.g. <1989May7.041643.29194@utzoo.uucp> could be
>expressed as <!e9`nl()+@utzoo.uucp>, saving 12 characters).

True, but utterly gross!  I believe that andrew.cmu.edu does something
like this.  Ok, I'll retract.  Stick with the longish, yet unique, 
and still yet readable, Message-Ids.  I'll start splitting the 
"In article.." lines into two, as you subtely suggested. 

Thanks,
	Brian.
-- 
 +-------------------+--------------------------------------------------------+
 | Brian Onn         | UUCP:..!{uunet!attcan, watmath!utai}!lsuc!ncrcan!brian |
 | NCR Canada Ltd.   | INTERNET: Brian.Onn@Toronto.NCR.COM                    |
 +-------------------+--------------------------------------------------------+

In article <1389@ncrcan.Toronto.NCR.COM> brian@ncrcan.Toronto.NCR.COM (Brian Onn) writes:
>Is there not a redundant full feed into the Toronto area?  I thought that
>both attcan and jarvis were bringing news in, and that most of the major
>sites were exchanging news with each other. 

We bring a (nearly) full feed in from uunet, have been since last
August:

comp,sci,news,rec,soc,talk,can,tor,ont,gnu,alt,misc

We feed geac and a few leaf nodes.


-- 
Kevin Brighton                          kevin@jtsv16.jts.com    
JTS Computer Systems Ltd.       { suncan | geac | uunet }!jtsv16!kevin
Toronto, Ontario, CANADA                   +1 416 665 8910

In article <1389@ncrcan.Toronto.NCR.COM> brian@ncrcan.Toronto.NCR.COM (Brian Onn) writes:
>Is there not a redundant full feed into the Toronto area? ...

News appears to be flowing fairly normally; the concern was with mail and
with the general issue of having a major site down.
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

One need only look at the references line above to see how quicly this gets
unwieldy.

In reply to Brian Onn, geoff@utstat.uucp (Geoff Collyer) writes:

>C news generates longish Message-IDs because I didn't want to have a
>sequence-number file, which can get truncated by a crash during
>updating, and because Message-IDs are currently generated by a shell
>script.

>However, there are reasons other than aesthetics for preferring short
>Message-IDs, including limitations in dbm(3) on total key and data
>lengths per block.

>One could omit high-order digits of
>the year or encode the information more compactly, perhaps printing
>integers in radix 64 (e.g. <1989May7.041643.29194@utzoo.uucp> could be
>expressed as <!e9`nl()+@utzoo.uucp>, saving 12 characters).

A visible sense of sequence would be nice. How about something in the
middle - a 9-digit representation of seconds, similar to the way it's
used in the Cnews history file, together with the process ID?

This way, an article could be: <610566286.20194@foo.bar>

From 21 characters down to 15 and possibly less. A possible compromise?

(I don't think there's much Cnews can do about long message IDs resulting
from domain names as long as <ncrcan.Toronto.NCR.COM> :-).

-- 

Evan Leibovitch, SA, Telly Online, located in beautiful Brampton, Ontario
   evan@telly.on.ca / {uunet!attcan,utzoo}!telly!evan / (416) 452-0504
Scientists have proven conclusively: Research causes cancer in lab animals

In article <big C news ID :-)> evan@telly.UUCP (Evan Leibovitch) writes:
>One need only look at the references line above to see how quicly this gets
>unwieldy.

Yes.  The reference line is now three lines long.  I seem to recall that 
rn will blow up at some limit.

>A visible sense of sequence would be nice. How about something in the
>middle - a 9-digit representation of seconds, similar to the way it's
>used in the Cnews history file, together with the process ID?
>
>This way, an article could be: <610566286.20194@foo.bar>
>
>From 21 characters down to 15 and possibly less. A possible compromise?

I like this.  This would satisfy Geoff's requirement for unique IDs without
having to keep a separate message counter file that could get truncated.
It may not be as easily generated from standard unix tools, though.  It is
possible to create the current ID in a shell script from date and expr
contortions.  The new method (if adopted) would require a helper program.

>(I don't think there's much Cnews can do about long message IDs resulting
>from domain names as long as <ncrcan.Toronto.NCR.COM> :-).

Ok.  I'll change it to ncrcan.uucp :-)

Brian.

-- 
 +-------------------+--------------------------------------------------------+
 | Brian Onn         | UUCP:..!{uunet!attcan, watmath!utai}!lsuc!ncrcan!brian |
 | NCR Canada Ltd.   | INTERNET: Brian.Onn@Toronto.NCR.COM                    |
 +-------------------+--------------------------------------------------------+

brian@ncrcan.Toronto.NCR.COM (Brian Onn) writes:
...
| Ok, I'll retract.  Stick with the longish, yet unique, 
| and still yet readable, Message-Ids.  I'll start splitting the 
| "In article.." lines into two, as you subtely suggested. 


 Or better yet, drop them entirely. People who need them can always
find them in the References: line in the header. Anyone know why
they were put there in the first place -- do they predate References:
lines?

-- 
	"Oh BLESS you, sir! The ANGEL OF DEATH was after me just as SURE as
	 you're standing there, yes he WAS!"
Chris Siebenmann		uunet!{utgpu!moore,attcan!telly}!ziebmef!cks
cks@ziebmef.UUCP	     or	.....!utgpu!{,ontmoh!,ncrcan!brambo!}cks

In article <1394@ncrcan.Toronto.NCR.COM> brian@ncrcan.Toronto.NCR.COM (Brian Onn) writes:
>>A visible sense of sequence would be nice. How about something in the
>>middle - a 9-digit representation of seconds, similar to the way it's
>>used in the Cnews history file, together with the process ID?
>
>I like this.  This would satisfy Geoff's requirement for unique IDs without
>having to keep a separate message counter file that could get truncated.
>It may not be as easily generated from standard unix tools, though...

Geoff and I have tentatively decided to do this, in fact.  It's easy; we
already have a program called "getdate" (and its inverse, ctime) for use
in bits of housekeeping.
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

In article <498@jtsv16.UUCP> kevin@jtsv16.jts.com (kevin brighton) writes:
>In article <1389@ncrcan.Toronto.NCR.COM> brian@ncrcan.Toronto.NCR.COM (Brian Onn) writes:
>>Is there not a redundant full feed into the Toronto area?  I thought that

>We bring a (nearly) full feed in from uunet, have been since last
>August:

>We feed geac and a few leaf nodes.

     Originally our main feed was yunexus however a while ago, there was a small
problem with smoke in the computer room there. This meant that yunexus became
somewhat unreliable for most of the holiday season. At this time we set up a 
full feed to jtsv16 (it had been only local groups up to that time) and 
afterwards left it as a redundant feed. Additionally the traffic to yunexus
was also restricted (to non-jtsv16 articles) because it seemed to be heavily
loaded with news traffic and an additional redundant inbound feed seemed 
unnecessary. 
    I anticipated that the news re-organization would change things later anyway
so I did not worry about the issue further. Since this has not happened, geac
is prepared to arrange redundant feeds to Trailblazer sites in order to provide 
a backup for the regular feeds. If you are interested send me mail to work out 
the details.


-- 
Eric Dirks 		Geac Computer Corporation, Markham, Ontario
eric@geac
{uunet!jtsv16,yunexus,utgpu}!geac!eric