evan@telly.on.ca (Evan Leibovitch) (05/07/89)
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?
--
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 animalsbrian@ncrcan.Toronto.NCR.COM (Brian Onn) (05/07/89)
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 | +-------------------+--------------------------------------------------------+
henry@utzoo.uucp (Henry Spencer) (05/07/89)
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
brian@ncrcan.Toronto.NCR.COM (Brian Onn) (05/07/89)
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 | +-------------------+--------------------------------------------------------+
geoff@utstat.uucp (Geoff Collyer) (05/08/89)
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)
brian@ncrcan.Toronto.NCR.COM (Brian Onn) (05/08/89)
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 | +-------------------+--------------------------------------------------------+
geoff@utstat.uucp (Geoff Collyer) (05/09/89)
> 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). Oops, RFC 822 overrides RFC 1036 (so that netnews can be mailed around), so the character set of Message-IDs is restricted to 54 characters (excluding upper case, since some news software folds case in Message-IDs). Make that radix 32, <0i67urbsga@utzoo.uucp>, for a saving of 11 characters. -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu It's all Henry's fault. (TM)
henry@utzoo.uucp (Henry Spencer) (05/09/89)
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
cks@ziebmef.uucp (Chris Siebenmann) (05/10/89)
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