Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!phigate!prle!prles2!prl.philips.nl!hooft
From: hooft@prl.philips.nl (Peter van Hooft)
Newsgroups: comp.sys.apollo
Subject: Re: mysterious hint file on HP/Domain/OS
Keywords: hint
Message-ID: <2679@prles2.prl.philips.nl>
Date: 6 Apr 91 18:55:37 GMT
References: <885@imec.UUCP> <50cad431.cb12@dabo.citi.umich.edu>
Sender: news@prles2.prl.philips.nl
Lines: 58

|In <50cad431.cb12@dabo.citi.umich.edu> rees@dabo.citi.umich.edu (Jim Rees) writes:
|
|>In article <885@imec.UUCP>, fleureck@imec.be (Marc Fleureck) writes:
|
|>  On Domain/OS SR10.2 some machines seem to have a problem with the file 
|>  /sys/node_data/hint_file.  For example, if I log out ( under DM ) on the 
      .
      .
|In general, you need to remove all hint files and reboot all nodes whenever
|a node moves from one network to another, or net numbers change.

No. When you move a machine to another net, you only have to ctnode -root 
it, or "replace" the entry in the naming server database (using edns) with 
the new netid instead of the old one.

If I _had to_ change net numbers, I would do it like this:
1. IF I had an alternate gateway, I would set it up to route for the old netid
   ELSE I would shutdown the ns_helpers, glbds, and rgyds in the net to change,
   (so they would disappear out of the replica lists) and shut all machines 
   except the gateway.
2. edit the /etc/rc file on the gateway to reflect its new netid
3. use netsvc and rtsvc to change its netid, "replace" its entry in the naming 
   server in the other networks (using edns)
4. "init -from" a ns_helper, "create -from" a glbd on the gateway. 
5. IF I had set up an alternate gateway I would at this point one by one change
   the netid of the other machines using netsvc, "replace"-ing their entries in
   the naming server as I went along. Lastly I would switch off the routing on 
   the alternate gateway, then I would netsvc it.
   ELSE I would boot the other machines one at a time (they would pick up the
   netid of the gateway).
6. after all this I would restore the ns_helpers, glbds and rgyds to their 
   original location, shutting down the temporary ones on the gateway.

This shows you'd better plan _far_ ahead choosing a unique netid :-).
Comments anyone on this procedure ?

|Things become slow because when Domain/OS has to try a remote network to
|locate an object, it doesn't get a nack as it does on the local network.
|Instead it has to time out.  If it has to time out several remote networks,
|it can take a long time.

It should only have to time out when the node is not reachable (remote node 
down, remote network down, naming server info incorrect and ,yes, hint_file 
corrupt).

|The hint file code is old and crufty and probably could use some work.

|If you find that you have to remove the hint file at times when you haven't
|changed your network topology, then something else may be wrong.  Check to
|see that your nodes are cataloged correctly, with the right net id, in the
|network root name server.

And, firstly, at all sr* releases check you have an ns_helper running in each 
network, and at sr10* that you have "at least one" glbd running in each network.

Peter van Hooft    Philips Research Labs, Eindhoven, the Netherlands
Email: hooft@prl.philips.nl SERI: HOOFT:NLWAYA01 Voice: +31 40744327 
X400:  /PN=PJG.VanHooft/O=research/PRMD=philips400/ADMD=400net/C=nl/