Conference azur::mcc

    MCC is defined to allow a single attribute to be passed back, but
    neither of the PMs we have built to date format the request that way.
    
    If you look at the SRM definition of the standardised directive SHOW
    (p893) you will see that there is a request argument [Attributes Wanted]
    of the datatype AttributeIdList. It is optional. If your AM is able to
    return only the requested attributes (rather than the default which is
    the whole partition), then you will be ready for when the PMs are
    enhanced. 
    
    Note that the user still gets the desired behaviour from the FCL PM, as
    it filters out the requested attribute(s) from the returned data.
    
    Note also, that FMs as well as PMs could make a SHOW request and make
    use of Attributes Wanted, so you shouldn't wait for just the PMs to be
    changed
    
    Colin

I have related questions. We are working on a FM, which calls AMs, using SHOW
verb and we need to request one or more attributes.

The first question is how to contstruct attribute list for IN_P, i.e. what
values should be passed for individual attribute? Or no value at all, i.e
mcc_a_pointer field should be NULL?

The second one: is it possible to request more than one attribute?

And the last: is it possible to request more than one attribute from different
partitions? For example, in PM you may do that:

	MCC> SHOW NODE4 <name> ADDRESS, TYPE

where ADDRESS belongs to the indentifier partition, and type to the
characteristic partition.

What should be specified as ATTRIBUTE parameter in this case for
MCC_CALL_ACCESS?

Thank you,
Gene

>> The first question is how to contstruct attribute list for IN_P, i.e. what
>> values should be passed for individual attribute? Or no value at all, i.e
>> mcc_a_pointer field should be NULL?

All MM's support showing all attributes of a single Partition.  This is
what the current PM's do.  The In-P buffer is passed as NULL - the MM returns
all attributes (of the single partition) in Out-P

>> The second one: is it possible to request more than one attribute?

I don't know (off hand) of any MM's which allow you to request a subset
of attributes in a single partition.  In the SRM for the SHOW directive,
it indicates that (optionally) the MM can have a request argument for
In-P.  This would be an Attribute List containing the list of attributes
that you want returned.

>> And the last: is it possible to request more than one attribute from
>> different partitions?

Sorry, but No.  The DECmcc Call is dispatched on three components:

  o Verb
  o Entity
  o (Attribute) Partition

You can only specify a single Attribute Partition.

>>  in PM you may do that: SHOW NODE4 <name> ADDRESS, TYPE

The PM expands your single command into multiple (in this case, two) requests
for the appropriate Partitions.

/keith

>
>>> The second one: is it possible to request more than one attribute?
>
>I don't know (off hand) of any MM's which allow you to request a subset
>of attributes in a single partition.  In the SRM for the SHOW directive,
>it indicates that (optionally) the MM can have a request argument for
>In-P.  This would be an Attribute List containing the list of attributes
>that you want returned.
>

It is a bit unclear to me here, since attribute list is a list of attribute
*values* and not a list of attribute id_code (what is needed here). I think SRM
defines the Attribute_Id_list which should be used, but all the SHOW directives
I know use Attrib_list (as you say) as request argument data type.

>>> And the last: is it possible to request more than one attribute from
>>> different partitions?
>
>Sorry, but No.  The DECmcc Call is dispatched on three components:
>
>  o Verb
>  o Entity
>  o (Attribute) Partition
>
>You can only specify a single Attribute Partition.
>
>>>  in PM you may do that: SHOW NODE4 <name> ADDRESS, TYPE
>
>The PM expands your single command into multiple (in this case, two) requests
>for the appropriate Partitions.
>

We have a trick for that !!! We (PNMP) have defined a directive SUMMARIZE whith
DIRECTIVE_TYPE=ACTION that send back some "critical" or "interesting" attributes
across multiple partition in a single response.

It does not violate the MCC architecture since we use :

Verb = Summarize
Entity = ours
Partition = Null


So if this can give you some ideas...

Regards.

Pierre.

Thank you for your replies.

>I don't know (off hand) of any MM's which allow you to request a subset
>of attributes in a single partition.

Neither do I, but it have been mostly theoretical question: if such beast exist
or will be writen, how the IN_P should be constructed on the call to it from
FM.

As Pierre pointed out 

>It is a bit unclear to me here, since attribute list is a list of attribute
>*values* and not a list of attribute id_code (what is needed here). I think SRM
>defines the Attribute_Id_list which should be used, but all the SHOW directives
>I know use Attrib_list (as you say) as request argument data type.

If it would be the case I wouldn't have my first 2 questions.

As to the third one

>Sorry, but No.  The DECmcc Call is dispatched on three components:
>
>  o Verb
>  o Entity
>  o (Attribute) Partition
>
>You can only specify a single Attribute Partition.
>
>>  in PM you may do that: SHOW NODE4 <name> ADDRESS, TYPE
>
>The PM expands your single command into multiple (in this case, two) requests
>for the appropriate Partitions.

Sure, I know all that, but in SRM the definition of the show just talk about
attribute list and nowhere there that all attribute should belong to the single
partition.

So the question basically is: what will happen if I construct the IN_P in FM
which will be Attribute_Id_list or Attribute_list with attributes from the
different partitions and call AM with such IN_P? What should be set as attribute
parameter on such call?

Thank you
Gene

we will (as the SRM syas we should) allow requests for specific attributes
to go over the call interface (when is simply the question). It wil be
done using the attribute_id_list that is already defined. If you want to
start coding to , the getevent on specific events will show you a good
example of just how it will look (except that it uses the event_id_list
instead ofthe attribute one).

jill