Conference azur::mcc

Re Not Returned


This is displayed when a particular attribute is expected in outp - it is in
the dictionary, and if there are variants, it should be associated with the
the entity, BUT it was not returned in outp.  It generally means that the
MS has an error in it.

Hope this helps.
Verna

 It is important to note that different SNMP agents on a network may
implement a subset of the MIB.  When a request is made from DECmcc
through the TCP/IP AM, the response may indicate that the agent does
not support the particular attribute(s).  Such attributes are marked with
a reason code of ``Attribute Not Gettable''.  For DEC's agents, the DECmcc
TCP/IP AM maintains knowledge of which attributes are not implemented.
By default, these attributes are not requested of the agent in order to save
network resources.  They are immediately marked as ``Attribute Not Available''
and passed back to the caller.  ( This Optimization) may be turned off by using
the Access Module's management interface.  Refer to Table 4-1,
attribute ``SNMP Optimization''.)

    Hmmm, maybe the text associated with "Attribute Not Gettable" should
    say something more like "Attribute not available from Agent"
    
    As someone who has been frustrated by the number of management windows
    I have seen full of "... not available" and "... not Gettable", it
    would sure look better (for Digital, and to the user) if we provided
    a user selectable way of surpressing the display of this sort of
    non-usefull information. Yes, I can see the value of seeing it when
    checking out an AM or Agent, or new device on the network, but for
    day to day operation it simply shows up as screen clutter and makes
    finding the usefull info more difficult.
    
    my $.02
    
    s/rob

re:        <<< Note 1584.3 by TOOK::R_SPENCE "Nets don't fail me now..." >>>
                      -< Make it more clear to the user >-

>    As someone who has been frustrated by the number of management windows
>    I have seen full of "... not available" and "... not Gettable", it
>    would sure look better (for Digital, and to the user) if we provided
>    a user selectable way of surpressing the display of this sort of
>    non-usefull information

	Actually, the Colorado Springs folks were explicit about wanting to see
	the name of each attribute, and that it was not gettable.  (At least
	back in V1.0 time.)

	(And there is a way to get rid of the "Not Available" response, by
	turning off optimization.  then you'll get all "Not Gettable.)

>    useful for checking out an AM or Agent, or new device on the network, 
>    but for
>    day to day operation it simply shows up as screen clutter and makes
>    finding the usefull info more difficult.
    
	I'm not sure of you understand the SNMP aspect of this.
	It's not something that is static and can be checked out once.
	SNMP agents from different vendors will produce widely varying
	responses.  Responses from the same agent can change with time,
	and responses may even change based on the identifier requested
	(interface 2 vs interface 1, for example).

	Sounds dangerous to simply not present such information.
    
	My .02
	Mike

    For the folks at colorado springs, the current way is correct. I agree.
    However, they are not the userbase. They are DECmcc troubleshooters
    and more info is better. That's why I suggested user selected
    surpression or enablement.
    
    If I understand correctly (please correct if I don't understand), if
    a particular SNMP agent (lets use Chipcom as an example) doesn't
    support certain attributes, then I will get  the "Not Gettable"
    when DECmcc askes on my behalf for them. This should remain true
    for this Chipcom and all identically configured Chipcoms? If so,
    then after I get any particular Chipcom working with DECmcc I don't
    need to see all the "Not Gettable" attributes. I want to see all the
    gettable ones. Now, this is a display issue sorta. Alarms may want to
    recieve the "Not Gettable" message at all times.
    
    Am I making any more sense?
    
    s/rob

	Rob,

	What feedback I got (from CS) was that *users* would want to see
	all the attributes each time.  It would be stange to see 20 attributes
	listed one time, and only 2 the next time the very same command is
	issued (with a different identifier).

	Most of the time, your assertion is true.  But an agent may reconfigure
	dynamically, and may not return the same set of MIB variables on each
	request.  For instance, Pre 4.2 Ultrix agents would omit most of the
	counters for whatever interface was configured as loopback.  So
	"show fred interface 1 all counters" looked very different than
	"show fred interface 2 all counters".

	But upon further review...  I suppose if a user is comfortable with
	it, let them have it.

	The issue is much larger now that MIBs may be added dynamically.
	The area of asking for attributes you don't get will have to be
	better addressed.  ( Consider asking a Chipcom box for Wellfleet 
	MIB objects.  I've suggested a specialized exception be returned for 
	this case. )

	Mike

    in DECnet-ULTRIX NCL, if the user asks for an attribute group,
    we filter out the "no such attribute" errors so they don't appear in
    the display.  However, if the user explicitly asks for the attribute
    then we don't filter out the "no such attribute" error.  This seems
    to avoid needless clutter without loss of information.
    
    ben
    

    Rob,
    	When dealing with SNMP agents with various levels of
    compatability with the standard MIBS it is better to display the
    errors messages.  Some SNMP agents return the 'attribute not
    available' or 'attribute not gettable' when a MIB variable contains a
    counter with a value of 0 or an OCTET STRING variable which is
    currently not defined.  An example I have seen is a MIB for an
    intelligent wiring hub which return an attribute not gettable error
    if the name of the down-line-load host machine is not defined.  A network
    manager would want to see this error.  Imagine a router MIB which
    returns a 'attribute not gettable' error when the number of octets
    transmitted on an interface is 0.  This is an error message I would
    want to see.  Until SNMP agents are more robust I would vote for
    displaying all the error messages. At least it shows our management
    station knows about the MIB variables and it's the agent that chose
    not to respond. 
     
    - Mike

Let's not lose sight of Rob's initial point:


    >Hmmm, maybe the text associated with "Attribute Not Gettable" should
    >say something more like "Attribute not available from Agent"
    
First, "gettable" is not a word in the English language.  Second, even if it
were a word, the message does not communicate anything to the user.  The 
only way to figure it out is to look in the manual.

Jack

Instead of deciding for the user, how about allowing the user to have
it his/her way?  I personally am sick and tired of having to scroll
through screens full of "not gettable" lines to get to the few nuggets
that are information that is useful (to me).  On the other hand, I
understand the value of displaying "nil" when that is useful
information in its own right.

I vote for a user-settable switch that can be toggled on the fly from
the user interface itself.