T.R | Title | User | Personal Name | Date | Lines |
---|
1745.1 | cluster alias | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Wed Oct 30 1991 15:56 | 6 |
| The way a cluster alias works - is you give the alias name, and ANY ONE
of the nodes in the cluster responds. So, I suspect your first command
was processed by one of the nodes which was registers. The command
you issued later was processed by an unregistered node.
/keith
|
1745.2 | still not clear | SWORD1::ES | Eugene Shvartsman | Thu Oct 31 1991 10:21 | 7 |
| Sorry, Keith, but I am not able to understand you last sentence:
>The command you issued later was processed by an unregistered node.
Whould you, please, elaborate on this.
Thank you,
Gene
|
1745.3 | any node in a cluster can respond to a request directed to the cluster-alias name | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Thu Oct 31 1991 11:09 | 18 |
| The MCC developement cluster is called TOOK. It is composed of 4 or
5 8550 vax's - BOEHM, RAMPAL, HAYNES, DORIOT, ...
If I give the command: show node4 took all char
any one of the nodes in the cluster could respond.
If, 2 minutes later, I try the command again, it is possible for a
DIFFERENT node in the cluster to respond.
The first show command you did, was processed by a node in the cluster
which was already registered. I suspect that the second time you did
the show command, a different node in the cluster responded which was
not previously registered.
Is this clearer?
/keith
|
1745.4 | still there | SWORD1::ES | Eugene Shvartsman | Thu Oct 31 1991 11:51 | 47 |
| Keith,
To tell you the truth, no.
When I issue command:
MCC> show node4 dec:.lkg.took
Using default ALL IDENTIFIERS
Node4 DEC:.lkg.TOOK
AT 30-OCT-1991 12:07:31 Identifiers
Specified Node4 is a Cluster Alias. Use a cluster member.
A cluster member = 4.33
the responce in this case I do understand as you have explained, i.e
the cluster member 4.33 (QUANTZ) in the cluster TOOK has responded.
Maybe my understanding is wrong, please, tell?
BTW, it is not regestred in DNS as MCC node, if this is what you mean under
the word "regestered".
DNS> show object dec:.lkg.QUANTZ
Attribute (Single) ___ DNA$NodeSynonym
Attribute (Set) ______ DNA$Towers
Attribute (Set) ______ DNS$ACS
Attribute (Single) ___ DNS$Class
Attribute (Single) ___ DNS$ClassVersion
Attribute (Single) ___ DNS$UID
Attribute (Single) ___ DNS$UTS
And it seems to me that none of the members in the cluster TOOK either, only
the TOOK itself.
But when I have responce:
Node is not registered.
I don't know which node in the cluster has responded as you've suggested and
where this node or maybe some other one is not register and why it supposed to
be registered and where?
I've thought that this reply means TOOK itself, and that is the reason why I've
shown the result of DNS output to prove that it is still there.
Still there too,
Gene
|
1745.5 | Perhaps the DECnet AM people could shed some light | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Thu Oct 31 1991 15:09 | 4 |
| Hmm..I think the DECnet AM team could better explain what is going
on here.
/keith
|
1745.6 | depends on the type of the global entity instance | TOOK::JEAN_LEE | | Tue Nov 26 1991 16:18 | 1 |
|
|
1745.7 | depends... | TOOK::JEAN_LEE | | Tue Nov 26 1991 16:21 | 37 |
| Gene,
It is a good question. Yes, there is a logical explanation for its
behaviors too.
DNA4 AM entry modules always try to do two things before performing
the requested opeation:
1) resolve the global entity instance to DNA4 primary
identifier, phase4address.
2) make sure the global entity it deals with is NOT a cluster
alias.
The way it obtains the address varies, depending on the type of input
instance. If the input is fullname instance (as you showed in your
example), dna4 looks up the namespace. If .took is not registered at
the time, you will get "Node is not registered". However, If it is
registered or partially registered at this time, DNA4 AM then continues
to check if this is a cluster node. If is, you will then receive
a friendly message telling you to try one of its member.
My explanation for your experience in .0 is:
when you entered the first show command, .took is still
registered. Sometime later, it's deregistered. When you did
second show, it can't resolve the address from the namespace,
thur returned "node is not registered" msg.
Try different type of global entity instance, and try register and
deregister it, then show it. Let me know if you still are confused.
Jean
|
1745.8 | | SWORD1::ES | Eugene Shvartsman | Wed Nov 27 1991 12:22 | 52 |
| Jean,
I have to admit, that your explanation beyond my understanding:
> when you entered the first show command, .took is still
> registered. Sometime later, it's deregistered. When you did
> second show, it can't resolve the address from the namespace,
> thur returned "node is not registered" msg.
I cannot imagine why it's deregistered and how.
To be more specific about "sometime later" I would like to give more detail
about timing.
1) Issue command:
MCC> show node4 dec:.lkg.took
Using default ALL IDENTIFIERS
Node4 DEC:.lkg.TOOK
AT 30-OCT-1991 12:07:31 Identifiers
Specified Node4 is a Cluster Alias. Use a cluster member.
A cluster member = 4.33
2) Immediately after responce, recall the command and issue it again. You
will receive the same response with the same or different cluster member.
3) Repeat step 2) as many times as you wish. Result will be as in step 2)
4) Let it sit for 20-30 minutes.
5) Recall the command one more time and your will have the response "Node is
not registered"
6) Immediately after that go to DNS and you will see that it is still there.
I have two explanation for that:
1 - humorous
PhaseIV AM has built in AI into it and simply get annoyed to answer the same
question.
2 - serious
It is a bug in PhaseIV AM. Maybe related to timing somehow, but it is just
a wild guess.
Still puzzled,
Gene
|
1745.9 | let's try different theory | TOOK::JEAN_LEE | | Wed Jan 08 1992 15:58 | 29 |
| Gene,
>> I cannot imagine why it's deregistered and how.
When you indicated "try the same command later" in your first note,
it can mean any length of time later. It is possible that
the same node is deregistered by other people or other jobs before
you show it again. It is a possibility that we have seen happened
here and should not assumingly rule out.
But, the fact that MCC says it is not registered whereas you see it in DNS
raises the following question:
- where is the copy of the DEC: clearinghouse located? is it on the
same system that you are running DECmcc (that is, is it the default
namespace)?
I have tried the same commands as your described and couldn't resproduce
it. I also repeated it a few times, still can't.
Can you consistantly reproduce this problem? Can you send me a log that
includes all mcc commands and DNS commands? Please describe the DNS setup
more fully.
Thank you.
Jean
|