Conference azur::mcc

    ref. 0
    
    >Also, I had added a node into the DNS space using RSM ADD CLIENT (that
    >was displayed in the DNS tree), but on the mcc node when I do a DIR
    >NODE4 of the node, I get back
    
    >No such entity: node4 nybs2
                             Unknown Entity = Node4 nybs2
    
    >Is there something wrong with what I am doing ?
    
     
     This is the way DECmcc works. If a DNS  object is created through DECmcc,
    MCC writes MCC_CLASS (the entity class value) as an attribute of that DNS
    object. When DIR command is issued,  DECmcc reads the DNS objects
    and verifies  the    MCC_CLASS values stored along with the DNS objects
    before passing results to the user.
    
     If a DNS  object is  created  using tools other than DECmcc, the 
     MCC_CLASS attribute would not be stored along with that object. 
     Therefor DECmcc DIR command will not recognize that DNS object and
     will not include in the returned results. 
      
     When the return result for a DECmcc DIR command is a null set (not
     even a single entry matches the specification) the user gets 
     that "unknown entity error". In your case you probabily had only one
     object of this kind and that too did not match the specication which
     in turn displayed that error message.  
    
     Try Registering this DNS object from DECmcc. That should be successful
     even though it already exists in DNS. In this case, DECmcc just adds
     some MCC specific attributes (like MCC_CLASS, MCC_VERSION etc.)  to
     this existing DNS object. Then if you isse DIR in DECmcc should
     display this object. 
    
    
    >I have a 6310 acting the DNS and RSM server, while mcc is installed on
    >VS3100. On the 3100, I do a REGIS NODE4 .TREASURY.SALES.NYBS3 SYN NYBS3
    >and this promptly shows up in my MC DNS$TREE_DISPLAY. But when I try to
    >either show or modify or add the same node name in RSM (to modify the
    >ethernet address), they all fail.
    
    Looks like RSM is not  recognizing  the DNS objects created by DECmcc. 
    Looks like an RSM bug..... I am not sure.
    
    Jesuraj
    
    PS: By the by, what is RSM? ( REMOTE STATION MANAGEMENT ???)
    
    
    
                                                     

The DNS$CLASS for RSM objects is RSM$something  (server/client)
while DECmcc uses  DNS$CLASS of DNA$node.   RSM also adds 
a bunch of its own  RSM$xxx attributes to the object.  DECmcc
does use MCC_CLASS, but RSM will ingore that.  The real killer
here is that their DNS$CLASS object attributes are different and
the DNS$CLASS is a single valued attribute, not a set of values.
That makes it unshareable between RSM and DECmcc.   During the 
registration process each application attempts to create the
DNS object with its special brand of attributes and DNS$CLASS
and they fall over each other in the attempt.
  
Because of this RSM (Remote System Manager)  objects will never 
be able to share names with DECmcc objects.   It's not a bug, 
it's not a feature either.  It's the way RSM was implemented.  
RSM will have to be recoded to conform to the architectural 
agreements contrived by DECmcc and the DECnet/OSI programs.  
Don't expect this realignment until RSM becomes EMA compliant.  
Until then, you will have to register two DNS names for each node, 
one for DECmcc and one for RSM.  

/Claudia

Hi,

I have a customer with the following scenerio.

One node running VMS V5.5, DNS V1.1 and RSM V2.3-bl6.1.  Another node operating
as a DNS client which has DECmcc-BMS V1.1.0.  She had deregistered a node under
DECmcc and RSM could nolonger access it (couldn't find the node in DNS).  She
registered the node again, using DECmcc, and RSM still could not find the node.

We ended up deregistering the node in DECmcc, doing an ADD CLIENT for the node
under RSM and then 'successfully' registering the node under DECmcc again.
Everything (RSM and DECmcc) appears to be working successfully with identical
names being used for both products.

Any ideas, comments?

Walt

    
    RE: .3
    
    The DECmcc uses DNS$Class attribute value of "DNA$Node" for Phase4 and
    Phase5 DECnet nodes while the RSM uses a different value.
    Any Phase4 and Phase5 node that DECmcc registered cannot be seen
    by the RSM since the DNS$Class attribute value is different.
    
    
> We ended up deregistering the node in DECmcc, doing an ADD CLIENT for the node
> under RSM and then 'successfully' registering the node under DECmcc again.
> Everything (RSM and DECmcc) appears to be working successfully with identical
> names being used for both products.

    Note that a wildcard lookup of RSM objects from DECmcc would not
    work on your RSM objects since DECdns requires the DNS$Class attribute
    value for wildcard operations (e.g. MCC> dir node4 .midwest.*,
    MCC> dir node *, MCC> show node4 * all ident, in domain .foo).

    William

Are you saying that adding the client through RSM and then registering the node
through DECmcc should work and not cause any problems even though the RSM name
and the MCC node synonym are the same?

Are there other problems we should be concerned with when having a common name
between to different applications (RSM and DECmcc)?

Walt