Conference azur::mcc

    Only a few situations where things get renamed come to mind. They are:
    
    A bridge fails and the FRU (field replacable unit) is a new bridge with
    a new ethernet address. In this case I would expect that the address of
    the bridge would be renamed since people are likely to use the name
    of the bridge more often than the address once they have DECmcc to help
    them with it. In this case is the UID associated with NAME of the
    bridge or the address? One would certainly want to retrieve historical
    info for "the bridge doing the function of connecting x and y" rather
    than retrieving info for the bridge with the address nnnnnnnnn.
    
    An application system is moved from one building to another and so gets
    a new "Full Name" while perhaps keeping the synonym. Network management
    wants to track traffic on the system without reguard for where it is
    located on the net.
    
    A user gets a new workstation (with a new ethernet address of course)
    but wants to reuse the old name. This should be like the bridge example
    above. ?? Is the ethernet address tracked for a decnet node ?? In
    this case, how would network management assist asset management in
    tracking where the old system went?
    
    Anyway... These are a few senarios that I would expect to be very
    common. Whatever happens, make sure historical data can be correctly
    retrieved.
    
    Also, I agree with .0 that we need to reduce the dependancy on "rooted
    directories".
    
    s/rob

If the only current reason for UIDs is for when an object is renamed, 
what exactly is the need for the MCC_UID directory?   I presume it goes 
something like this:

	SHOW obj .dir.foo all status from 1-apr-1990 to today

At some point, MCC looks at object .dir.foo and grabs the MCC_UID attribute - 
which it gives to the Historian to do the past query?  And this gurantees that 
I get all the information about the object, even if it was once named .dir2.bar?

At what point does anyone go to the .MCC_UID directory to get the name back?
I assume you can't get the name the object had in the past, because the softlink
is pointing to the new name.  When you rename an object, does the MCC_UID get
copied from the existing object?  Or is this when the MCC_UID softlink comes in?
Or does the old names .MCC_UID get modified to point to the new object, which
now has 2 softlinks?  That's the only case I can think of where you'd need to
do that backtranslation.

Maybe I've done something wrong, but I've registered a couple of nodes, 
successfully I thought with V1.1.  They seem to MCC_UID attributes, the 
.MCC_UID directory is empty.  I haven't done enought work to see if this will 
cause me problems.

Anyway, if they're truly necessary, and they have to be in a single, root-level
directory, I'd vote to make them optional.  However, I could see benefits for
having the default for creating the .MCC_UID softlinks on a per class basis.

_Mek

    ref .-1 
    
>At some point, MCC looks at object .dir.foo and grabs the MCC_UID attribute - 
>which it gives to the Historian to do the past query?  And this gurantees that 
>I get all the information about the object, even if it was once named .dir2.bar?
    
    
 Yes !! it is true
    
    
>I assume you can't get the name the object had in the past, because the softlink
>is pointing to the new name. 
    
    This is also true, as we do not track the names. We use it to track the 
    objects independent of its current name.
    
>  When you rename an object, does the MCC_UID get copied from the existing 
    object? 
    
    Yes,  MCC copies the MCC_UID attribute when rename takes place.
    
> When the MCC_UID softlink comes in?
    
    MCC_UID softlinks are created by MCC when the global entities are
    registered.
      
> Or does the old names .MCC_UID get modified to point to the new object, which
  now has 2 softlinks?
    
    
  No! We have only one softlink, that points to the new name, but has the
    old MCC_UID.
                                             
>Maybe I've done something wrong, but I've registered a couple of nodes, 
>successfully I thought with V1.1.  They seem to MCC_UID attributes, the 
>.MCC_UID directory is empty.  I haven't done enought work to see if this will 
>cause me problems.
    
    Seems to be a problem here. The DNS code in MCC creates the MCC_UID
    softlink as a part of registration, and it complains if it could create 
    one. By the by What vesrion of the software are you running?
    
    If you test with no MCC_UID softlink, you may not see any problem at the
    moment, as no management module (except possibly historian) uses that
    soft link.
    
    /jesuraj
    
    

>     By the by What vesrion of the software are you running?

DECmcc (X1.1.0)

I believe it's the most recent kit.

I'm chagrined that I don't have a log of the registration, but I'm quite sure
there were no error messages.  I can delete/deregister a node and try again if
it's important.

I'm still trying to clarify when there might be a need for backtranslating from
.MCC_UID to the object.  Details on how the Historian does (or doesn't) do this
would be very helpful.  I know that the use of the Historian is crucial for
DEC's internal use of DECmcc, so if the Historian really uses the softlinks in
the directory, most managed objects will need to have entries.


_Mek

    DOn't forget that there will be no objects in the MCC_UID directory,
    only LINKS. You have to look with DNS$CONTROL by doing a
    	SHOW DIR .MCC_UID KNOW LINKS
    
    s/rob

Thanks Rob, my mistake.  I keep forgetting that DNSCP need to be told what type 
of thing I'm looking for...

I think  this  "feature"  of the historian is a mis-feature.  When a manager
Renames a global entity you can't tell automatically what the right thing to
do  is.   See the discussion in the NETMAN architecture about Node names and
Node identity.  In some cases the user is thinking of the hardware when they
use  the  name,  in  other  cases  they  are  thinking  of  the  application
environment,  in  other cases they are thinking of the physical location, or
the network location, or the terminal they use, or ...

If a Node has been Renamed, it is not at all clear what the manager wants to
see  when they ask for historical information and give the name.  They *may*
want information about the same system when it had a different name (and was
probably serving a different function) or (much more likely in my view) they
may  want information about the system which had that name then, or they may
want  information  about  the  node  which  has been performing that logical
function (routing, say) before, or anything.

You can't win if you try to second-guess what the user means by names.

Graham

I've reread this discussion, and I can't figure out any reason why the
MCC_UID need be stored in DNS as a softlink. While the feature of allowing
a entity to have data retreived/stored over time, independant
of the name of the entity makes sense, this can be accomplished simply by
tagging every record in the instance/attribute database of MCC with the
UID of the entity. Ben England and I discussed this at length back when the MCC
database was designed, and that ws how it was planned to be built. Why
was this changed?

				Very confused, and I invented this feature....
				Mark

    RE:.8
    Dear Inventor of Features,
    
       My understanding was that certain MM's needed to ask the question,
    "Given a UID, what is the entity which owns it?".  Assuming the question
    needs to be asked, how else could it be answered?  Note that these are
    ``MCC'' UIDs not DNS UIDs.  I think looking at every entity until you
    find one with a matching UID is little too much.
    
    -Matt.

That was what I understood. At one time, the MCC instance database was 
keyed by UID as well as by entity name.

OH, I get it, the MCC Instance database was moved lock stock and barrel
into DNS wasn't it! That's where this came from!

This will get fixed when we have a real configuration database.

    About Graham's concern... A long time ago when I was in MCC and had all
    of my hair, the entity instance database had a historical component, so
    that MCC could let the user know whether this machine called TOOK::
    actually was always named TOOK, or whether it used to be named BOEHM. 
    It could also tell you if a bridge had a different hardware address. 
    The guiding principle was that to precisely specify an entity, you had
    to provide its unique identifier and the POINT IN TIME when that
    identifier was valid.  In most cases users are interested in time NOW,
    but there were cases where a user might want to refer to the machine by
    the name it had then.  Graham's concern disappears somewhat in that
    case, because if there is any doubt about which entity to reference,
    the user has a way to figure out which one is the right one, assuming
    that the data exists in the system.  
    
    Certainly DNS is not a good place to store historical data.
    However, I had thought that DNS would be used a way to distribute
    information about the CURRENT identifiers of an entity, and 
    that some form of database (e.g. the MIR) would
    be used to handle the historical component of this data.
    
    The schema was relational in nature, whereas the DNS is really a
    hierarchical database.  So some of the lookup techniques used  in the
    MIR schema won't be appropriate for DNS.  For example, UIDs were to be
    used as b-tree or hashed indexes, definitely NOT for linear search!
    Whereas DNS has softlinks, etc.
    
    					ben
    

    Not obsolete thoughts...
    
    That's exactly what we do.  The historical database keeps entity
    existence information along with the attributes.