Conference azur::mcc

    I prefer having common map files. If they want to see the same bits of
    the network in a different way, this can be done by setting up
    different domains.
    
    It would also avoid a lot of "auto-placement" & unidentified
    "deregistered entity was filtered" messages.
    
    While we're on the subject of maps, one feature on which many of our
    customers insist is to being to scan existing maps and then drop icons
    on a specific map file. One of our customers is even planning to write
    an AM to drive a keyboardless station which will automatically display
    a scanned map of a building where an entity is located when an alarm
    rule fires on such an object....
    
    Regards,
    
    Philippe.
    
    

    RE .0
    
    I second that.    
    
    It would seem to make more sense to create all the map files in
    MCC_COMMON by default.
    
    With the current method the map files are created in the user's
    current default device and directory.  And the map file displayed is
    dependent on the user's current default device and directory.  
    
    MCC_MAPS is defined as -
    
    $ DEFINE/SYSTEM/EXECUTIVE_MODE  MCC_MAPS  SYS$DISK:[],MCC_COMMON
    
    In this way MCC_COMMON is search after SYS$DISK:[] but how could a 
    map file ever get into MCC_COMMON.

    On my system I redefined MCC_MAPS to -
    
    $ DEFINE/SYSTEM/EXECUTIVE_MODE  MCC_MAPS MCC_COMMON
    
    so all the map files are created in MCC_COMMON and aren't scattered all 
    over the disk.  And when I start the IMPM I don't have to think about
    what directory I'm in.
    
    Bill

Yet another vote for a single area for maps. Less confusion from user to
user and this also keeps the management focus of all users in the same
direction rather than stovepiping. MCC has plenty of flexibility to solve
user-to-user map needs without personal maps. 

best regards,
brad...

A single map is very desirable, but only if multiple users on diferent 
systems can access it.  That means that the map file pointer will have to
be contained with the domain object (e.g., in DNS as an object attributed,
ala notesfiles).   This is especially import in the 'sun never sets'
networks where control over the network maybe transfered as operations
staffs complete a shift.   DFS can also be used, but the ultimate model
is to associate the map file pointer with the domain object.

/Claudia

    I agree with a single map (simplifies lots of stuff).
    
    However, I strongly disagree with putting them in MCC_COMMON.
    
    I do not think that ANY files should be created in MCC_COMMON by the
    users of the system. Read/Write files are a big enough headache to
    manage protections/ACLs for in MCC_COMMON. The complexity that file
    creation adds is a mess. The exporter already has this and it is a real
    problem to set up a real production system where all users do NOT have
    lots of privs and where accountability is required.
    
    I would like to lobby for a new area (new logical too) for common
    files that MUST be created on behalf of the user that are not put in
    the user's own directories.
    
    s/rob

Ah, don't use a logical to point MCC at the location of some bunches of stuff
in files. Instead, define an attribute of some MCC entity.

MCC ought to be managed as an entity, we are telling all the other development 
groups in DEC to clean up their act and conform to the Entity Model. It
might make the case stronger if MCC didn't violate the rules willy-nilly.

Quick, can ***anyone*** list all the logical names that can be used to
Manage DECmcc.


I knew you couldn't ;-)

					Mark

A common map is highly desirable - however, it must also be possible for 
individuals to customise the way in which a given set of entities (i.e. the
domain in question) is presented to them.

I don't profess to know the ins and outs of DECmcc's use of map files, but am
simply stating what I believe to be an essential customisation capability.

Arguing for a single map only, is like arguing that all users should share
a single specification of window sizes, layout, colours etc.  Although all
users are dealing with the same set of entities (in this example the windows
of an application) they expect to be able to tailor their presentation.

Paul

    I vote to lose this feature, and here's why.
    
    In the documentation, we're trying to construct an "external myth"
    about how DECmcc works.  One of the statements we make is, in effect,
    that you only deal with maps.  The actuality is that you deal with
    layers of management modules, viz:
    
    		    A    <----- (the "eye" of the user)
    		Topology
    		Domain
    		Configuration
    
    		(network)
    
    We (well, I) don't want users to have to know about the layering, and
    have to deal with the "CDT" elements separately.
    
    Unfortunately, the way things are implemented right now, users do have
    to be aware of the layers.  Sometimes they have to manipulate one
    layer, sometimes another.  Having maps separate from domains is one
    example.
    
    So I conclude that deep-sixing this feature simplifies the external
    myth (and thus the user's "conceptual model") and is therefore A Good
    Thing.

I agree with Steve, the user is confused without a consistent "myth".

However, the "myth" is not the FMs, but what information a "map" is bound to.
Right now, a map is bound to a domain, which is bound to a "database".
That mapping is "right". But bindings can be 1 to 1 or they can be many to 1. 
(Think of a binding in this sense as a "function" like you dealt with in
college mathematics).

Right now, MCC allows more than one "map" to be bound to a domain. That is the
right answer, but MCC used the wrong binding. In fact what is needed is 
multiple maps, showing the same entities, but showing different relationships
between those entities. For example, you might show a domain of all the
Systems on a LAN, and in one map show the physical connections in the
LAN, and in anoother, show what systems are "load servers", and what
systems the load. A very different "map" but the same domain. MCC can't do
that today, but needs to. Note however, that *all* the users of each of
those two maps should probably see the same screen. Now, given that more than
one map is bound to a domain, how does the user state which map to use/display?
It certainly can't be the In Domain qualifier, that's insufficient information.
We probably need an "In Map" qualifier.

Similarly, MCC's 1-1 binding of a domain to a database is also fundamentally
flawed. Right now, the same entity has two different histories if it appears
in two domains. And there's no way to share those histories. This however, is
a bigger argument, one that requires a longer discussion.

Mark

re:-.1

Your approach is much like the 'layering' abilities of AUTOcad which I
have used to draw many maps. It works very well and allows the user to
view, or not view, whatever level of detail they wish. This detail is usually
divided or grouped by functionality in each layer. This keeps the overall
map understandable and manageable. If you take this tact, you will need to
add more complex drawing abilities to MCC. To zoom in and out on specific
sections and also increase the variability of size of entities and text.
Graphic clarity is very important once this type of complexity is brought
into a map.

regards,
brad...