Conference azur::mcc

    
    
    Steve,
    
    		The first error you received was indeed caused by the
    old Object Identifier format, and setting the MCC_DNA5_AM_LOG logical
    took care of that.
    
    		The second error is a Phase V Ultrix bug. Phase V Ultrix
    systems are returning an invalid Fullname. I QARed this in the PHVQAR
    database(QAR 261), and was told it'll be fixed in the Phase V Ultrix FT
    Update. Try showing something other than NODE Identifiers....
    
    JimH
    
    

Thanks, Jim. I'll wait for the Phase V Ultrix FT Update to see if 
it's fixed. 

                                        Steve

Does .1  imply  that  the  command fails completely when the bad fullname is
encountered?  If an attempt was made to show all the attributes and an error
occurred  formatting  one  for  display  would  the  rest  of the display be
completed?

I hope the answer is "Yes".  If so, don't bother with the rest of this note!

If not,  then  it  is  a major flaw.  The second most important feature of a
*management*   station   (after  being  able  to  communicate  at  all!)  is
robustness.   To  be  useful  in  tracking  down  and  fixing  problems, the
management  station  has  to behave impeccably when faced with badly behaved
systems  (or  newer  systems!).   An error message should be printed but the
output continues with the next attribute.

Graham

    Graham,
    
       When you soh wthe node with all attributes the display continues
    down and doesn't stop at the fullname error
    
    Bob

    
    On the subject of the MCC_DNA5_AM_LOG logical and object IDs...
    
    Does setting the logical to 200 cause the use of the old object IDs or
    the new ones ?
    
    
    Trevor

	Trevor,


		Setting the logical to 200 causes the use of the old object ids.
By default, the DNA5 AM uses the new format.


	Re: FullNames errors...

		When FCL hits an error like that it stops displaying
any more attributes in that Partition. You'll notice that the Address attribute
(towerset) never gets displayed on a SHOW ALL IDENTIFIERS. 

		The SHOW ... ALL ATTRIBUTES command continues because
a seperate request is made for each Partition. When the ALL IDENTIFIER partition
blows up on the FullName error, it drops the rest of that message. But continues
on to the other Partitons.


	Jim Halpin

    
    The logic behind stopping, is... If a module has been fully tested
    there shouldn't occur (in the field) a case where bad/ill-formatted
    data is returned to the PM. If this occurrs the rest of the output
    buffer is assumed to be corrupted. We do not terminate operations
    because the message is only an "E"rror status and not a fatal.
    
    jill
    

    Yes, the module should be tested, etc.  But even if it is, I think
    MCC has to be concerned about version skew.  MCC can't re-release
    every time that a manageable product is released.  Consequently
    you will inevitably encounter situations where MCC's dictionary and/or
    software is not synchronized with some manageable entity's software.
    This is especially true in the case of the SNMP world.
    In Phase IV NCP, this was dealt with very nicely -- the NCP would
    print the attribute number and would then attempt to print out the
    value on a best-effort basis (using the data type information available
    in the NICE encoding).  Phase V NCL/EVD does this as well.  It's
    a REAL handy feature when integrating with a new router release,
    for example.
    
    I know that ILV may make it slightly more difficult to pass the 
    CMIP-encoded data type back from the AM to the display, but it's not
    impossible.  For example, ILV_dump manages to do something without
    the dictionary.  Also, it would be possible to create a new data type,
    MCC$K_DT_ANY or something like that, which would be a RECORD whose
    first field was, you guessed it, the protocol-encoded data type,
    and whose second field would be the raw value.  Sorry to ramble on
    like this, but robustness is very important.
    
    ben
    

    
    I agree that testing isn't the whole issue, and that improving the
    robustness of the whole management system should be one of our goals.
    
    But, c'mon, just getting this whole thing to work when everything else
    is being nice to us is a pretty big job by itself!  :-)
    
    I think there are two points about robustness in this note:
    
    1 -	As we don't in this fullname case, you'd like us to keep chugging
    	away at the list of attributes returned even if one or more of them
    	can't be interpreted correctly.  Sounds good to me.
    
    2 -	It would REALLY be nice if we could make an attempt to return some
    	kind of information indicating that we received some gibberish from 
    	somewhere, and here is what it was.  Something after NCP's
    	inimitable style:
    
    		Parameter #1016 = %1238768712
    
    I like point 1 especially, and it would be nice if we could squeeze
    this ability to rebound from bozo data into DECmcc.  That might be
    as ugly as showing the attributes something like this:
    
    		 Name = Full.entity.name
    		State = 
    % MCC-E-NOENTITY No corresponding entity exists
    		Sub-state= running
    		.
    		.
    		.
    
    The point simply being that we would discard the bad piece of data and
    continue on.
    
    Solving the second problem is more difficult, but also a good idea. 
    Something like you suggested in .-1 could work, but might be expensive
    to implement.  Would you settle for maybe a non-predictable attribute
    like an "Unrecognized Attribute" attribute, which would be returned in
    place of any attributes we didn't have in our dictionary?  I think
    right now the AM will usually just drop things that don't live in the
    dictionary.  This would at least show that something else was
    returned, but we couldn't figure out how to deliver it to the MCC
    interface.
    
    Did I capture these ideas correctly?
    
    -Jim Carey
    
    P.S. I guess I see more robust behaviors as another of the myriad goals
    we are working towards, but I guess I also let these things get pushed
    into the background periodically.  Thanks for bringing it up to the
    top again.
    

    By the way, this will save you and the field time and money, because
    it will help you quickly identify the cause of the problem and 
    will thus reduce the number and priority of problem reports as
    far as MCC is concerned.
    
    If you can't dump the "bozo" value, the really important information
    is the attribute/argument number.  If you could at least return the
    number, it is then possible for the field to diagnose which attribute
    is not being recognized by the director.  
    
    As for the value... Another tactic is to just hex-dump it on a
    best-effort basis. In this case, the AM would just return the value as
    an octetstring. If the FCL PM doesn't recognize something that the AM/FM
    returns, it can just hex-dump it as well.  This is still better than
    nothing. For many kinds of attributes, this can still be a reasonably
    informative display.  I'm not saying this is a goal, but it is a means
    of "graceful degradation".  It could look somewhat like MCC_ILV_DUMP,
    I guess.  However, the Iconic PM may not be able to deal with this
    because of the constraint that it must build the forms at install
    time (have I got it right?), and that's ok, it can just skip the
    unrecognized attributes/arguments without displaying them
    (and log an MCC event :->).
    
    ben
    

Re .10,

The Iconic Map does not build forms at install time.  If we did that, we would
have no way to factor in variant information, for one thing.  We create forms
on the fly using the dictionary and variant information.  That way, if we get
back an attribute which is not expected, we display an error box with the code
for the attribute and the message that it was unexpected.  We also fill in the
text field for an attribute for which a value is expected but not returned with
--NOT RETURNED--.  

Hope this helps,
Verna

I see  the  point  about two different cases and I agree that continuing the
display  is even more important than displaying unknown attributes.  I agree
with Ben that displaying the values would be a useful feature even in a very
simple form.   

Seeing as  the iconic PM goes to all that trouble (error box, etc.) it would
be  nice  if the error box displayed a hex dump of the value (maybe only the
first  20  bytes  of  it, say).  By the way, I presume that when it displays
this error box it still goes on to display all the other attribute values in
the form as usual?

Thanks for listening,
Graham

>Seeing as  the iconic PM goes to all that trouble (error box, etc.) it would
>be  nice  if the error box displayed a hex dump of the value (maybe only the
>first  20  bytes  of  it, say).  

	Sounds like a good idea. We will look into this further.

>By the way, I presume that when it displays
>this error box it still goes on to display all the other attribute values in
>the form as usual?

	Yup, the other attribute values are displayed. 
 
	/Jim

    An appropriate qar, #556 in MCC_INTERNAL, has been logged against
    the FCL PM for not attempting to continue the displays.
    
    jill