Conference azur::mcc

I can only answer for the FCL for certain, but an attrib list (ON OUTPUT)
can be returned for any directive type. It is simply handled as another
data type. As for the Iconic Map...any answers Jim or Verna...?

>>I can only answer for the FCL for certain, but an attrib list (ON OUTPUT)
.....

	Jill, is the AttribList ok as a REQUEST argument too?

	In Bridge AM I would like to have a CREATE where the user can pass
	arguments, as in SET. Currently, the user has to invoke 2 directives
	to accomplish the same, i.e., first CREATE (w/o arguments), and then
	SET. The default CREATE arguments will often be insufficient for the
	new bridge.

Thanks,
Herman

No. Sorry about that, I guess I wasn't clear enough.

Attribute list on output -- in a response or exception is fine on any
directive type. BUT it is only supported on examine and modify directives
on input. Also examine and modify directivs are currently limited to having
only one argument, and it must be an attribute list.

jill

one more thing I forgot to add.

A create directive is an action directive, that does not mean that it can't
as part of it's action modify some attributes. To do this you define an
argument for the create that can be used to do the SET without haveing
the user have to do two seperate operations.

Jill,
	thanks for the replies - now I understand how it works. But - a few
	comments:

>>A create directive is an action directive, that does not mean that it can't
>>as part of it's action modify some attributes. To do this you define an
>>argument for the create that can be used to do the SET without having
>>the user have to do two seperate operations.

	Restricting AttributeList to examine/modify sounds like artificial
	limitation, specially with list supported in Out_p.
	It is a generic feature, to be able to set in Create
	the same attributes as in Set. The PM then could reuse the same code
	as for Set. The AM code should be very similar also. 

	As it looks now, to get the Set option into Create, I have to define 
	all my settable attributes as separate arguments for Create. 
	It seems that it would be easier
	just to allow one argument of Attrib_List type, to reuse the code
	from the Set directive, since they are very similar.

Herman

RE: -.1

  Herman:

    I tend to agree w/ you.  The Attribute List type was introduced somewhat
    late in the v1.0 development cycle and we scrambled to support it 
    (especially as concerned ILV support) in that timeframe.  It did not 
    become an issue in the v1.1 timeframe, and v1.2 functionality is pretty
    much decided, but...

    Other groups (notably ISB) have made this same point to me in the past.
    I believe it should be looked at furthur.  It probably should be QAR'ed in
    the SRM NACQAR datbase until someone has more time to look at the con-
    sequences of making this kind of change throughout the system.  I know that 
    PTB and our PMs would have to change to support it.  What do you think 
    Steve (Wong - SRM PL)?

                                                                      - Jerry

Okay, before we digress to far here...

Attribute list on examime and modify was done for many reasons, of which
I agree the world is changing and so are the rules and reasons for doing
things. So let's leave it as, yes we know alot of people want to allow
attribute lists on any directive.

The problems are technical in nature though. To parse a command that
can take attributes and arguments the parser would need to be enhance to
be able to handle situations like <attr> <arg> <attr>; the problem is 
that across the call interface all of the attributes are one argument
and therefore the handling ofthe command internally must change (I am NOT
saying it can't be done, but there is a sizeable amount of work required).
Things like the parse tables would need to be extended to include more
information then they do today, as well as more intelligence in the
command completion and context sensitive help.

Along with the statement you made, a more common one I receive is that
they want selective attributes, through the use of an attribute list, to
be supported on action directives. People want to say that on a create
you can do the create as well as setting the identifiers only. So they
want a way through MSL to say that these attributes work in this attribute
list on this directive...more complex but a heck of a lot more powerful.
Just remember if from the iconic map interface you have an action directive
and say that atttribute list is the data type of one of the arguments, then
the form would have to include all settable attributes, this could be quite
a list and not really what you were looking for.

What I am trying to say is that we hear you and many others, though you 
aren't all asking for the same thing, there are ways today to do what
you want though they might not be as nice as you would like. This is
on the list as a "nice to do" sometime down the line when we have the
other "mandatory" functions done.

Jill,
	I understand the complexity of supporting AttributeList in general
	case, when you have other arguments as well.

	Maybe, a resonable limitation, which would satisfy a lot of people,
	would be that the AttributeList is only allowed as the ONLY argument
	to any directive request, as is the case with SET today.

Thanks again,
Herman

    
    Attrib_List.
    
    I don't think the restrictions on its use have anything to do with the
    SRM.  Conceptually, there are no restrictions on it at all, it is just
    another contructed data type that we decided was pervasive enough to
    provide assistance constructing and parsing.  So, modifying the SRM
    won't gain you anything.  Across the interface, and within the system, 
    the Attrib_List is very easy to manage.  The problems (as Jill stated)
    lie in determining what is attributes and what isn't.
    
    We had to wrestle with similar problems in DECnet Phase IV.  Our
    result was to input the information required as arguments on the create
    directive and then to feel free to do whatever we needed to do with the
    information once we had it.  Sounds good?  As a side effect, we noticed
    that we had much better control over the request side of the problem by
    using arguments instead of attributes.  Arguments can be required by
    MCC, attributes are always optional.
    
    Not allowing Attributes in action directives also gives us more
    flexibility: all attributes and arguments for an entity would have to
    be unique if we allowed them to be mixed in a command.  This way, we
    can use arguments to "carry attribute information" without exposing the
    difference to our users.  Operators just want to put information into
    the system and get it out.  The less we expose the differences between
    entities, attributes, arguments, and qualifiers, the better.
    
    The approach we're using now costs you a little bit of MSL (sometimes a
    lot, I know), but gives you more control over the user interface, and
    with care can allow the user to move freely across the system, putting
    requests in, and getting information out.
    

RE: .9

  Jim:

    You're absolutely right.  It has nothing to do with the SRM.  I should
    have said "MRM" since it has to do with the services offered/required
    agreements.  Thanks for pointing this out.

    I agree that there are more important issues at hand today, so I would
    agree w/ Jill: "This is on the list as a "nice to do" sometime down the
    line when we have the other "mandatory" functions done."

    However, I would disagree w/ leaving it alone forever.  Too many people
    have complained about this to let it lie.  This is one of those hard to
    explain limitations of our product set.  If we expect people to flock
    to DECmcc (to write AMs and FMs) then we have to make it as easy as 
    possible.  This is just one of a number of small limitations that DECmcc
    imposes on AM/FM developers.  If we can remove it by improving our 
    user interfaces (i.e., parser) then we should.

                                                                       - Jerry

RE: .8

>	Maybe, a resonable limitation, which would satisfy a lot of people,
>	would be that the AttributeList is only allowed as the ONLY argument
>	to any directive request, as is the case with SET today.

Herman, this would be too restrictive, as it would prevent having a 
directive argument that wasn't an attribute. Once Create/Delete/Set/Show
are taken care of, many directive arguments apply only to the directive,
and are not assigned to an attribute.

Of course, then there's CMIS, in which attribute list and reference object
are the only arguments.  I would guess that, over time, more and more MMs
will be concerned with this mapping.

Kathrin