Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!kuhub.cc.ukans.edu!anu-news!list From: root@NSFNET-RELAY.AC.UK Newsgroups: news.software.anu-news Subject: Mail Delivery Failure to uk.ac.king - Rejected Message-ID: Date: 2 Jan 90 07:04:46 GMT Sender: ANU-NEWS Discussion Reply-To: root@NSFNET-RELAY.AC.UK Lines: 87 Via: 000040010180.FTP.MAIL; 2 JAN 90 7:09:36 GMT The NIFTP process was unable to deliver your mail to host uk.ac.king over janet. The reason given by the remote host was: Invalid value in command: invalid attribute - filename "FTP$NETWELL:MAILTMP.TMP". File open failure reason - device full (insufficient space for allocation). Secondary reason - device full - allocation failure. Username ignored. VAX/VMS FTP (80) Version 5.0. Your message was not delivered to the following addresses: GPKING@uk.ac.kingston Your message begins as follows: Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK Via Ethernet with SMTP id aa09032; 31 Dec 89 1:41 GMT Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa06681; 31 Dec 89 1:33 GMT Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 3801; Sun, 31 Dec 89 01:38:15 GM Received: from NDSUVM1.BITNET by UKACRL.BITNET (Mailer X1.25) with BSMTP id 1159; Sun, 31 Dec 89 01:38:15 G Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.03B) with BSMTP id 2567; Sat, 30 Dec 89 19:36:26 C Date: Fri, 29 Dec 89 23:47:16 GMT Reply-To: jeh@com.simpact Original-Sender: ANU-NEWS Discussion From: jeh@com.simpact Subject: Re: RE: Troubles adding batches with 5.9B To: Multiple recipients of list ANU-NEWS Sender: ANU-NEWS%earn.ndsuvm1@uk.ac.earn-relay In article <8912190737.AA16720@uunet.uu.net>, munnari!csc.anu.oz.au!gih900@UUNET.UU.NET (Geoff Huston) writes: >>We are running NEWS 5.9B. >> >>Last night a large number of articles that arrived in "rnews" format were >>rejected by the add/network command, with messages of the form >> >> Add news.group: JUNK (Cannot open output file (write access)) >>or >> Add junk: REJECT (Cannot open output file (write access)) >> > ....... > > check which account owns the itm files, and then check the diskquota entry - i t > looks like you are out of quota (or out of free space on the disk). > Accounts and file ownership and directory protections and all were all as they used to be and as they are now -- ie I didn't change anything and things just suddenly started to work again. We don't use diskquotas here, and it's quite unlikely that the disk was full, since (a) there was 75 Mbytes of free space the next morning and (b) some batches had some items that were received correctly. > its just another of the integration problems - vaxc is not quite VMS - at this > point the NEWS code sees a -1 value from a file operation and says "oh well - > nice try" - to get past this to the RMS return status is what you are asking > for... could be interesting! imho this is one of the things that really needs to be worked on. It's a real pain to track down the cause of problems when the only diagnostic is equivalent to "there's a problem". Another nicety in the "problem tracking" area would be some trace capability. Folks are always having troubles getting their news.sys and news.distribution files right; it'd be nice to turn on a "forwarding trace" feature and get output like neighbor system crash: Item not forwarded (news.sys filter) neighbor system pnet01: Item not forwarded (news.distribution filter) where each decision is made. --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...Ecrash,scubed,decwrlL!simpact!jeh