From:	CRDGW2::CRDGW2::MRGATE::"SMTP::DECWRL.DEC.COM::SIMPACT!JEH" 10-OCT-1989 17:25
To:	MRGATE::"ARISIA::EVERHART"
Subj:	Terry Poot's two questions

Message-Id: <8910102051.AA18793@decwrl.dec.com>
Received: from decwrl.dec.com by DRYCAS.CLUB.CC.CMU.EDU; Tue, 10 Oct 89 16:53
 EDT
Received: by decwrl.dec.com; id AA18793; Tue, 10 Oct 89 13:51:31 -0700
Received: by simpact.com (DECUS UUCP w/Smail); Tue, 10 Oct 89 12:40:47 PDT
Date: Tue, 10 Oct 89 12:40:47 PDT
From: Jamie Hanrahan <jeh@simpact.com>
Subject: Terry Poot's two questions
To: vmsnet@DRYCAS.CLUB.CC.CMU.EDU

> 1) Does ANU news respond correctly to control messages such as SENDSYS? One
> of my news neighbors sent a sendsys, and ANU News failed to mail back the
> response. Here is what was put into the rnews_*.log file:
> 
> ----------------------------------------------------------------------
>         Control: sendsys - Reply sent to "uucp%""tar@ksuvax1.cis.ksu.edu"""
> %MAIL-E-SENDERR, error sending to user tar@ksuvax1.cis.ksu.edu at 
> %PAS-F-ERRDUROPE, error during OPEN
>   File "MESSAGE_INFO_PTR^MESSAGE_INFO.REQUESTS_FILE"  Filename "MIS2::"UUCP_REQU
> ESTS:""
> -RMS-E-ACC, ACP file access failed
> -SYSTEM-F-INVLOGIN, login information invalid at remote node

It looks like the account under which your news batch stuff runs doesn't have
FAL access to the uucp node.  

uucp_mailshr sends a message to the uucico daemon's mailbox -- known by the
logical name uucp_requests -- whenever it places outgoing mail in the spool
directory.  In a VAXcluster environment this is a bit of a problem:  The spool
directory is (we hope) on a disk that's visible to all nodes, but of course
there's no such thing (yet) as a cluster-wide mailbox.  So on nodes other than
that on which the uucico daemon runs, we define the logical uucp_requests to be
uucp_node::uucp_requests (see uucp_systartup.com), and send the message to the
mailbox through FAL.  

For this to work, any account which will be sending uucp mail has to have FAL
access to the uucp node.  Check proxy entries, etc., on the uucp node.  There
are two interesting workarounds:

1.  On the non-uucp node, change the definition of uucp_requests (in 
uucp_systartup.com) to something like

	$ defsys uucp_requests "uucp_node""username password""::uucp_requests"

in other words, put the whole access control string in the logical, and don't
rely on proxies or the decnet default account.  

(As an aside, I'm a little puzzled by the extra quotes in the error message:

>   File ... "MIS2::"UUCP_REQUESTS:""
                    ^              ^

2.  If you can't get it to work any other way:  On the non-uucp nodes, change 
the definition of uucp_requests as follows:

	$ defsys uucp_requests nla0:

The mailbox message is not required -- it merely causes the uucico daemon
to wake up right away instead of waiting for the end of its current sleeptime
(15 minutes in the distributed control file).  So mail delivery will be a 
bit delayed.  On the other hand the sending of mail will go a bit faster 
because uucp_mailshr won't have to wait for a FAL process to start up on the
uucp node. 

> 2) Where can I get the vmsnet.* newsgroups? 

This is an area we haven't pursued much -- the mailing list seems to be doing
all we need for now.  Volume is so low (under one message per month) that it
isn't worth chasing.  Of course if we had a better distribution tree there'd
be more volume... I'll be more interested in pursuing this when Mark gets 
the vmsnet mailing list/vmsnet.misc newsgroup gateway going.  (Mark???)

	--- 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