Conference azur::mcc

    
    Roland,
    
    There are several aspects to this.  
     
      1.  How does it look on the screen.
             A couple possibilities:
    
            - One icon can be exploded into many or many condensed into
              one by some motion of the mouse buttons.
    
            - The icons can be stacked/offset from each other.  If
              the user wanted to deal with an entity using one of the
              icons on the bottom of the stack, they could pop the one
              they wanted to the top.
    
            - The icons could be put in a box of some kind (I'm winging it
              here) and the box could serve as the master icon...Could
              get ugly. 
    
      2.  Mechanics to accomplish the plurality. 
             What, if anything, does the user do?                          
             Un-thought-out.
    
      3.  How is this plurality stored?
             Don't know...  Others are working on this.
                               

    Icons within icons would help - to both display an entity's abilities
    and even status of different functions.  One issue is around naming.
    While the entity might be the same box, it may be known by different
    names to different protocols.  For example, it's IP and DECnet name
    could be different.  My opinion is that the separate display of 
    multiprotocol entities is ok, as long as the ability to display it once
    and zoom into it's different functions is allowed.  ie, if I want to 
    have a map of all IP systems, yet once troubleshooting an IP host, I
    need to use the Ethernet-AM to do a 802 loopback, I should not have 
    to change domains and icons.  
    
    bill

I see, there are many many ways to go. But You all know, normal a customer wants
everything, everywhere and everytime. The customer I gave demos, normaly want
everything on one map. They want a map of the real network. So there are 
stations, snmp, phase VIV, .... on the same ethernet. There are also single 
nodes reflected from more than one icon. So you have (i.e. three icons) group 
together, that everyone know, that this is physicaly one node.

I think we will try to display one node (two or three icons) with the icons 
close together connected with one line to the Ethernet.



				Roland

    Another point that gets to be a problem is that when you have a single
    computer that can have multiple protocols (DECnet, IP, 802.3, LAT,
    etc), not only do you have many icons (which is kinda awkward) but you
    have to manage multiple sets of referance info.
    
    When I was a network manager I would have wanted one set of referance
    info that got me to the owner of the box, not the owner of a protocol.
    
    s/rob

    If I'm not mistaken, Wally Mathers is thinking along these lines in
    trying to solve some of the problems inherent in auto-topologizing.
    
    The last I talked to him, we discussed the notion of a "SYSTEM" global
    entity.  System in the Its-what's-on-to-of-my-desk sense.  A system
    is a collection of physical and logical components.  
    
    At this point, I'll stop putting words into his mouth!
    
    Fred

    I would to have you think about one more thing when looking at this
    "problem". So far the notes here have discussed the different views
    of the physical box, as portrayed by their protocols on the network.
    That is fine, but what do we do to the picture when we start wanting
    to think of the "SYSTEM" not as a box, but by the application it
    runs (like this "SYSTEM" is a nameserver).
    
    As more management modules get incorporated into MCC, we will start
    to really make use of the potential of the mcc, and the goals of
    EMA for a truely integrated "Enterprise Management" system. As we
    do this more and more application management modules (I believe)
    will become available and MCC will be for the management of the
    whole not just the phsical network entities. As this happens
    what happens to your definition of "SYSTEM", do you expect it to
    grow or are you expectations that "SYSTEM" only means the network
    object.
    
    Now, as to whether you think that this applies to the discussion
    or not I am not sure. It just seems to me that mcc will always have
    to have multiple views of the "network". No two managers view things
    the same way, and no two should have to. the question is what kind
    of flexibility can we give them when "designing" the mcc view of
    the network...
    
    
    
    
    

 This note raises two issues:

  1. How does all this stuff will look on the screen. An implementation issue...
  2. How MCC will allow users to manage all this stuff. The architectural
     issue.

 At this time, MCC is mainly NETWORK oriented, not yet ENTREPRISE or SYSTEM 
 oriented. Global entities are NODE4 or BRIDGE... But is NODE4 a real global 
 entity? I really think that "SYSTEM" would be a better global entity, with
 physical and logical components. NODE4 is only one aspect of THE MANAGEMENT.

 Let's go deeper into the MCC architecture. Suppose we want to develop an access
 module to "monitor" system ressources and hardware (error counters...) thus
 allowing the generation of alarms (something like the well-known DCM...).
 Could we define a "SYSTEM" global entity which would include our new entities
 (devices, processes...) as well as NODE4 as child entities? I think we cannot
 do it at this time so we will have to declare all the "nodes" twice, once to 
 "see" them as NODE4 and once to "see" them as a collection of ressources and 
 hardware. And we will see them twice on the iconic maps. This could be fine 
 if we support the WYSIWYWTS (What you see is what you want to see) which is
 one of our customers' favorite products. But multiple declarations are really 
 an issue...
 
 Another idea for our monitoring or system modeling problem would be to add 
 new attributes to the NODE4 entity thus making it looking like a real 
 SYSTEM... Is it possible in the current MCC architecture?

 Serge

	Hi All,

	Within a network you have some specialized CPUs and some multi-
	purpose CPUs.  DECmcc is very capable when dealing with what looks
	like specialized CPUs.  Therefore, multi-purpose CPUs are managed
	as a number of specialized CPUs.  From a systems/network managers
	point of view, there are "boxes" on the network.  Some of these
	boxes perform many tasks, but are still a single box (and are usually
	managed that way).  Therefore, having a box, or SYSTEM, represented
	only once on a map is more accurate to the real world.  As customers
	flock to DECmcc, like I think they will, systems/network management
	personnel will be reduced, placing more of the management respons-
	ibilities on fewer people.  These fewer people will be, more than
	likely, responsible of all aspects of selected (or all) SYSTEMS on
	the network.

	In an earlier note, someione mentioned the use of the DOMAIN AM to
	represent these SYSTEMs.  This is not a bad stop-gap idea, but is
	limited to what the DOMAIN FM is willing to allow you to save about
	SYSTEMS.  A better alternative is to have a SYSTEM FM, which is very
	similar to the DOMAIN FM, but is specific to the managing of a system
	(ie: it can deal with all the network protocols the SYSTEM supports
	as well as the operation system running on the CPU).  It is also better
	suited to the ACCOUNTING aspect of management (which DECmcc will
	support in the future).

	What do you think?

	~Jon.

    I currently have several domains that I use to cope with this problem.
     The Idea that a network can be sliced several ways across the "ISO"
    layer stack plays as very usefull.  I show nodes in a domain "physical"
    and look for a cable or physical plant problem.  Then I show the
    same nodes at the "DECnet phase IV" level in another domain, looking
    for a "problem" at a higher level.
    
    When there is a clear seperation between functions, and there is
    a small (2 here) number of functions associated with a "box" this
    works quite well.  As the number of functions increases (add TCP/Ip
    and/or non-network application management, etc, etc) some method
    that will associate all of these funtions with the same "box" becomes
    very necessary.
    
    Some kind of "system" icon or "Multiprotocol" icon seem to be needed.
    
    Regards,
    
    Glen R.
    

The Node class of global entities was *intended* to be the thing you call
the System. For various reasons, some political, some due to our not
understanding all the implications of some seemingly trivial decisions,
it didn't quite work out that way. I expect by V2 (of the EMA architecture)
that this will be clarified and 1 Node=System global entity class will
subsume at least:
	Node
	Node4
	SNMP Node
	OSI Node
and possibly
	Bridge
	Terminal Server
and others.

Note that at least all of the VMS system management will be done as a part of
the Node entity (either as child entities or additions to the Node, even for
a whole cluster). Also OSF/DME based management should (I expect) fit within
this System=Node entity.

Anyone developing a new "system" like global entity should think very hard
before defining a new global entity class, and be aware that they may have 
to redesign it.

So eventually, you should see the effect you desire.

					Mark

    This is a big subject with many side issues. Let me start by saying
    that I think Mark Sylor is heading in the right direction but he
    thinks he has to go to the end of the next block when from my
    perspective he has to go to Bangkok. Let me give you my view.
    
    We have the OSI reference model for use in networking and communication
    but lack the same type of reference model when we talk about a computer
    system. We have to ask ourselves what does the user really mean by a
    system. The answer is that the user means many different things when
    he uses the term "system" and munges them alltogether into something
    that defies analysis. The system is the collection of boards, cables,
    boxes, power supplies, and cabinets that he points to as "his" system
    or as ANCHOR. The system is the operating system that is resident on
    the collection of hardware and appears to the user(s) as a single
    instance of an operating system that may be multi-user, multi-tasking,
    multi-processing, multi-???. The system is a collection of files and
    applications which are at any time resident on set of hardware and
    operating system(s) and which perform functions that the user wants
    to have access to. This last system can be moved to an equivalent
    collection of hardware by moving the files there and activating the
    operating system. Take your pick they are all the system. 
    
    We need to develop a reference model for the system similar to the
    one that ISO developed for communications. There is a physical level.
    There is a driver/level in the OS which interfaces with the hardware.
    There is the kernel level of the OS which ties the collection of
    drivers to the upper level components in the same way that the
    network level of the ISO reference model ties together a network.
    There needs to be an account level which is a user's access into the
    system similar to the Session layer in ISO. Decwindows, etc. provide
    anologies to the ISO presentation layer. I don't claim to have the
    layers right or that the boundaries are where I suggested. But I think
    by now you get the picture. 
    
    The user of an iconic map, depending upon his current role will want a
    map at one of these levels of the system and/or the network. Trying to
    display all these levels on a single flat map is madness. When the
    user is doing hardward fault isolation, he will want a physical view.
    When he is managing the VMS operating system he will want to have a
    logical view of VMS. When he is managing the various communications
    facilities that may be available in his OS, he wants to choose which
    one of them he is working with (ie. the protocol stack is subordinate
    to the Operating System). In other words, a user will want to change
    the level of the display to match his current "role". I can see a
    user's role as managing a set of application level clients and servers
    which are layered on one or more protocol stacks. This user doing
    routine monitoring will want a simplified graphic model of the clients
    and server relationships. If there is a problem, he/she may want to
    an expanded picture which includes additional views of the protocol
    stacks. After further isolation, they may actually get down to the
    level of hardware. 
    
    Mark is currently working on integrating the concept of multiple
    protocol stacks under a single concept called a NODE. I think he
    needs to expand and include management of the OS, its drivers, data
    bases, applications, etc. When there is a System Reference Model
    which supports all the various layers of a system and it provides
    within its containment structure the agents that we need to access
    to manage the components of a system, then we will have a solution
    that meets the users visual representation needs for a system.
    
    It will be V3 of the EMA architecture or beyond for it to evolve but
    in the interim, DECmcc is exploring simple "system containment
    relationships" which provide a rational view of the many facets of
    a system to a user. I don't want to set false expectations. Currently
    this is an ad-hoc advanced development with no committed product
    deliveries. If it is of value, some of the concepts will be used
    in future versions of MCC to rationalize the users view of the
    system.
    
    wally matthews (alias mathers or anything except late for a meal)