Conference azur::mcc

1867.0. "TCP/IP SNMP AM problem with XYPLEX MIB extensions" by NISKY::SHREFFLER (I'll have a Caffeine free VMS please) Tue Dec 03 1991 11:26

I appear to have two problems working with a MIB extension supplied by XYPLEX.
The first problem appears to be a problem with the XYPLEX MIB and/or their
implementation on their terminal server (MAXSERVER 1800).  However this
problem demonstrates a problem in the SNMP AM.

Within the MIB there is a table of serial port characteristics.  If I use the
iconic map interface to retrieve this data I get the message:

	Management Window Message: no corresponding entity instance exists

and none of the 28 attributes in the table are displayed.  If I use the command
line interface I get the following:

MCC> sho snmp xyplex xyplex basic basicPortTable 16  all char

SNMP xyplex xyplex basic basicPortTable 16
AT  3-DEC-1991 10:56:57 Characteristics

Examination of attributes shows:
                basicPortActiveUserName = -- Attribute Not Available
                   basicPortAutoConnect = disabled
                     basicPortAutoLogin = disabled
                     basicPortBroadcast = enabled
                 basicPortConnectResume = disabled
             basicPortDefaultDestAction = preferred
        basicPortDefaultDestLATNodeName = -- Attribute Not Available
        basicPortDefaultDestLATPortName = -- Attribute Not Available
               basicPortDefaultDestName = -- Attribute Not Available
           basicPortDefaultDestProtocol = any
               basicPortDefaultProtocol = any
            basicPortDefaultSessionMode = interactive
               basicPortDefaultUserName = -- Attribute Not Available
                        basicPortDialup = disabled
                   basicPortIdleTimeout = 255
              basicPortInactivityLogout = disabled
               basicPortLastInCharacter = 17
              basicPortLastOutCharacter = 32
              basicPortLossNotification = enabled
                  basicPortMessageCodes = enabled
                 basicPortMultisessions =
%MCC-E-NOENTITY,  no corresponding entity instance exists

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

I am able to retrieve all of the objects except "basicPortMultisessions" by
requesting them individually.  Attempting to retrieve "basicPortMultisessions"
by itself always results in the message:

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

I am working with XYPLEX to determine what if any is the problem with their
terminal server software.  What concerns me is that the SNMP AM is not able to
recover form this error and display the characteristics of the objects that it
can retrieve.

Has anyone else seen this or have any ideas?

    I recently read the Simple Book by Marshall Rose. I distinctly remember
    a discussion of the use of the GET operation vs. GET NEXT operation.
    The behavior described fits the GET operation semantics. You might
    want to check with MOLAR::BOSE and see if the SNMP AM uses the
    GET operation for a list of attributes. If so, then if any attribute
    within the list forces an error in the agent, the complete operation
    is aborted. Since the FCL seems to work right and the iconic map
    doesn't there may be a small difference in how they use the AM which
    triggers the use of GET vs GETNEXT. 
    
    I only claim to be a layman trying to offer a possible insight.
    
    wally

The AM has successfully requested and retrieved the attributes.
The FCL and/or MAP cannot display them.  FCL's error message is (and has been
for 3 versions now) particularly misleading.  It means the dictionary
definitions do not match a value that has been returned across the call
interface.

A typical case is the agent returns a value for an attribute of type
enumeration that is not in the range defined in the mcc dictionary.  

In any event you can check this out using DAP, etc.

And your point is well taken that the 'raw value' should be presented to the 
user even if it isn't present in the dictionary.  MIBs as known to the manager
will always be out of synch in some manner with the agents.

Regards,
Mike

Thanks for the help.  It turns out that the object is a feature (multisessions)
that is supposed to return a value of 1 for disabled and 2 for enabled.  If I
enable this feature for a port the snmp get receives a valid value although it
says the feature is disabled.  It looks like someone goofed.  I bet that when
the feature is disabled the terminal server is sending a zero and that is out
of range.  If I had 3 hours to kill while my parse table is rebuilt I would try
to verify my assumption.

    don't waste three hours rebuilding just to test the assumption. Instead
    define MCC_FCL_PM_LOG to a value of 8. You will be able to see exactly
    what is being passed back across the call interface. Change from
    enabled to disabled and you will be able to pick up both values and
    then you can make the change. If you are running the V1.2 kit the
    parse table build will ONLY rebuild the changed entity class which
    means minutes not hours on the rebuild.
    
    jill