[news.software.anu-news] news 5.9

gih900@UUNET.UU.NET (Geoff Huston) (09/18/89)

Pekka Kyt|laakso writes:
     
>I downloaded the anu-news-v59.tar.Z using ftp to csc2.anu.oz.au
>The tar file seems to have only the sources. is the documentation
>available anywhere?
     
As I mentioned in my posting last week I have not had time to work on
documentation as yet. It's coming.... slowly. I'll post to the anu-news mailing
list when I've got something ready,
     
cheers,
     
Geoff Huston
gih900@csc.anu.oz.au

gih900@UUNET.UU.NET (Geoff Huston) (09/22/89)

Scott,
     
I forward this reply to the anu-news newsgroup as well...
     
Attention is drawn to item 5 for all VMS V5 users.
     
>   Thanks for making the 5.9 version of NEWS available.  Several of the
>changes were greatly appreciated, especially the MAILLIST qualifier.  I
>have a few notes for you concerning the new version and its installation.
>For reference, I have NEWS running on a VAXstation 3200, VMS 5.2, VAXC
>2.4, and the CMU 6.4 distribution with IPACP and NAMSRV as patched by the
>authors and made available by FTP from their system.
>
>1) The NNTP_TCPCMU.C module works as distributed (without the
>accompanying patch) with one change.  In the DEBUG code that writes out
>the time that the server was started, change cur_time to &cur_time.  The
>function in NNTP_TCPCMU.C that returns the foreign host name works on my
>system.  This probably means that VAXC changed the way structures are
>aligned when they went to version 3.0.  The way I originally debugged
>this code was to declare a character string with length 1000, feed it to
>the TCP$INFO call, dump what was returned, count bytes and check the
>length field.  I should note that the function will not return the
>foreign host name the first few times that it is invoked.  It seems that
>something needs to get initialized in the CMU software before the
>TCP$INFO call will work.  Placing the hosts the you expect to see in the
>HOSTS.TXT file seems to speed up this initialization process.  I
>typically only see one failure per host (from the NNTP_FEED.LOG file).
     
This QIO (TCP$INFO) is a real problem - It runs on some sites, and not on
others, and requires funny changes on others,...
     
My response has been to remove the code within the getremhost() call and sinply
supply a host name of "TCP". At least it works!. The downside is that the nntp
access list cannot then control which hosts may access you as a server, nor can
you effectively restrict newsgroups to include specific remote users on nntp
client systems coming in over TCP.
     
>2) In the NNTP_TCPCMU.C module, the call to SYS$CANCEL() in close_net()
>can/should probably be deleted.  If that subroutine is reached, there
>shouldn't be any outstanding calls to the IP device.  Leaving the call in
>causes the following call to TCP$CLOSE to fail.
     
This is somewhat non-intuitive - the cancel call was there as a catch-all to
catch any outstanding traffic on the channel, making the close call function
without errors!!!!. On my system the channel DOES close anyway - when you sayt
that the call fails, is the channel left open??
     
>3) In the NNTP_TCPCMU.C module, the DEBUG variable should probably be
>initialized to FALSE rather than TRUE.
     
correct - my error
     
>4) As noted on the net, YCMND should be replaced by STAT in both
>NEWSREMCLIENT.C and NNTP_FEED.C.  This had two of my UNIX feeds rather
>upset until we tracked it down.
     
correct - again my error, due to a lack of knowledge about how other NNTP
implementations reacted to unknown commands! (I must admit that logging all
unknown commands is a bit extreme - but then again I suppose that they had
their reasons!)
     
>5) The change to the callable mail interface in VMS 5.0 systems
>necessitates a change in the format of the NEWS_ADDRESS.CNF file.  All of
>the quotes used to escape the quote characters must be removed.  The
>addresses should be of the form IN%"user@host" instead of
>"IN%""user@host""".  This probably needs to be changed in ADD_TRANSFORM.C
>as well.
     
     
GOOD POINT - as the string is now NOT passed to the DCL CLI the extra quotes
get in the way.
     
This is the necessary change to the default table (ADD_TRANSFORM.C):
     
static struct {		/* the structure which holds the address patterns    */
    char *internet;	/* and the corresponding rewrite rules		     */
    char *local;
    }
      def_rules[] = {	/* Default is to pass all addresses to local PMDF    */
	{"in%*",    "in%\001"},
	{"psi%*",   "psi%\001"},
	{"@*",	    "@\001"},
	{"*@*",	    "in\%\"\001@\002\""},
	{"*::*",    "in\%\"\002@\001\""},
	{"*",	    "\001"},
	{"",""}},
      *addrs = 0;	/* Pointer to loaded rule set			     */
     
     
NOTE NOTE NOTE NOTE NOTE NOTE NOTE - VMS V5 NEWS USERS **************
     
All VMS V5 users will also need to make changes in the NEWS_ADDRESS.CNF
file to strip out the DCL required quotes i.e.:
     
	"handler%""address"""   becomes   handler%"address"
     
The VMS V4 version of this program still calls mail via DCL so no change is
necessary for VMS V4.
     
>6) It turns out that the current method of batching files into the
>NNTP.BATCH files causes some problems when two feeds try to update the
>same file at the same time.  This appears to be related to a bug in the
>early releases of VMS 5.  Encoding the PID into the file name seems to
>prevent all of the problems.  In module NNTP_SERVER.C, change the
>NEWSBATCH define to be NEWS_MANAGER:NNTP_%X.BATCH.  In function
>add_item(), add a declaration for char batch[FILE_STRLEN] and change the
>line that does the fopen to be fopen(batch,"a").  Immediately before
>this, place a sprintf(batch,NEWSBATCH,getpid()).  This also will require
>a change to the batch job command files (NEWSSKIM.COM).
     
Agreed. If the description of these changes is not obvious to the news list
readers, I will be posting out a consolidated set of the first batch of V5.9
changes in about two weeks from now (cause I'm still collecting bug reports!!!)
     
>7) NEWSMAIL.C should probably have its name changed to avoid conflict
>with the logical name that the installation guide suggests creating.
>This could also be fixed with a change in NEWSBUILD.COM.
     
Yeah - agreed - NEWSVMSMAIL.C now comes into existance
     
note that in making this change you'll need to change NEWSBUILD.COM and also
use the LIBRARIAN utilility to remove the NEWSMAIL module manually.
Also note that for consistency reasons the new module name (#module) in the
file should be changes to NEWSVMSMAIL.C
     
>8) In version 2.4 of the VAXC compiler, the header files sjcdef.h,
>clidef.h, sordef.h, and uaidef.h do not exist. Two of these were supplied
>with the NEWS 5.8 release (sjcdef.h and uaidef.h) and can be used without
>problems.  Sordef.h may be replaced with with sortdef.h from the NEWS 5.8
>release as well.  I found a copy of clidef.h on a recent DECUS tape and
>it seems to work.  I can send you this DECUS version if you would like to
>have it for inclusion.  All of the references to these files would need
>to be changed appropriately by those compiling with VAXC 2.4. The
>affected files are NEWSEXTRACT.C, NEWSMOD.C, NEWSSKIM.C, and NEWSSITE.C.
     
I'm not sure what is best here, as most of us will be running VAX C V3.0 sooner
or later. Perhaps the best answer is posting the deleted .h files to the
anu-news mail list.
     
>Finally, a few things I have noticed but haven't had time to track down.
>
>9) Cancel control messages with no body (Lines: 0) do not seem to get
>executed.  I don't know if this applies to all messages, all control
>messages, or just cancel control messages, but this is potentially
>serious given some of the recent events on the net.
     
Hmmmmmmm - new one on me
     
>10) When the SEARCH command displays output (great job!), the highlighted
>text is incorrect if there are tabs in the line before the occurrence of
>the search string.  My hunch is that tabs are being counted as a single
>character rather than the multiple characters that are actually
>displayed.
     
correct this is SMG at its best!!!!! wh
     
>11) When you finish reading a message and use the TOPIC command, nothing
>seems to happen.  READ/TOPIC works just fine.  TOPIC seems to work if you
>are on the display containing the message list and subjects.  Apparently,
>some state variable is not correctly set up.
     
I'll have to look into this one
     
Scott, thanks for your work in nailing down these problems. I hope the
responses are useful to both yourself and the net readers.
     
     
cheers,
     
Geoff Huston
gih900@csc.anu.oz.au