Conference azur::mcc

Darryl, For many people some of these comparisons might be a bit confusing.
My two cents are from the angle of need/use.

The script AM is for getting info into MCC that can be used to generate
rules on the data. It does require you to write a script to perform this
function as well as defining the data.

The data collector can be called directly from the operating system prompt
and does not require any data description. In its' simplist form this is
easier to use than even the launch application, but it limited in funtionality.
As you add more intelligence into your use the collection AM you will find
that you can use it to create command procedures capable of using the operating
system to pass in more intelligent information (like the disk space example
given in this notes conference), and again unlike the script AM this doesn't
require an information modeling, but is limited to passing in an event to
mcc (not overlly useful with rules). If you want to you can write your own
application that makes use of the C api's for the collector to send in data
(events) to mcc, this would be more work and is associated with the script AM.

So, the collection AM is only as hard to use as you want to make it. In reality
is provides you with a range of complexity from the easist open interface to
use to one only slightly more difficult than the script AM (and that is
subjective, since a person who can write C and not DCL or shell script would most likely
disagree).

Example of collection AM at is't simplist:

send:==$sys$common:[syshlp.examples.mcc]mcc_evc_send.exe
send goste collector1 "node4 goste" "title" "description" major

I concur w/Jill.   

It's *easier* to do Data Collector events than Script AM stuff.  Hells bells,
it's even easier to do than launched applications.  However:
	1) data collector events are 'one way only' (that pretty much defines 
	   an 'event',  huh? ;^) ), and 
	2)  you can't reliably create alarm rules on data collector events,
	    since they only have *one* event ID in the MSL (General Event)

Here's *my* version of your chart...

    
              ----------------------------------------------------------------
        I     |                                                       *      |
        n     |                                                       *      |
        t     |                                                       *      |
        e  C  |                                                       *      |
        g  o  |                                                       *      |
        r  s  |                                                       *      |
        a  t  |                                          *            *      |
        t     |                                          *            *      |
        i     |                                          *            *      |
        o     |                                          *            *      |
        n     |                               *          *            *      |
              |      *            *           *          *            *      |
              -----------------------------------------------------------------
                Iconic Map       Data       Script    Callable        MM
                  Launch       Collector      AM         MCC     Development
                                           
                                   Degree of Integration


P.S. There should also be a 3rd axis (better bone up on your favorite text
editor before trying to put it in here, though) that should be pointed out:
'leverage-ability quotient'.  I.e. the amount that application is able to
leverage the services supplied by the other MMs in DECmcc divided by the effort
required to develop it.   (I think the Script AM gets highest marks for 'LQ').

  To continue with the "DECmcc Simple-Integration 101" course ... 8)

    Note:  The examples below use the modified entity model where the
           Script AM is a Global Entity (next IFT kit out will be soon).

  The Script AM has three levels of integration of its own:

  o Loosly-Integrated:

    You don't write any MS at all .. the Script AM simply executes your
    command and returns the data to DECmcc.  The Attributes are pre-named
    by the Script AM for you, as: arg1, arg2, etc...

    On Ultrix, this is great because your 'simple' command can be a
    shell contortion with grep and all those other goodies.  Complex
    shell incantations can be stored in the Script MIR so you don't have
    to remember and type them each time.

    Ex:  Show Script x Command "df" all status

  o Moderatly-Integrated:

    This is were you write your MS file which describes your child entity
    under the Script AM and its attributes, by name and datatype
    (Latin1string,Integer,Real).  You can still store any complex commands
    in the Script MIR.

    Ex:  Show Script x Disk cluster all status

         This example would look up the command to execute in the Script
         MIR.  For example, the Script command might be "disk * 0 noheader"
         (as works with the VMS disk script template).

  o Tightly-Integrated:

    This level of integration will allow you to specify *any* entity model
    and any directive; the other Script integration techniques use a fixed
    entity model and only the 'show all status' directive.

    Tightly-Integrated scripts could, infact, replace Management Modules all
    together (certain restrictions apply - your mileage may vary).

    Did you notice the "will" above?  This level of integration is not yet
    available.  If there is enough interest in such a capability then it
    "may" be completed for the next DECmcc release.

  Class dismissed.

  /keith

    
    Although it's not strictly integration to the director, it would
    be useful to include the common agent capabilites in this matrix. 
    
    I see that the script am has some great possibilities, but it overlaps
    with the common agent in the DEC base (ULTRIX,VMS).
    
    We need to clarify the positioning of these, and prevent the too many
    options syndrome.
    
    Dave.
    

>    We need to clarify the positioning of these, and prevent the too many
>    options syndrome.

Key differentiator:

    The script AM is not 'remote-able' whereas stuff managed via Common
    Agent technology *is*.   I.e. Script AM can only return data from the
    'local' MCC system (note I am disregarding clever 'rsh' hackage one may
    be tempted to implement as a poor-man's distribution...)

    /doug

I would be interested in more information about the Data Collector and
the Callable MCC options.  Are the documents someone could point me to?
			thanks	lynn

The mcc interfaces are defined in the SRM.
The Data collector AM is described in the MCC doc set, too.

> The mcc interfaces are defined in the SRM.

    See the DECmcc Management Module Programmers Guide (Ch 4, I think talks
    about 'callable MCC')

> The Data collector AM is described in the MCC doc set, too.

    See Ch 8 of the Alarms and Notification Services Use Manual for more
    detail on the Data Collector

	RE: .4,

	Can someone update the graph in .2 to include the Common Agent/DNA
Phase V AM?  I think it is just befor the MM development but I would be
inetrested to see what other peiople think.

	Carl

Common Agent probably is a lot closer to the "script AM" that it is to 
"callable MCC".  Some of the MOMGEN tools and such make it almost simple
to build your own agents.  The script AM only does remote access thru hackery.

The differences are just like writing a program in DCL vs writing the same
program in C.  Using the common Agent gives you more flexability, but at a
slightly higher cost.

    Dave,
    
    You mentioned Common Agent would be a slightly higher cost.  I assume
    you mean "higher resource cost".  As I understand it, the Script AM costs
    me one process for each network entity I'm accessing.  If I am accessing
    100 entities, this translates to 100 additional processes on my system. 
    (Please correct me if I've misunderstood something.)
    
    What will the Common Agent cost me in terms of overhead on the DECmcc
    node?  I have a customer who will be using the Script AM heavily, but
    will likely move to the Common Agent with time, if it makes sense.
    
    Thanks,
    Dan

The "Higher cost" I refered to is the cost of development, and not related
to the cost of running the application.

Common Agent for Ultrix is "spoken to" with the SNMP am, and
on VMS, we use the DNA_CMIP AM, so there is no "additional" cost
on the MCC system, other than just a slightly larger dictionary.
(Note, you would need to add these definitions with the script AM, also.)
The target system needs some processes running to deal with the inbound
management requests, but these are not too bad.

A project I am helping with currrently has about 20 "Objects" that are being
supported, and they have broken it into only 3 Common Agent MOMs for functional
reasons.  If everything ran on the same node, then they could have used only 1
process.

	The Common Agent is intended to make (all) objects (systems, applications, etc.)
	remotely manageable by directors/management applications using standard protocols.

	Whereas, the director is intended to operating on a managment station
	to control a large number of systems; the agent is intended to operate
	on every system to provide remote manageability to its system objects.

	The performance cost of the director is much higher, of course, than the agent.

	The CA runtime package consists of three parts:
		protocol engines which encode/decode protocol msg
			and dispatch to the Managed Object Modules.

		Managed object directory which handles registeration
		and location services

		Managed Object modules which receive management requests
		from the protocol engine and perform the operations on 
		the managed object and return a response.

		Managed Object Modules may also generate events/traps
		to directors/management applications.


	The CA developers toolkit provides tools for generating 90% of the MOM code
	from the management specification (an IEFT Mib definition, or EMA msl definition)
	The developer then supplies the routines which perform the *actual* operations
	of the object.

	The Common Agent for ULTRIX V1.0 will ship on January 23, 1993.
	This agent will support SNMP protocol.

	The Common Agent for VMS V1.0 has not yet announced a ship date
	(depends on the DECCRTL/DECthreads special kit for VMS 5.5).
	This agent will support DNA CMIP protocol.

	The notes conference for the common agent is
		NOTED::COMMON-AGENT

	Project documents are located on
		FILES::EMA$:[public.common_agent]