Conference azur::mcc

What "entity error" do you get?  Also, what directive are you
working with, and what is its directive type?  What do you mean
by "encoding" here?

I think that a manager can directly modify attributes that are
characteristics, reference, or identifiers, but I don't think
that (ILV) encoding a datum in an attrib_list ought to get you anything 
other than an ILV error.

If you are in a hurry, please send mail as well as posting a reply
here. 

Ruth K.

re .0 and .1

What Bonnie wanted is the following:

She wants to report errors (using a Reason Code) on arguments 
(arguments on action directives such as CREATE) that are not attributes in the 
same way that she reports them on arguments that are also attributes. An example
follows:

let suppose entity SERVER has two optional arguments on CREATE, 'Image' and 
'Like'.
The 'Image' argument is also a characteristic attribute. 'Like' is only an
argument that qualifies the directive, i.e. it is not an attribute.

Let us suppose that her AM traps duplicate attr/arguments if specified on
the same directive and report it back as follows:

MCC> CREATE SERVER x image=exe$:server.exe , image=exe$:server1.exe 

The following problem has been encountered with the argument:
                Image = -- Duplicate Values Not Allowed

Now suppose that you duplicate the like argument, then the it cannot be 
found in the dictionary if it's encoded in the same way (using the reason code)

MCC> CREATE SERVER x like=y , like=z 

The following problem has been encountered with the argument:

%MCC-E-NOENTITY,  no corresponding entity instance exists


The reason is the attrib_list macro that is defined for the argument of the 
exception cannot find the 'like' as an attribute
and the Reason code datatype seem to (supposed to) work only with attributres. 


So her question was, is there a way to handle arguments that are not 
attributes in the way that attributes are handled using the reason code ?


Phil

    Thank you for the clarification!  
    
    I think that the mechanism for non-attribute argument errors is
    more exception arguments.  The attrib_list is limited to attributes.
    (At least, the PMs mechanism for display of attrib_list data is
    limited to attributes, and that was the "original intention".)
    
    The Out_p containing the exception arguments would then contain
    one argument for attributes that is an attrib_list with reason codes, 
    and as many other, specific, arguments as necessary. 
    
    One possibility is to have a separate exception argument for each 
    argument rejection reason so that the text is correct.
    (Note that this means one exception argument per data type per output
    exception text.)  
    
    Another possibility is using the _private_ TYPE
    mechanism in MSL to define a datatype for the arguments that looks like
    the attrib list.  (ILV is switching things around to make the
    attrib_list encoding, so you have to be careful about encoding the data
    if you take this tack.)
    
    Hope this helps.  
                           
    Ruth K.
     
    
    At this moment, I haven't got the references available to give an example 
    or to check my assumptions, so .