[comp.sys.apollo] login-problem

brunner@metoch.uu.ch (felix brunner) (07/31/90)

Hello

I am responsible for a net of ten Apollo WS which are
connected to an ethernet. It is a mixed environment with five
DN 3500 and another five DN 2500. In the net we got three harddisks
and all nodes are running SR10.2.
 There is a problem on one node and all nodes which are
booting from this nodes harddisk. If someone logs into this node
it takes about 40 seconds to get PAD001 while the same procedures
on other nodes only takes about 5 seconds or so ( I mean all other nodes
which are booting not from this harddisk ). Of course I have a nice view
to the Swiss Alps, but sometimes I'd like to get the PAD faster just
to be more productive.
 Someone told me to remove the /sys/node_data/hintfile and to reboot 
this particular node, but it didn't help.

Has somebody on the net any clue of what this could be ? 
Any given hint is very appreciated.


Felix Brunner  brunner@metoch.ch

Mettler-Toledo AG
Im Langacher 
8606 Greifensee
Switzerland


   

crh@APOLLO.ENG.OHIO-STATE.EDU (Charlotte Hawley) (08/01/90)

<   There is a problem on one node and all nodes which are
<   booting from this nodes harddisk. If someone logs into this node
<   it takes about 40 seconds to get PAD001 while the same procedures
<   on other nodes only takes about 5 seconds or so ( I mean all other nodes

Check the netsvc command.  Perhaps you forgot to change it.  If you
have several nodes booting from the disked node, you should change
the netsvc to the maximum of 3.  
(You can do this by uncommenting these lines in rc.user)
At least this is one thing to check.
                                                                   

thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (08/01/90)

> I am responsible for a net of ten Apollo WS which are
> connected to an ethernet. It is a mixed environment with five
> DN 3500 and another five DN 2500. In the net we got three harddisks
> and all nodes are running SR10.2.
>  There is a problem on one node and all nodes which are
> booting from this nodes harddisk. If someone logs into this node
> it takes about 40 seconds to get PAD001 while the same procedures
> on other nodes only takes about 5 seconds or so ( I mean all other nodes
> which are booting not from this harddisk ). Of course I have a nice view
> to the Swiss Alps, but sometimes I'd like to get the PAD faster just
> to be more productive.
I'd prefer the Alps to a fast PAD-generate, myself.    :-)

>  Someone told me to remove the /sys/node_data/hintfile and to reboot 
> this particular node, but it didn't help.
I'd still lean toward that, however.  Instead of just deleting the file
and hoping the system checks up on it, try running the 'rtsvc' command
(located in /com as a link, and in /etc).  The 'Net ID' should be the
same on all your machines.  It presumably is the same on all nodes that
are booting off the same disk (otherwise they shouldn't boot!)
If the net IDs are NOT identical, you can set them by using
    /etc/rtsvc -dev ETH802.3_AT -net NET_NUM  [-no_route | -route]
(Use ETH802.3_AT, since you said you were on ethernet.  The man-page
seems to be confused / confusing on the names, specifying ETHERBRIDGE, but
I don't believe that's correct for AT-bus (we have ethernet controllers as
well as ring).  The 'NET_NUM' can be '0', unless you have a Domain Internet
set up (this is NOT tcp/ip internet!)  It can also be any other number
(up to 5? hex-digits).  The '-route' or '-no_route' tells the node
to open up the port for Domain traffic (probably is already), and then either 
to offer routing services, or keep everything local.  Routing services are
only needed if you have a Domain Internet (e.g. 2 rings connected via an
ethernet), in which case you should have read up on the rtsvc command in
the "Managing Domain/OS and Domain Routing in an Internet" manual.

> Has somebody on the net any clue of what this could be ? 
> Any given hint is very appreciated.
Here's hoping the hint works....

John Thompson (jt)
Honeywell, SSEC
Plymouth, MN  55441
thompson@pan.ssec.honeywell.com

As ever, my opinions do not necessarily agree with Honeywell's or reality's.
(Honeywell's do not necessarily agree with mine or reality's, either)