Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!mordor!sri-spam!nike!ucbcad!ucbvax!apollo.UUCP!mishkin
From: mishkin@apollo.UUCP (Nathaniel Mishkin)
Newsgroups: mod.computers.apollo
Subject: Re: USENET news software and Apollo Domain/IX
Message-ID: <8607240725.AA23859@uw-beaver.arpa>
Date: Wed, 23-Jul-86 15:13:32 EDT
Article-I.D.: uw-beave.8607240725.AA23859
Posted: Wed Jul 23 15:13:32 1986
Date-Received: Fri, 25-Jul-86 23:48:41 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 61
Approved: apollo@yale-comix.arpa

In-Reply-To: decvax!tektronix!sequent!mntgfx!dclemans@yale.UUCP, mon, 14 jul 86 18:06:33

    We have the USENET news software (news 2.10.3 beta, rn, vn) running
    on the Apollo ring at Mentor Graphics....

    In this environment, the BIG problem with the USENET software
    (specifically inews) is that it depends on being able to write to
    the news active file (and the history file?) anytime it wants to.
    This capability is NOT supported in general on a multi node Domain/IX
    environment; i.e. if a news reading program has the "active" file
    open for reading, inews/rnews WILL NOT be able to open it with write
    access (unless both the news reader program and inews/rnews are running
    on the same node).

Another message has dealt (or will deal) with how to get around this
problem.  I just want to point out that the reason that this facility
is not available is because it is fundamentally difficult to implement
with any guarantee of reasonable behavior.  It's hard enough to implement
systems (and write programs that use) a facility that allows simultaneous
readers and writers of a single file on a single system, but when you
have multiple systems that don't even have a common physical memory,
it's nearly impossible.

In addition to the simultaneous readers and writers problem, "transient
file system failures" (e.g. network partitions that makes some file
temporarily unavailable) also screw up "traditionally written" programs.
(E.g. pieces of UUCP have the potential for serious problems if they're
not run on the node on which "/usr/spool/uucp" and "/usr/lib/uucp" actually
reside.)

These problems really demand more abstract solutions.  E.g. in the case
of the Usenet sofware, there should be servers answering requests about
what the state of the active newsgroups are.  Of course, the Usenet
software, along with tons of other Unix software, was developed before
there were distributed file systems so the need didn't seem pressing
at the time.

    To get around this, I modified "rn" to make a copy of the active
    file when it starts up and from then on reference only the copy.
    I also stuck some "ulkob -f" (or equivalents) in at various places.
    With this there's still spurts when a few articles disappear, but
    it's not too bad.

"ulkob -f" is a power tool.  Use it incorrectly and you could get hurt.
I'd like to know why/where you found it necessary to use it.

    Another problem is that there are scattered uses of uninitialized
    local variables throughout the USENET software.  While you can get
    away with that most of the time on typical UNIX architectures with
    entirely separate address spaces, you can't on Domain/IX where an
    address space is shared.

While our architecture may not be identical to vanilla Unix, it seems
clear to me that depending on the initial values of uninitialized local
variables is treading on thin (or no) ice.  I.e. I think this qualifies
as a Usenet software bug.
    
                    -- Nat Mishkin
                       Apollo Computer Inc.
                       apollo!mishkin
-------