Conference azur::mcc

>  1. The SRM says that if the request argument is specified with REQUIRED =
>    TRUE and DEFAULT = NO DEFAULT, then doing a SET CLASS inst ATTR will cause
>   attribute if I just enter "SET CLASS inst", but I haven't been able to
>    get it to prompt for a value.
   
   The command SET CLASS inst ATTR is dealing with an attribute, not a request
   argument.   Request arguments apply only to Action directives (i.e., TEST).
   Attributes do not have a REQUIRED definition.  

   It was thought that only the Request Arguments need to be "REQURIED", 
   hence the user will not be promped for the attribute values.

/Jim

>    4. It seems there are two ways to pass attributes and values to a
>    directive:
>      a. Have one request argument of type Attrib_list
>      b. Have multiple request arguments, one for each of the valid
>         arguments, declared REQUIRED = FALSE so any one or more of them
>         can be specified.
    
 
	We had discussions on whether to do a. or b. early in the design
	process. Method a. was chosen because it was easier to implemtnt and on
	the MSL writer.   

	The basic question is "do we want to have required attributes?". 
	The answer at the time of writing SRM enrollment chapter was that
	attributes should not be required.  

	Now, if this is no longer the case (i.e., we get LOTS of feedback
	that some attributes should be required), we could enhance MSL so it
	allows for defining the REQUIRED definition under ATTRIBUTE and
	stores it in the dictionary.  The PMs could then go to the dictionary
	and determine which attributes need to be prompted for.  Note that
	this doesn't require any changes to how the attributes are encoded.

/Jim

Jim, thanks for the response, it help clear up some of the confusion.

A comment on making REQUIRED part of the nature of an attribute: I think
whether an attribute is required on any given command is a product of
the two. An attribute may not be required for all commands, in other
words, just some of them. So setting it on the attribute is probably too
broad a brush.

So what does MCC pass as the value when I do a command like

SET Node Capn Routing Circuit Cost

???

The answer had better be "the magic value default". Passing a null string isn't
right, since the data type of the attribute might be Latin1String, and ""
is a legal value for that. Looking up the value in the dictionary, and 
passing that isn't right since it is the entity (for EMA compliant entities)
that determines what the default is. This "bug" had been identified a long 
time ago, .0 seems to indicate it was never fixed.

Someone tell me it ain't so
				Mark

.4>	SET Node Capn Routing Circuit Cost
    
    This was discussed within the development group only two weeks ago
    (so you may not have code working 'correctly' yet).
    The intention - and if *I'm* wrong, someone better tell me - is that
    if an attribute has a default defined (whether as a specific value,
    or marked as implementation default) then mentioning the attribute
    name, but no value, on a SET command, will cause the
    	VALUE: default
    to be sent down and NOT the
    	default value
    to be sent across the mcc_call interface, and hence across the
    protocol.
    The same is true whether or not MCC (thinks it) knows the default.
    
    The *only* use that MCC makes of the MSL definition of the default
    value is to explain to the user (eg. at the iconic map) what value
    they ought to expect if they choose to set it to the default.
    
    I believe it has been defined this way in the SRM (though in our recent
    discussions we did discover about 7 places where some textual
    clarification was in order) for a long time - we just have to get the
    implementation (both the command line PM and the iconic map PM) to
    match.
    
    Colin

    Mark, As Colin stated in .5 this was discussed a few weeks ago.
    As it currently works the MSL syntax allows you to state a default
    value or implementation specific default (your magic). Currenlty
    the FCL does not work as Colin describes, but this is being fixed.
    What we do do is to send the default value specified in the MSL
    or the magic flag if there isn't a value but defaults are supported
    for the attribute.
    
    I will have to reread the earlier messages as to what the "" they
    were seeing was, since the only way to get that is to enter it in
    the MSL as the default value or at the UI (though the ILV dump may
    LOOK like "" since the flag isn't ascii readable).
    
    jill
    

re: .5

 The iconic map currently sends the default value stored in the dictionary.
This is being changed to send the special "use default value" as requested 
in .4.  


/Jim

I'm glad to see this will be fixed.
					Mark