Conference azur::mcc

    What Entity Class are you trying to use?
    
    Note that they don't have Ethernet Addresses and are not manageable
    as such either?
    
    s/rob

    
    I tried it with the icon interface as follows:
    
    click on domain icon in toolbox. the create domain window comes up. On
    the bottom you can click on delni, dempr, despr or domain icon. Click
    on delni icon. Type in delni name (this seems to be the only compulsary
    field). Click ok. You are asked to position the cursor on the map. Move
    cursor to map and click. MCC comes back with message window saying that
    operation cannot be completed. Same for dempr and despr.
    
    Do I have to fill in some other fields?
    
    Timo

    
    Just tried it again, and I seem to be able now to add delni's dempr's
    and despr's through the domain icon in the toolbox. 
    Now how do I add these from the commandline? Are these companents
    considered as entity domain? (since they are shown in the create domain
    window)
    Is there a way to trace what mcc commands correspond with an operation
    that is done through the graphics interface? 
    
    Still haven't found a way how to get bridges on my map.
    
    Timo

  
>    Just tried it again, and I seem to be able now to add delni's dempr's
>    and despr's through the domain icon in the toolbox. 
>    Now how do I add these from the commandline? Are these companents
>    considered as entity domain? (since they are shown in the create domain
>    window)

 The command is CREATE DOMAIN <delni-name>

 At this time you only can drop entities which are registerable in the map.
 Creating a domain that is to represent a nonregisterable entity (in your
 case the delni) is one way to get around this.  That is why you see an 
 icon that represents a delni displayed when adding a domain. 

 We are going to allow the user to add a "Picture Icon" to a map in the v1.1+
 product.  The difference between the picture icon and the global entity icons 
 is that the MCC CREATE, REGISTER, SET REFERENCE, and CREATE DOMAIN MEMBER 
 operations are not performed. 

>    Is there a way to trace what mcc commands correspond with an Operation
>    that is done through the graphics interface? 
    
 The iconic map doesn't trace the FCL commands used.  The add operation
 does a 

	CREATE <entity>   if the entity has the create directive
	REGISTER <entity> if the entity has the register directive
	SET REFERENCE 	  if the entity has the register directive
	CREATE DOMAIN MEMBER	 if the entity being added is a global entity.

 The lookinto (double click) operation retrieves the child entities of the
 entity being looked into and then does a 

	SHOW <child-class> * ALL IDENT. 

/Jim

  

    RE: .3
    
    Most interesting...
    
    Doesn't the use of stuff like "picture icons" prevent applications from
    being written later to do stuff like auto-topology and physical level
    path tracing? It would be nice to have "real entities" to later apply
    Mark Sylor's "relationship" stuff to.
    
    Has any thought been given to resurrecting the REPEATER AM that was, at
    one time, "fronting" for transparent entities (allowing at least the
    naming and storing of Reference attributes for them?). It would seem
    to be easier to do this than to muck with conceptualizing them as
    Domains...

> We are going to allow the user to add a "Picture Icon" to a map in the v1.1+
> product.  The difference between the picture icon and the global entity icons
> is that the MCC CREATE, REGISTER, SET REFERENCE, and CREATE DOMAIN MEMBER
> operations are not performed.

Hummm...  I suspect you'll find that users will want to be able to keep
reference info on these things, so the lack of SET REFERENCE (and I assume
the corresponding SHOW REFERENCE?) may be a problem.  Is there any way to
add this particular functionality without causing yourself additional
headaches?

					Wayne

  There was talk at one time to have something like that.  It went something
like this...

Provide the MS for the reference entity. It would contain 
the architected reference global entity, along with the show, set, register, 
deregister directives.  It would need to support the identifiers and reference
partition.

The config fm (or a reference entity AM) would need to support the 
show <entity> all idents operation, which would return in_entity in 
out_entity.  The entity instance would be returne in the NAME identifier 
attribute in out_p.

The iconic map and FCL would not require any changes to support the above.


/Jim

    RE: 321.7  BARREL::LEMMON (and adding to 327.5)
    
    A Simple AM (as opposed to Sample AM :-) would definitely be the
    easiest way to go here.
    
    Config FM could treat the entity (or entities) that the AM supports
    just like it treats any of the others (well, any except TCPIP and
    NODE/NODE4). So could IMPM (we would need more icons...).
    
    You could even define entities (DEMPR, DELNI) that would "return" how
    many ports they had so that you could have reference information about
    them (e.g. Description of location of connection, maybe person(s)
    connected). This would even provide a hook for relating things
    topologically (assuming stuff like that ever gets done).

    my only question we, I though you had to be able to register it
    to add it to a map. So wouldn't the reference entity have to support
    register/deregister along with the set/show of reference attributes?
    
    

re: .9

Yup!