greg@ncr-sd.UUCP (Greg Noel) (05/19/86)
Somewhere along the amazingly short path ncr-sd!sdcsvax!ucbvax!cbosgd!postmap, article <2124@cbosgd.UUCP> with the subject "UUCP map for u.usa.il.att.1" got smashed. According to Mark Horton, the article is OK on cbosgd, so either ucbvax or sdcsvax smashed it. Of the two, ucbvax is indicated, since I don't think sdcsvax has anything to do with either mtxinu or olympus. Sites down- stream of ucbvax should check to see that their copy is OK. If this damage is widespread, could it be reposted? The smashed fragement is attached below. #N muskie #S #O AT&T Bell Laboratories, Indian Hils daemon mtxinu (4/26-17:04) (514947899.56) sent data 95 bytes 0.10 secs daemon mtxinu (4/26-17:05) (514947914.71) sent data 943 bytes 10.35 secs daemon mtxinu (4/26-17:05) (514947920.29) sent data 93 bytes 0.04 secs uucpadm olympus (4/26-17:05) (514947939.82) received data 2002 bytes 20.56 secs uucp mtxinu (4/26-17:05) (514947944.50) sent data 1805 bytes 18.22 secs uucpadm olympus (4/26-17:05) (514947945.76) received data 76 bytes 1.89 secs uucp mtxinu (4/26-17:05) (514947951.75) sent data 86 bytes 0.03 secs uucp olympus (4/26-17:05) (514947957.34) sent data 867 bytes 7.11 secs uucp olympus (4/26-17:06) (514947961.64) sent data 83 bytes 0.05 secs daemon mtxinu (4/26-17:06) (514947968.80) sent data 1226 bytes 12.02 secs daemon mtxinu (4/26-17:06) (514947973.30) sent data 109 bytes 0.06 secs daemon mtxinu (4/26-17:06) (514947990.03) sent data 1205 bytes 10.80 secs daemon mtxinu (4/26-17:06) (514947996.37) sent data 98 bytes 0.10 secs daemon mtxinu (4/26-17:07) (514948023.81) sent data 1981 bytes 21.59 secs dae+345-7583 #P Room 1-2;2600 Warrenville Rd.;Lisle, IL 60532 #L 41 48 N / 88 05 W #R #U #W 851204 ihnp4!action # -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
fair@ucbarpa.Berkeley.EDU (Erik E. Fair) (05/19/86)
The article is OK here on our system, but damn if that doesn't look like a piece of our UUCP SYSLOG (and we speak to both mtxinu and olympus...). Now, we have been having some problems with running out of file descriptors in the kernel tables, but fail to see how that might cause this... Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu
johnsson@decwrl.UUCP (05/19/86)
The map arrived here by the path decwrl!ucbvax!cbosgd!postmap and is not smashed.
mark@cbosgd.UUCP (Mark Horton) (05/19/86)
In article <882@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >Somewhere along the amazingly short path ncr-sd!sdcsvax!ucbvax!cbosgd!postmap, >article <2124@cbosgd.UUCP> with the subject "UUCP map for u.usa.il.att.1" got >smashed. According to Mark Horton, the article is OK on cbosgd, so either >ucbvax or sdcsvax smashed it. Of the two, ucbvax is indicated, since I don't >think sdcsvax has anything to do with either mtxinu or olympus. Sites down- >stream of ucbvax should check to see that their copy is OK. If this damage >is widespread, could it be reposted? > >The smashed fragement is attached below. > >#N muskie >#S >#O AT&T Bell Laboratories, Indian Hils >daemon mtxinu (4/26-17:04) (514947899.56) sent data 95 bytes 0.10 secs >daemon mtxinu (4/26-17:05) (514947914.71) sent data 943 bytes 10.35 secs >daemon mtxinu (4/26-17:05) (514947920.29) sent data 93 bytes 0.04 secs >uucpadm olympus (4/26-17:05) (514947939.82) received data 2002 bytes 20.56 secs >uucp mtxinu (4/26-17:05) (514947944.50) sent data 1805 bytes 18.22 secs >uucpadm olympus (4/26-17:05) (514947945.76) received data 76 bytes 1.89 secs >uucp mtxinu (4/26-17:05) (514947951.75) sent data 86 bytes 0.03 secs >uucp olympus (4/26-17:05) (514947957.34) sent data 867 bytes 7.11 secs >uucp olympus (4/26-17:06) (514947961.64) sent data 83 bytes 0.05 secs >daemon mtxinu (4/26-17:06) (514947968.80) sent data 1226 bytes 12.02 secs >daemon mtxinu (4/26-17:06) (514947973.30) sent data 109 bytes 0.06 secs >daemon mtxinu (4/26-17:06) (514947990.03) sent data 1205 bytes 10.80 secs >daemon mtxinu (4/26-17:06) (514947996.37) sent data 98 bytes 0.10 secs >daemon mtxinu (4/26-17:07) (514948023.81) sent data 1981 bytes 21.59 secs >dae+345-7583 >#P Room 1-2;2600 Warrenville Rd.;Lisle, IL 60532 >#L 41 48 N / 88 05 W >#R >#U >#W 851204 ihnp4!action ># >-- >-- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA The missing data from the original file looks like this. You'll note there are only comments, as far as pathalias is concerned. So if you're just trying to keep pathalias happy, you can delete the offending lines. If you need the contact information, you can patch this in. I don't want to repost such a large file, however. Mark #N muskie #S #O AT&T Bell Laboratories, Indian Hill (IH) 55231 #C Terry Todd (IH 6N-530) #E muskie!tlt #T (312)979-2077 8+367-2077 #P Naperville-Wheaton Road;Naperville, IL 60566 #L 41 47 N / 88 09 W #R #U #W 860128 ihnp4!action # #N nwlsa #S #O AT&T Technologies, Network Software Center (NW) 11nw064110 #C Dave Baker #E nwlsa!tapperz #T (312)510-7656 8+345-7656 #P NW 32D21;2600 Warrenville Rd.;Lisle, IL 60532 #L 41 48 N / 88 05 W #R #U #W 840905 ihnp4!action # #N nwprd #S #O AT&T Technologies, Network Software Center (NW) 11nw503350 #C Jerry Jones #E ih1ap!jj #T (312)510- 8+345- #P 11NW503350;2600 Warrenville Rd.;Lisle, IL 60532 #L 41 48 N / 88 05 W #R #U #W 850821 ihnp4!action # #N nwuld1 #S #O AT&T Network Systems, Network Software Center (NW) 11nw521410 #C Willie J Halbert (NW 42B24) #E ihuxi!iclid #T (312)510-6828 8+345-6828 #P Dept. 11NW521410;2600 Warrenville Rd.;Lisle, IL 60532 #L 41 48 N / 88 05 W #R #U #W 860115 ihnp4!action # #N nwutb #S #O AT&T Technologies, Network Software Center (NW) #C Del Howell #E nwutb!ddh #T (312)510-7583 8+345-7583 #P Room 1-2;2600 Warrenville Rd.;Lisle, IL 60532 #L 41 48 N / 88 05 W #R #U #W 851204 ihnp4!action #
greg@ncr-sd.UUCP (Greg Noel) (05/20/86)
In article <13879@ucbvax.BERKELEY.EDU> fair@ucbarpa.Berkeley.EDU (Erik E. Fair) writes: >The article is OK here on our system, but damn if that doesn't look >like a piece of our UUCP SYSLOG (and we speak to both mtxinu and >olympus...). Now, we have been having some problems with running out of >file descriptors in the kernel tables, but fail to see how that might >cause this... I don't see how that might cause it, either. However, the article is smashed on sdcsvax, meaning that everybody that got the article from sdcsvax (all of San Diego, possibly all of SoCal) has a smashed copy. Is there any way of getting a corrected version down here so that it could be resubmitted with a sdnet distribution? That would get it fixed in the San Diego area -- even just the correct text for the portion that was smashed would be a help. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA