Conference azur::mcc

    Hello,
    
    I am currently involved in the design of an AM which will have to talk
    CMIP (yep, another one !) based on the DECRose product. For various
    (mainly political) reasons that I won't go into, the customer seems set
    on doing "his thing", and will not buy / wait for a DEC-supplied OSI
    AM. 

<<< The customer is always right even if they are incorrect. :-)
    
    Several questions arise while designing this thing, so I'll be grateful
    for any answers.
    
    1) The customer want to handle attributes individually, not by
    partition. Unfortunately, the SHOW directive only works in partition
    mode. Are there any plans (in V1.2 for example....) to allow in_p to
    specify the wanted attribute_list ?
    
<<< I will answer your literal question first. No, there are no plans
<<< in V1.2 to change the way we handle partitions across the DECmcc
<<< internal APIs. I know of no plans to change this either in the
<<< V2.0 development cycle. A great deal of thought went into the
<<< current method of passing partitions across the API. If someone
<<< is only interested in a few attributes, then they can always
<<< select them out of the partitions as they are returned. There
<<< is a certain amount of overhead associated with the use of the
<<< API. That overhead outweighs any theoretical performance gain
<<< of not passing a complete partition across the API. The FCL
<<< UI for example, only presents the attributes requested by a 
<<< user although the AM gives it the complete partition. The 
<<< Iconic Map needs to access the partition anyway to prompt/remind
<<< the user which attributes are in the partition, so it presents
<<< all of them rather than providing some selection/filtering
<<< mechanism. This is done for simplicity. 

<<< I suspect that in your case the customer wants to write their
<<< own FMs and do not want to provide filtering/selection function.

<<< Unless someone can make a strong argument otherwise, we are
<<< not considering changing how we handle attribute lists at present.
<<< It works well for both the FCL and Iconic Map PMs and our current
<<< suite of FMs. 

<<< If you have a well documented reason for making the change, we would
<<< like to review it. Maybe there is something we missed in our
<<< original design process. 

    2) Most implementations of event-handling involve having a separate
    event-sink doing mcc_event_put calls, and the AM GETEVENT directive
    support. Because the agent side of things in this case cannot initiate
    associations, the event sink will have to keep as many associations
    active as there are global entities to manage, and then wait for an
    incoming event report indication. It seems a shame to have to set up
    separate associations every time I have to perform another operation.

<<< I don't recall anything is ACSE that prevents an agent from initiating
<<< an association. My limited reading of ACSE was that it regarded
<<< agents and managers as peers and placed no restrictions on either
<<< role. Did I miss something?

<<< Is this a restriction of a particular agent implementation? How
<<< likely is this restriction in other agents?

<<< You don't need an association active for all global entities. At
<<< worst case, you would only need one for each global entities that
<<< there is an outstanding getevent request waiting for an event.

<<< You are assuming that the manager wants to handle all events from
<<< all global entities in the universe. That is far to grandiose
<<< a strategy to implement. The first level of filtering is that
<<< if there is no outstanding getevent for a particular event class
<<< from a particular global entity, then the event is not processed
<<< by the event sink. Remember that in a large enterprise there will
<<< be many management systems and many more global entities. Not all
<<< management systems will deal with a particular global entity. Only
<<< those that need to will deal with it. 

<<< It is a common trap to conceive of a management system as a single
<<< monolithic whole that defaults to processing all possible events
<<< from all possible global entities. This leads to madness. No
<<< processor in the world can deal with this upper boundary
<<< condition.

    What would be the best way to handle this ? Write a separate
    Association handler ? Get the event-sink & AM to talk to each other so
    they can exchange connection-ids ? Run the event sink as a separate

<<< I am suggesting that the event sink be more selective on which
<<< events that it will receive. It needs to establish associations
<<< with only those global entities which it has customers for their
<<< events. The same is true from the agent side. It needs to only
<<< send events to those management systems which WANT its events.
<<< Yes, the AM needs to clearly communicate with the event sink
<<< those global entities and event classes for which it has outstanding
<<< getevent requests for. Yes, wildcarding clouds the issue. But
<<< we have to start with some reduced set of global entities and
<<< event classes. Yes, recognizing the existence of a new previously
<<< unknown global entity is a special case that needs to be handled.
    thread within MCC so it can share associations with request-type
    threads
<<< The previous discussion points out a small weakness of using 
<<< a Connection Oriented protocol for all management functions. There
<<< are some management functions that would be better suited to
<<< connectionless methods.    
    3) Scoping and filtering : what is the status regarding subentity class
    wildcarding ? Is this still restricted to level n + 1 ? An older
<<< Pure OSI Scoping and filtering is not the same as the DECmcc
<<< With clause. They do a similar function but they are defined very
<<< differently in how they function. There is no defined mechanism
<<< to pass OSI scoping and filtering across the DECmcc call interface.
<<< This has been a deferred issue for over 4 years and to date, there
<<< is no workable solution in sight. I do not know of any current
<<< effort to change how the with processing is done. It happens at
<<< the PM level only.
    version of the SRM states that the WITH qualifier which could (I guess)
    be used to perform filtering only supports a single AND logical
    operator. This restriction seems to have disappared in SRM 1.1, what is
    the DECmcc product actually capable of handling ? (By the way, the SRM
    states on page 67 that subentity class wildcarding is supported, does
    DECmcc actually support it and what is the syntax in the FCL PM ?)
<<< I would suggest that this question be seperated out as a seperate
<<< topic so that the FCL people can deal with it independently.

    
    

                      <<< Note 1862.1 by TOOK::MATTHEWS >>>
                               -< partial reply >-

>>> A great deal of thought went into the
<<< current method of passing partitions across the API. If someone
<<< is only interested in a few attributes, then they can always
<<< select them out of the partitions as they are returned. There
<<< is a certain amount of overhead associated with the use of the
<<< API. That overhead outweighs any theoretical performance gain
<<< of not passing a complete partition across the API.

	You're looking at the wrong performance gain.

<<< The FCL UI for example, only presents the attributes requested by a 
<<< user although the AM gives it the complete partition.

	There's the rub.  You force the AM to request and receive ALL attributes
	in the partition, regardless of how many were requested and will be
	displayed.  Network and agent loading goes way up for no good reason.
	The Proteon MIB has a child entity with 60 counters.  Think about what
	happens trying to get them all, ESPECIALLY the agent is busy, and 
	returns some errors, or doesn't implement one of them, so the AM has to
	retry N times, etc.

	It's not a great decision as regards agents and networks.

	My 2 cents,
	Mike

RE: discussion around requesting specific attributes.

 The feature is spec'd, but not yet implemented...

 The SRM defines an optional request argument for the SHOW directive,
called Attributes Wanted (of type AttributeIdList), which addresses the
concern expressed in Mike Daniele's note.

 The attribute partition must be supplied, and the list of attributes
requested must reside in that partition, but requesting two out of an
available 60 counters could reduce traffic considerably.

 The *implementation* of this functionality in DECmcc will have to wait
until sometime after V1.2.

						Chris

Wally:

  I'm not aware of the decision to stick with only passing partitions and
  not individual attributes.  Are you sure about this?  I thought that it
  was just a tradeoff we made during v1.0 that has been with us since then.

  The latest version of the DECmcc SRM still has the optional request argument
  "Attributes Wanted" on the SHOW directive to handle just this kind of 
  request...

  Not being in Littleton anymore, I must admit that I am sometimes behind the
  times as far as recent decisions are concerned, so I would like to get 
  confirmation on this.

  BTW, I must say that I agree with Mike on this one -- we should implement
  this in the future.

                                                                    - Jerry

If DECmcc is dropping the idea of ever putting in support for showing a
partition sub-set and pushing the WITH predicate out to the server, I have
probably let one too many request-for-Phase-0-requirements go by without
sending it back and stating that these are important to us.

Both of these features are unimportant as long as objects are small and
the number of instances few. But as the scale of entities go up, and the scope
of DECmcc management increases, customer instances will become unmanageable
if these issues are addressed.

For example, consider the media library project we're working on. Each physical
reel or cartridge of tape, each optical disk, is an instance of a Cartridge
object. We've talked with customers like RJ Reynolds, the US Census, and
Martin Marietta where their media library will have numbers of cartridges
in 6 digits. We address some of that magnitude in the model by partitioning
the library into Branch libraries, each of which is a separate database.
And we try to model things so that the day-to-day operations are targetted
at a specific instance, or are done in such a way that if a large search
is done it is done within the Agent/MOM/server, where it is a local database
operation aided by indices.

But there will always be those exceptions, where in order to do business the
manager will have to list all the cartridges in a certain state, or owned
by a certain user, or contained in a certain media robot. We again endeavor
to keep the search local by pre-defining the queries we can anticipate as
reports. But we can't anticipate them all, and the day will come when

MCC>Show Branch AIM Cartridge * WITH Project = mumble

is issued, and if tens of thousands of responses have to be sent back to
be filtered by FCL, we're in big trouble. If DECmcc doesn't support
passing of the filter out to the agent, then I would think we'd keep our
customers happy by defining a Search directive, which would take the
filter expression as a string argument and return some information. But
it would have to be an action directive, and wouldn't get all the built-in
help from the PMs that Show does.

I would like also to put my vote that passing individual attributes instead
of the whole partition is very important. I have already ran into a few cases
where it would have been of a lot of help.

Passing of the WITH qualifier across the MCC_CALL ineterface is also 
desirable. Right now, I believe, the FCL implements it only with the SHOW
directive. It may be desirable to use it with other directives. In Addition,
the case that Rich Kittel (in reply .4) mentions in reducing traffic on 
widcarded SHOW when there are a lot of instances is starkly clear.

Phil

Passing the "with" qualifier is great -- but think of how complex it is to
to evaluate...all those datatypes and relational operators to process.

When we allow the "with" qualifier to be passed through the Call Interface,
we better have a generic 'tool' in place to help the developer process it.

The Rule Evaluator used by the Alarms FM is a generic service which should
be considered for this purpose.  It will require some extentions -- but
I beleive this is the correct direction to head.

We must keep development and maintenance costs for MM's to a minimum.

Keith

I forgot to mention in .6, that we had (and still have) to do a lot of 
workarounds because the select variance attribute is a characteristics and
I have entities that have a number of settable (charaterictics) attributes
that might be very large expressions. Therefore, asking for all the 
characteristic attributes to get the select variance one is, I am afraid, 
going to be a real hog. 

RE: .6

Keith,

I agree that passing the WITH clause (what us ex-database types would call
a selection predicate) isn't an easy thing to implement, and in fact we
should assume that some simple agents will never want to see it, or at
least of way of indicating they haven't applied it, so the PM should.

But it will be critical to those that need it. When it comes time to think
about how to encode an arbitrarily complex expression, note that you'll
have several ways to choose from, and probably no need to go invent a new
one. In particular, the common agent already has filter expressions and
filter routines defined, presumably based on some ISO stuff. So we really
want to make sure that whatever gets passed from DECmcc can be converted 
into those constructs by the common agent's protocol engines.

(We should probably cut these last few replies out of this discussion and
 start a new topic.)

    Hello,
    
    Thanks for all those comments, I didn't come back to this conference
    earlier because I was out on customer site. However, you now have me
    quite worried regarding some of these points ....
    
    Re : .1 
    
    The agent is not implemented yet, one of the original ideas was that
    the director should handle all association set-up / tear-down. This has
    been revised, we'll now use two associations : one set-up by the agent
    when it wants to send an Event-Report, the other managed on a
    semi-permanent basis by the AM for request / response type exchanges.
    
    I have not had any replies from the FCL team regarding the combination
    of several WITH qualifiers. Is anybody home ?
    
    Re: .2 : 
    
    I agree with Mike, we'll get better performance if we reduce the
    network load and only request the attributes we need, however, this is
    not at the top level of my priorites, but it is something we need.
    
    Re : .7
    
    Keith,
    
    Am I right in understanding this reply as saying that the WITH
    qualifier is *not* passed down to the AM ? If this is the case, this is
    in violation with the SRM. Page 62 states that :
    
    "The WITH qualifier is associated with the in_entity parameter of the
    VEP tuple. Specifically,  the WITH qualifier is placed at the
    appropriate level in the entity hierarchy in the In_Entity parameter
    
    (...)
    
    One WITH qualifier may be used at the lowest level of the entity
    hierarchy for MCC V1.0"
    
    Furthermore, table 5.1 states that the with qualifier may be handled by
    the PM, the IM *or* the target MM.
    
    Please clarify this point, as my customer is basing his AM design on
    this , and one of his customer's requirements is that a minimum amount
    of filtering is supported.
    
    I believe I can make him accept that only on WITH clause is supported
    and only for base datatypes, but no support at all will really put us
    in trouble (to say it mildly!).
    
    This is the only way I'd have of supporting some kind of CMIS-like
    scoping and filtering.
    
    I have an extra question for the FCL team : The SRM states that
    sub-entity class wildcarding is supported. What is the syntax of the
    command to use this feature ? Or is it something only FM's / AM's
    should use ?
    
    Thanks for your help,
    
    Philippe.
    
    

I have created a new note to discuss the With Qualifier

	1919.0

/keith

    re: quite a few
    
    Despite the assertion in an earlier reply, there is NO intention of
    NEVER implementing the ability to request particular attributes from
    a partition within a request. As has been pointed out, this has been
    specified since the first release of the SRM - the functionality has
    just been traded off in each version of DECmcc.
    
    Sure would be a good idea to implement it - problem is that there needs
    to be a critical number of MMs that implement it to get any gains.
    However, the feature *is* specified in such a way that MMs may
    implement it whenever - you just don't get the desired effect until
    both a service requestor and a service provider both support it!
    
    A comment on WITH clause - this one does need to be added to the SRM -
    there is insufficient detail therein to implement it. We also need to
    choose what subset of scoping/filtering we wish to provide. Obviously
    the Common Agent's filtering routines will be very useful in any
    module's use of filtering.
    
    Colin

    as to the FCL question of about -.3
    
    The FCL, and MCC as a whole, is not yet ready to support class
    wildcarding that is why you can't do it. Simply allowing the FCL to
    accept the class wildcard it not as straight forward as many would
    hope. We have yet to solve the problem. I know that some kernel
    routines say they allow you to encode a wildcarded class, but that is
    not true for all kernel routines/information manager/MIR...routines.