jeh@simpact.com (12/16/89)
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 <id> news.group: JUNK (Cannot open output file (write access))
or
Add <id> junk: REJECT (Cannot open output file (write access))
(We'll call these "type 1 errors".)
First there was just one article in one batch; another batch or two
arrived okay, then nearly an entire batch was rejected. For each article,
an item number was assigned and a newsgroup directory entry was created, but
attempts to read the item fail with "unable to access item text", or some
such.
A later batch was rejected with about 400 (the number of items in the
batch?) messages that read
Error: Cannot open scratchfile SYS$SCRATCH:ADD_139B.ITM
(We'll call these "type 2 errors".)
A few hours later, another batch arrived and worked fine, except for one
item that was posted to comp.unix.wizards and rejected (Type 1). It turns
out that although there's an entry in news.groups for comp.unix.wizards,
the directory doesn't exist. Apparently, in this case, NEWS trusts news.groups
and doesn't try to create the directory if it isn't there.
However, this was NOT the case with the previous (very numerous) "type 1"
errors; the directories did exist. Not only that, but I logged into the
newsmgr account and did one of the adds "by hand", and it worked fine.
Does anyone have any idea of what is going on? (Yes, the current (only)
version of NEWS.EXE is installed with sysprv, and the newsmgr account has
sysprv as well.)
Suggestions: 1. Add an interpretation of the error status return from
file open attempts. These messages would be a lot more helpful if
accompanied by "no privilege for attempted operation" or "no such device"
or whatever. 2. All error messages should have some sort of indicator in
them to distinguish them from all the other output from an ADD BATCH. I'd
like to have the once-a-night NEWSSKIM do a SEARCH of the previous day's
ADD BATCH log files looking for error messages, and mail the result to
the news manager.
--- 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: ...{crash,scubed,decwrl}!simpact!jehjeh@simpact.com (12/16/89)
In article <791.2588fa61@simpact.com>, jeh@simpact.com writes: > ... > A few hours later, another batch arrived and worked fine, except for one > item that was posted to comp.unix.wizards and rejected (Type 1). It turns > out that although there's an entry in news.groups for comp.unix.wizards, > the directory doesn't exist. Apparently, in this case, NEWS trusts news.groups > and doesn't try to create the directory if it isn't there. Third suggestion: In this case, NEWS should just go ahead and create the directory.
gih900@UUNET.UU.NET (Geoff Huston) (12/20/89)
>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 <id> news.group: JUNK (Cannot open output file (write access)) >or > Add <id> junk: REJECT (Cannot open output file (write access)) > ....... check which account owns the itm files, and then check the diskquota entry - it looks like you are out of quota (or out of free space on the disk). > >Suggestions: 1. Add an interpretation of the error status return from >file open attempts. These messages would be a lot more helpful if >accompanied by "no privilege for attempted operation" or "no such device" >or whatever. 2. All error messages should have some sort of indicator in >them to distinguish them from all the other output from an ADD BATCH. I'd >like to have the once-a-night NEWSSKIM do a SEARCH of the previous day's >ADD BATCH log files looking for error messages, and mail the result to >the news manager. 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! Geoff Huston
foperator@tekno.chalmers.se (Daniel Berglund) (12/23/89)
In article <8912190723.AA14204@uunet.uu.net>, munnari!csc.anu.oz.au!gih900@UUNET.UU.NET (Geoff Huston) writes: >>Suggestions: 1. Add an interpretation of the error status return from >>file open attempts. These messages would be a lot more helpful if >>accompanied by "no privilege for attempted operation" or "no such device" >>or whatever. > 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! Maybe I'm overlooking something obvious, but the rms STS value can be found in vaxc$errno (but I don't know how to access the STV value). Example: #include errno #include perror main() { fopen("sahdjgf$$$","r"); perror("Blurp"); printf("%d %d\n",errno,vaxc$errno); fopen("sdf:asjklhdf$$$","r"); perror("Blurp"); printf("%d %d\n",errno,vaxc$errno); fopen("gdgd%gsgs","r"); perror("Blurp"); printf("%d %d\n",errno,vaxc$errno); } yields: $ r apa Blurp: no such file or directory 2 98962 Blurp: no such device or address 6 99524 Blurp: non-translatable vms error code: 0x18744, vms message: %rms-f-wld, invalid wildcard operation 65535 100164 -- Daniel Berglund (foperator@tekno.chalmers.se, BITNET: FOP@SECTHF51) Chalmers University of Technology, G|teborg, Sweden
glassmann@ccavax.camb.com (12/23/89)
In article <8912190723.AA14204@uunet.uu.net>, munnari!csc.anu.oz.au!gih900@UUNET.UU.NET (Geoff Huston) writes: > 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! > I thought this info could be gotten from the global variable vaxc$errno. -- Lenny Glassmann glassmann@ccavax.camb.com
jeh@simpact.com (12/30/89)
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 <id> news.group: JUNK (Cannot open output file (write access)) >>or >> Add <id> junk: REJECT (Cannot open output file (write access)) >> > ....... > > check which account owns the itm files, and then check the diskquota entry - it > 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: ...{crash,scubed,decwrl}!simpact!jeh