Conference azur::mcc

    I think MCC can do what you want. 
    
    Two things:
    	1/ you would benefit from understanding the current work being
    	   designed for "notification services". I'll get someone to
    	   contact you off-line on this.
     	2/ I'm unclear what components are involved in your description and
    	   which of them are inside MCC (eg. AMs) and which are outside.
    
    Certainly an event can be passed from an AM to an FM with just the
    "raw" data about the event from the "agent". Then an FM could "tack
    on" the other information such as event priority and type of response
    required - the new event might then appear at the "top" of the FM
    either as the same, or more likely a different, class; there it can be
    processed by other FMs and/or PMs as needed.
    
    Colin

    
    Rich, I would like to discuss this in more detail with you. Please
    see mail message I sent to STAR::.
    
    thanks
    jill
    

    Rich,
    
    Sounds like you are on the right track.  Looks like somewhere,
    there is this Entity called an Operator.  Is it a global entity?  Maybe,
    but I doubt it. What is it a subentity of?  I don't know.  That's for
    you to figure out.  But, the important thing is that this entity can do
    certain things, one of which is to issue event-like information.
    
    Currently, MCC has two types of event-like information, the first one
    you already know about.  It is the MCC Event data, and is managed
    (well, the communication of it anyway) by the Event Manager.  The Event
    Manager essentially is very simple and very generic.  It manages per
    entity, system-wide mailbox-like communication channels.  The
    communication tends to be from Event Sink (that "thing" which is
    Listening for events from the actual entity) to Service Provider (that
    part of MCC which is waiting to receive event information so it can be
    forwarded on to the Requestor of the the event information). The EVENT
    Manager does not currently know anything about priorities, but that
    support is planned for V1.1 (don't read a commitment into that, it may
    be pushed out to V2.0).  The main purpose of Priorities for the Event
    Manager is for the management of Lost Events (if you HAVE TO lose
    events, lose the least important events first, and lose the most
    important events last).  But, it could also be used for additional
    filtering.
    
    The other Argument (Response Type Required), indicates to me, you are
    may be looking for something that someone else once requested.  The
    ability to define "generic" or "common" events. Or at least to be
    able to define an event once, and then when you define new events, to
    say, "It's like that one over there".  Currently you can only define
    a common MS include file and include it everywhere it is needed.
    
    But given what you have said, and after talking to Dan Carr, I tend to
    agree with Colin.  Your best bet may be to look at the Notification
    Services.  It is more sofisticated, and better adapted to handle needs
    such as yours (priorities, etc.).  The Notification Services support
    "occurrances" (the second type of event-like information) which is 
    really a superset of events.  Jill can better describe for you the
    usage, functionality, model, etc, for Notification Services.
    
    Hope this helps,
    -Matt.

 
> Sounds like you are on the right track.  Looks like somewhere,
>    there is this Entity called an Operator.  Is it a global entity?  Maybe,
>    but I doubt it. What is it a subentity of?  I don't know.  That's for
>    you to figure out.  But, the important thing is that this entity can do
>    certain things, one of which is to issue event-like information.
    
I asked the Operator whether he was Global Entity or a Sub Entity, he
said "he didn't know he just mounts the tapes!" :-)

Mark

    
>I asked the Operator whether he was Global Entity or a Sub Entity, he
>said "he didn't know he just mounts the tapes!" :-)
    
    Mark,
    
    You have to come back on this side of the pond.  Your jokes are getting
    worse!!!!!  8-)
    
    ~Jon.

    
    I have a similar request for assistance in enhancing the DECtrade
    product by using the MCC model.  I am interested in knowing the 
    outcome of the discussion resulting from this request.
    
    DECtrade is a platform that can run internally-developed and third
    party applications using an API.  These applications register
    with DECtrade, and can generate events to be processed by the
    server, similar to what Rich has described in .0.
    
    Having a capability requested by Rich for DECtrade will also relieve 
    the burden from the application developers for this product.
    
    Another capability that DECtrade provides to the users of these
    applications is a common user interface through a control 
    program (TRADECP, analogous to NCP).  TRADECP not only performs
    management activities, but also forward commands to these
    applications and obtains responses.  These commands are defined 
    only within the target application.  For instance:
    
    TRADECP>  SHOW NODE  INDEX  TRADE$MGMT  /ALL
    
    requests the management server, TRADE$MGMT, (a special class of 
    an application) on node INDEX:: to show the values of all 
    defined attributes.  While:
    
    TRADECP>  DA-DA  NODE  NET  APPL$FOO  /HA-HA=NO-NO
    
    tells TRADECP to forward to application APPL$FOO on NET:: 
    DCL-like command DA-DA/HA-HA=NO-NO, which is understood only 
    by the application, APPL$FOO.  Note that TRADECP doesn't
    have any idea about the verb DA-DA but APPL$FOO does!  The 
    general command syntax is:
    
    	VERB [NODE node_name] [application_instance_name]
    	     [FACILITY facility_name] /qualifier[=value]
    
    Is MCC sufficiently flexible to provide this kind of capability 
    for DECtrade?  If so, would it be necessary to define all 
    application commands known to MCC, so they can be passed on
    to the respective applications?
    
    Muhammad

    
    To tell the truth I am not positive what you are requesting; are
    you looking for the ability to add in a module that is capable of
    forwarding commands from MCC to another application, and then returning
    the response data to the user?
    
    If this is the case then, yes MCC should work, since this is the
    basic premise between an Access Module which sends commands to an
    entities agent to get the response data.
    
    If this isn't what you meant, please feel free to call me and we
    can see what can be done regarding setting up a meeting to go over
    what can be done.
    
    (BTW: I am meeting with Rick, RE: .0, today.)
    

    
    Jill,
    
    Your para-phrasing in .-1 very concisely describes the capability 
    I am looking for.
    
    The twist is that with the current version of the DECtrade 
    management server the commands (directives) don't have to be 
    defined, unlike what is normally done when MCC management modules 
    are programmed.  They are forwarded transparently by the server 
    to the applications, which then respond to these commands.  
    Applications may also pass events to the server for further 
    processing.
    
    My question is, if I 'migrated' my server to become an Access 
    Module, will this scheme still work or the commands sent by the
    AM to an entities agent need to be somehow defined as part of
    defining the AM?
    
    Muhammad
    
    send events to the 

    
    Well you have a couple of options that I can think of (remember
    these are off the cuff).
    
    #1 every time they define a new command, "augment" your entity
    specification in the dictionary with the new command, and have your
    AM simply put in a wildcarded dispatch entry point for ANY command
    that works on your DECtrade entity.
    
    #2 put together a command syntax similar to the current alarms syntax.
    They have an argument called "expression" which when broken
    apart gives them all the information then need to acutally go off
    and evaluate the rule without having specific knowledge before hand
    of all entity classes and attributes supported by the currently
    enrolled modules. You could do something similar by using a syntax
    something like:
    
    	EVALUATE DECtrade <name> COMMAND = <command string to be passed>
    	^^verb   ^^entity        ^^argument

    I know this isn't real pretty but that is something you can work
    on, especially if there is a known command base that you can have
    predefined in your MSL, and all you need this for is the ability
    of handling new commands without augmenting your entity specification
    already in the dictionary.
    
    My personal preference is option #1, since it provides what I see
    as a nicer interface, but option #2 is just as workable.
    
    

Thanks for the help so far.  We are now coordinating with the developers of 
the Notification Services and that looks to be very useful.  I still have a
refinement of my event-related question, however.

I have a thing, GENERATOR, which can generate what I'll call OPERATOR EVENTS.
An OPERATOR EVENT is a DECmcc event with some added properties:

	1. Every OPERATOR EVENT has arguments ALPHA, BETA and GAMMA of
	   exactly the same type.

	2. Its arguments have DEFAULT VALUES, which differ for every
	   OPERATOR EVENT.

I have the following design considerations:

	1. I do not want GENERATOR developers to need to know about the
	   data types, etc. of these arguments.

	2. I do not want GENERATOR developers to have to replicate MSL code.

Off the cuff, I guess a syntax like this would be what I'm after:

EVENT my event = 1 : <MCCDataType>
	DISPLAY = TRUE
	TEXT = "This is my event with an argument !<my argument>"

	ARGUMENT my argument = 100 : Latin1String
		DISPLAY = TRUE
	END ARGUMENT my argument

	ARGUMENT alpha INHERITED FROM <???>
		DEFAULT = <Value>
	END ARGUMENT 

	ARGUMENT (beta, gamma) INHERITED FROM <???>                
	END ARGUMENT
END EVENT

I don't care about syntax, but what I intend with the above is to define an
event with an event-specified argument MY ARGUMENT, an argument ALPHA which is
common to a set of events and has an event-specified default, and arguments
BETA and GAMMA which are common to a set of events.  Even better would be
a syntax which would not require me to know that BETA and GAMMA were the other
arguments, but would rather permit me to say "define all the arguments in
the following set" (of course excluding those which I provided defaults for...)

                

    
    Let me restate what I believe you are looking for, by using an example
    from our current implementation.
    
    In MSL now there are two, what I will call, special cases. The first
    gives you the ability to define all attributes for a given entity
    class. It then allows you to reference them, from any 
    request/response/exception under that entity. This is done by simply 
    defining an argument of data type attrib_list. This way your MSL
    only defines the attributes once and can then share, or useing your
    words "inherit", these definitions.
    
    Another example of "inheriting" information is the use of the "COMMON"
    entity. This entity is used to define all common exceptions used
    by the system. MSLs don't even have to reference these, there is
    a special CVR which tells the client that the data returned is common,
    and not to look to the service provider but to "COMMON" for the
    definition of the data.
    
    Since we have mechanism in place for "inheriting" information, what
    we need to do now is to understand your requirements and determine
    how best to implement it. For a short term solution, if you are
    already working on implementation, put all your common stuff in
    a seperate .MS and use the INCLUDE command to pull the definitions
    in where ever they are needed.
    
    One more thing that I thought you were getting at was for the person
    returning the event, you don't want them to know the data type.
    The major problem with this is that all data must be ILV encoded
    to go across the interface and therefore the data type must be known
    to do the encoding. Note: the application can go to the dictionary
    to pick up the data type at run time....
    
    jill