Conference azur::mcc

5886.0. "show all characteristics" by MARVA1::BUCHMAN (UNIX refugee in a VMS world) Tue Mar 01 1994 12:43

    Hi,
    	A customer is using DECmcc for a telecom network management system,
    and is having a problem. I told him that I would relay it to the notes
    file. Suggestions?
    			Thanks,
    				Jim Buchman
    
    ------------------------------------------------------------------
    
We have defined a MIB extension for an enterprise-specific MIB which
contains a table which is INDEXed by a unique variable-length OCTET
STRING (an X.121 address of 1-14 BCD digits). The related MIB fragment
is shown below:

sshost OBJECT-TYPE
   SYNTAX       sshost_entry
   ACCESS       not-accessible
   STATUS       mandatory
   DESCRIPTION
        "An entry containing objects that define a Specialized Services
         Host."
   INDEX        { x121_addr }
   ::= { sshost_tbl 3 }

sshost_entry ::=
   SEQUENCE {
        x121_addr
           DisplayString,
        ...
   }

x121_addr       OBJECT-TYPE
   SYNTAX       DisplayString ( SIZE(1..17) )
   ACCESS       read-write
   STATUS       mandatory
   DESCRIPTION  "The X.121 address of the Host."
   ::= { sshost 1 }

Since the INDEX is of variable length, it cannot be defined as IMPLICIT
and when traversing the table with the GextNext PDU, the agent returns
the length of the following values as the very first element in the OID.
See trace of table traversal below where HAMMER is a VAX 4000/90 running
PolyCenter v1.3 and s1c1 is an SNMP agent on an embedded system:
PolyCenter v1.3 and s1c1 is an SNMP agent on an embedded system:

12:54:47.10 hammer.1034 > s1c1.snmp: GetRequest(59) system.sysUpTime.0 system.sy
sDescr.0 system.sysObjectID.0
12:54:47.11 s1c1.snmp > hammer.1034: GetResponse(116) system.sysUpTime.0=0 syste
m.sysDescr.0="WEC-ESG Mobile Data Group, SNMP agent, MSAT-DH SNACS" system.sysOb
jectID.0=E:epilogue.7.1.3.0
12:54:47.11 hammer.1034 > s1c1.snmp: GetNextRequest(31) E:618.1.2.2.3.1
12:54:47.12 s1c1.snmp > hammer.1034: GetResponse(58) E:618.1.2.2.3.1.14.3.0.3.7.
1.0.0.0.0.0.0.0.0.1="30371000000001"
12:54:47.12 hammer.1034 > s1c1.snmp: GetNextRequest(46) E:618.1.2.2.3.1.14.3.0.3
.7.1.0.0.0.0.0.0.0.0.1
12:54:47.13 s1c1.snmp > hammer.1034: GetResponse(58) E:618.1.2.2.3.1.14.3.0.3.7.
1.0.0.0.0.0.0.0.0.2="30371000000002"
12:54:47.14 hammer.1034 > s1c1.snmp: GetNextRequest(46) E:618.1.2.2.3.1.14.3.0.3
.7.1.0.0.0.0.0.0.0.0.2
12:54:47.15 s1c1.snmp > hammer.1034: GetResponse(58) E:618.1.2.2.3.1.14.3.0.3.7.
1.0.0.0.0.0.0.0.0.3="30371000000003"
[...]
12:54:47.40 hammer.1034 > s1c1.snmp: GetNextRequest(46) E:618.1.2.2.3.1.14.3.0.3
.7.1.0.0.1.0.0.0.2.6.5
12:54:47.40 s1c1.snmp > hammer.1034: GetResponse(58) E:618.1.2.2.3.1.14.3.0.3.7.
1.0.0.1.0.0.0.2.6.6="30371001000266"
12:54:47.41 hammer.1034 > s1c1.snmp: GetNextRequest(46) E:618.1.2.2.3.1.14.3.0.3
.7.1.0.0.1.0.0.0.2.6.6
12:54:47.42 s1c1.snmp > hammer.1034: GetResponse(58) E:618.1.2.2.3.1.14.3.0.3.7.
1.0.0.1.0.0.0.2.9.1="30371001000291"
12:54:47.43 hammer.1034 > s1c1.snmp: GetNextRequest(46) E:618.1.2.2.3.1.14.3.0.3
.7.1.0.0.1.0.0.0.2.9.1
12:54:47.43 s1c1.snmp > hammer.1034: GetResponse(45) E:618.1.2.2.3.2.14.3.0.3.7.
1.0.0.0.0.0.0.0.0.1=1

Note that the table traversal is completely performed by PolyCenter and all
entries are returned.

Problem:
When using the DECwindows interface provided by PolyCenter, the
table rows are usually displayed by the row title (in this case sshost)
and the unique INDEX associated with this row. In this case, only the
row title is displayed with no index i.e., in this case we get 22 entries
all identified as "sshost".

Problem:
At this point, if we try to "show all characteristics" of any of the
"sshost" entries, PolyCenter puts the following on the Ethernet:

12:54:55.82 hammer.1035 > s1c1.snmp: GetRequest(59) system.sysUpTime.0 system.sy
sDescr.0 system.sysObjectID.0
12:54:55.83 s1c1.snmp > hammer.1035: GetResponse(116) system.sysUpTime.0=0 syste
m.sysDescr.0="WEC-ESG Mobile Data Group, SNMP agent, MSAT-DH SNACS" system.sysOb
jectID.0=E:epilogue.7.1.3.0

and returns the following error message to the screen:
   The requested operation cannot be completed
   %NONAME-W-NOMSG, Message number 00000000
   %MCC-E-ILVTOOBIG,  no more room in buffer for additional values

Any light you can shed on this matter is appreciated.

    Hello again,
    	Here is a brief restatement of the problem. My customer can access
    the MIB if the identifier is an integer, but not a character string.
    (Note that the same MIB and access method works from Netview on an IBM
    RS/6000). See the preceding note for details.
    			Jim
    -----------------------------------------------------------------
    
    we are having a problem with DECmcc accessing an SNMP MIB table which
    is
    INDEXed by a variable length string (a 1-14 digit X.121 address).
    
    the GetNext operation works but the resultant display does not show
    the INDEX.
    
    the Get operation on any row in the table does not work at all and
    returns the following errors:
       %NONAME-W-NOMSG, Message number 00000000
       %MCC-E-ILVTOOBIG,  no more room in buffer for additional values
    

    Hmmm.... still no response. Is this a bug? Has anyone else had problems
    using a char string as an identifier in a MIB?

	Using a character string as an identifier should work fine. Looks
	like a buffer is overflowing somewhere. Does your customer see the
	same behaviour while using FCL.

	Rahul.

    
    
    Thanks for replying. Here is my customer's response:
    
    >Note 5886.3               show all characteristics                 3 of 3
    >MOLAR::YAHEY::BOSE                                    6 lines 
    14-MAR-1994 16:59
    >
    >        Using a character string as an identifier should work fine.
    Looks
    >        like a buffer is overflowing somewhere. Does your customer see
    the
    >        same behaviour while using FCL.
    >
    >        Rahul.
    
    yes, well it is quite clear that the ILV buffer allotted for this OID
    is
    overflowing [which suggests that the MIB declaration that defines this
    field as an OCTET STRING of upto 17 chars is not getting properly
    translated into MSL and fed into MCC].
    
    using FCL does not cure the problem. as in the graphical mode, we are
    able to get "all identifiers" but not display them - and if we try to
    get a row by specifying the identifier, we get %NONAME-W-NOMSG and
    %MCC-E-ILVTOOBIG.
    
    both ASN.1 definition and MSL translation are available, if needed.