| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1447.1 | Is the name in use elsewhere? | NSSG::R_SPENCE | Nets don't fail me now... | Wed Sep 04 1991 13:14 | 4 |
| Any possibility that the simple name is already in use for something
else (like a domain, a station, a bridge or an IP host)?
s/rob
|
| 1447.2 | Syntax, Maybe?. | KERNEL::OSBORNE | | Thu Sep 05 1991 07:57 | 7 |
| The syntax that I have used, and sorry if this is obvious or of no
validity with respect to the problem you have, is as follows;
REGISTER NODE4 dsp_ns:.DNA_NODE.nmsuvo SYNONYM=NMSUVO !IDP=49::-
ADDRESS=41.307
Dave.
|
| 1447.3 | Looks like .1 is right on.... | TOOK::CAREY | | Thu Sep 05 1991 11:09 | 50 |
|
Steve,
The "inconsistent class error" is usually a DNS problem....
.dna_node.tesla is apparently already in your Namespace, known to MCC,
and the name of a different entity.
The easiest way to find out is to try the fullname against each of your
global classes:
MCC> dir NODE .dna_node.tesla
MCC> dir SNMP .dna_node.tesla
MCC> dir STATION .dna_node.tesla
.
.
.
If you scout around in the namespace using DNS$CONTROL or something
similar, remember that the SNMP stuff is under a "hidden" directory,
MCC_IP. MCC thinks that MCC_IP.dna_node.tesla is the same as
.dna_node.tesla.
I don't know what kinds of quirks you may be hitting because of the
different IDP.
If you'd like to further check out the DNA4 AM on this problem, you can
try the following commands to the AM to ensure that access to the node
is working okay:
MCC> SHOW NODE4 tesla all ident
MCC> SHOW NODE4 tesla circ * all ident
MCC> SHOW NODE4 tesla line * all ident
MCC> SHOW NODE4 tesla circ * all char
MCC> SHOW NODE4 tesla line * all char
These are the requests the the Registration FM makes to us when
registering a Node4. If these work, then the AM is very likely
handling its part of the job correctly.
When you do the SHOW NODE4 tesla all ident -- make sure that the name
that comes back is Tesla. We ask the actual node4 indicated to tell us
what *it* thinks its name is. If it has a different opinion (say
someone traded names but not addresses), then there may be another set
of considerations.
Hope this helps.
-Jim Carey
|
| 1447.4 | Parse Table rebuild was the Answer | CSC32::WOESTEMEYER | Why??...Why not!!! | Thu Sep 05 1991 13:03 | 7 |
| Don't ask me why, but the fix was the rebuild of the parse tables. As
soon as this was completed the customer had no problem registering his
NODE4 entities.
Any ideas??
Steve
|
| 1447.5 | Parse table rebuild? | TOOK::CAREY | | Fri Sep 06 1991 17:54 | 20 |
|
Nope, no clue at all.
I was going to guess that an attribute partition got incorrectly
redefined so that the Node4 requests were failing. Say the
characteristics partition got itself assigned a different id. Then the
DNA4 register would fail, but others might succeed.
However, I think the Bridge AM also queries characteristics during a
register (is that right, Chris?) in which case I just offered nothing
at all.
I put this in hoping something would tumble for somebody.
Steve, is there anything extra in this MCC? New AM, FM, PM? Even
something we gave you that isn't part of the BMS kit might have a
strange problem in it, and that's all I can think of.
-Jim
|