Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!metro!usage.csd.unsw.oz.au!plod.cbse.unsw.oz.au
From: troy@plod.cbse.unsw.oz.au (Troy Rollo)
Newsgroups: comp.sys.apollo
Subject: Re: rgyd problems again (dn3500, sr10.2) ...sigh
Message-ID: <1011@usage.csd.unsw.oz.au>
Date: 24 Dec 90 04:32:22 GMT
References: <5309@hemuli.tik.vtt.fi>
Sender: news@usage.csd.unsw.oz.au
Reply-To: troy@plod.cbme.unsw.oz.au
Distribution: comp
Lines: 33

From article <5309@hemuli.tik.vtt.fi>, by Markku.Savela@tel.vtt.fi (VTT/TEL):

Markku.Savela>   Arghh! I'm no apollo expert, so I just rebooted the machine again.
Markku.Savela> This time "rgyd" didn't start even on boot. It didn't complain when
Markku.Savela> I started it manually, but it seems non-functional (hmm.. just now
Markku.Savela> when I tried, it seems to have gotten something ok, could "su" again
Markku.Savela> normally, but still cannot run "edrgy", I get...


Check the global location database...ie.

/etc/ncs/lb_admin
lb_admin> domain global
lb_admin> l

This should give a list of registries. If the list is incorrect, or, worse 
still, if you get an unexpected machine holding the known glb, your problem is
one of the now famous location broker problems.

How to fix:

	First, make sure you start the location broker with -li dds (normally
the correct option, meaning limit *to* domain distrbuted systems).
Then create a new file, /etc/ncs/glb_site.txt, containing a list of machines,
one machine per line, where you can expect to find your glb. This will
probably be dds://machine_name

Make it publicly readable (probably not necessary, but it doesn't hurt),
and reboot. This should prevent anybody else from throwing unwanted location
broker stuff at you.
___________________________________________________________
troy@mr_plod.cbme.unsw.oz.au	 
Fascist comments deleted for the duration of the Gulf Crisis