Conference azur::mcc

    Kelly,
    
    The FDDI FM registers all of the nodes on the map as class FDDI station.  
    So you will have to change the nodes yourself if you want to manage
    them as a different class.
    
    Bob 

    That's my question - how do I go about changing them?

    The only way I know of is to deregister the FDDI node and then 
    go to the toolbox and re-add the node as class concentrator, bridge
    or whatever.  If anyone has a better way then please let me know.
    
    Bob

    Oh, great.  So I have to write down each address, delete the entry, and
    then type it in again.  That's what I call user friendly.

    Kelly,
    
    I understand your frustration.  But it isn't so simple to have
    autotopology know all this.   For example, there is no  way to determine 
    that a SAS is a bridge from the SMT frames.   Even in the case of 
    concentrators there is no easy way to tell that it is a DECconcentrator
    500 (which is what the Conc AM supports).   I suppose we could blindly
    poll each device on the ring with a list of protocols to see if they
    are supported.
    
    These are the kinds of problems that we are trying to solve.  
    
    For now instead of writing down each address, use the autoregistration
    script generated from the autotopology run.  Simply change each
    register command to a deregister command then add a register command
    for the new entity class you want to use.    
    
    Bob

    I understand that figuring out what something is just from knowing its
    presence on the LAN is not necessary easy.  
    
    I am just suprised at how difficult it is to "move" things around.  I
    mean changing something from a "fddi station" to a concentrator.  So
    sort of expect this to be an easy operation.  Modifying the command
    file is certainly easier than doing it by hand - thanks for the hint -
    but is still more complex than I expected.
    
    The autoregistration script.... If I make it deregister each and then
    register them again, will that blow up the map or just change each of
    the things on the map?
    
    Oh, one more thing - at least with the ones it finds that are DAC -
    this means dual attach concentrator - why not ASSUME it is a
    DECconcentrator?  That would at least save me some of the work.

    It looks like you will have to use the IMPM to keep the same map
    location.
    
    If you use the FCL to add the members to the map they will not be
    placed where they were as FDDI stations.  If you want to maintain the FDDI 
    map you will have to use the toolbox to delete and then replace at the same
    ring location.
    
    
    
    

                                                              
    You could do a little bit of both:
    
    Open the domain in question from the IMPM.
    
    Make a snapshot of the map file you wish to doctor.  (Select File->Map
    Snapshots->Save)
    
    In the window which has the domain opened, deregister (and remove from
    the map - use the toolbox circle with the double line) the FDDI stations
    which you would like to replace with something else. 
    
    Save the map file.
    
    Then execute your newly edited registration script to re-register the
    stations you deregistered (only now they will be registered as some
    other entity).
    
    Then open the domain (again) in the IMPM, pointing to the original map
    file.  You will get a "map file mismatch" message -- entities found in
    the domain but not in the map file.  The entities listed in the
    message box will appear in the upper left corner of the map, all
    in a row, possibly placed over other entities in the map.
    
    Open the map snapshot (File->Map Snapshots->Read) which you saved
    before.  This will be your guide as to how to move those entities in
    the upper left corner to their proper location on the map. 
    
    What does this save you?  You can register the entities in batch
    and do only half the work in the IMPM to place them.  Moving existing
    icons should be faster and easier than re-registering all the entities.
    
    Ulla
    

I just want to understand the base requirement.

You want some sort of "Transmogrify" operation (action) that can be applied
to a registered entity that will turn (say) a FDDI Station into something
else, say a Terminal Server. Is that an arbitrary transmogrification, or are
there limited things you want to transmogrify?

A general transmogrifier would be hard to build. Specific transmogrifiers
are reasonably straight forward I should think.

Mark

    The case I have experienced so far (but my experience is rather
    limited) is that I want to change an FDDI station into a Concentrator
    or a Bridge or leave it as a station.  
    
    I guess you might also want to change an ethernet station into a
    terminal server.
    
    In the case where the station is an end-system with an FDDI adapter,
    I'ld really like to be able to turn that into a Node 5 or a Node 4 but
    then I loose the ability to talk to it as an FDDI station, don't I?
    
    

This is  closely  related  to the need for DECmcc to handle a single icon on
the  map  representing  several  different global entities.  A Wave 1 system
running UCX could be a Node4, Node5, SNMP and Station all at once.

It should  be  possible  for  a  single icon to have multiple personalities,
representing  several global entities.  Looking-into the icon would show all
children  of  all  global entities, looking at the attributes would show the
attributes  of  all  the global entities, etc.  It should be possible to add
and  delete  personalities  from  an  icon.   Then  you would be able to let
auto-topology  run,  create  the  stations  and  then *add* Node4 or Node or
whatever  personalities,  supplying the information needed to register those
personalities.

Graham