[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

2184.0. "SNMP AM T1.2.4 SHOW problem for single entity" by CUJO::HILL (Dan Hill-Net.Mgt.-Customer Resident) Fri Jan 24 1992 00:13

    I have BMS T1.2.4 installed which includes the SNMP AM, but I have a
    problem when trying to get info on a "single" entity.  No problem when
    using a wild card.  This problem only occurs in FCL, not IMPM.
    --------
    MCC> SHOW SNMP .snmp.node1
    Using default ALL IDENTIFIERS
    
    SNMP .snmp.node1
    AT 23-JAN-1992 22:13:03 Identifiers
    
    No such entity: SNMP .snmp.node1
                             Unknown Entity = SNMP .snmp.node1
    
    ---------
    MCC> SHOW MCC 0 TCPIP_AM ALL CHAR
      (Works fine and shows all chars)
    ---------
    MCC> SHOW SNMP *
      (Works fine and shows all ident for all snmp entities.)
    ---------
    
    Any ideas??
    
    -Dan
T.RTitleUserPersonal
Name
DateLines
2184.2Use complete fullname for SHOW SNMPTOOK::TANEd TanFri Jan 24 1992 09:5078
    	The problem you are seeing is due to the way the parser parses
    the name .snmp.node1 in your example. Let me explain.
    
    	First of all, in the SNMP AM MSL file for the global entity SNMP,
    the identifier list is defined as follows:
    
    	IDENTIFIER = ( Address, Name, Registered Name )
        
    where
                                  
    	ATTRIBUTE Address = 99 : IpAddress
          ...
        ATTRIBUTE Name = 98 : InternetName
          ...
        ATTRIBUTE Registered Name = 97 : FullName
          ...
    
    
    	The order of the identifier list determines how the entity name is
    parsed. In the case of SNMP, the parser will see if the name is an IP
    Address, if not, is it an Internet Name, and if not, is it a namespace
    fullname.
    
    	In your example
    
    	SHOW SNMP .snmp.node1
    
    	I believe you are expecting .snmp.node1 to be a namespace fullname.
    However, to the parser, it knows that it is not an IP Address, but it
    is a valid Internet Name. So the parser will encode it as a Internet
    Name and the FCL will mcc_call the SNMP AM to do a SHOW. Well, SNMP AM
    sees the Internet Name and trying to go to the UCX database (or host
    file on Ultrix) but couldn't find .snmp.node1. So it returns the
    message
    
      No such entity: SNMP .snmp.node1
    			       Unknown Entity = SNMP .snmp.node1
    
    	I believe if you try (suppose your namespace is FOO_NS:)
    
    	SHOW SNMP FOO_NS:.snmp.node1
    
    	you will see the identifiers returned.
    
    
    	As mentioned above, this is due to how the parser works. And also
    the name such as .snmp.node1 is both a valid Internet Name as well as
    a vaild namespace fullname. Unless SNMP does some special processing,
    your have to use the complete fullname (FOO_NS:.snmp.node1) in the SHOW
    SNMP if you really mean a fullname and not an Internet Name.
    
    
    	Just an additional information, the REGISTRATION FM directives
    DIRECTORY, SET reference attributes and SHOW reference attributes do
    have some special processing for SNMP. So in your case, you can do a
    
    	DIRECTORY SNMP .snmp.node1
    
    		or
    
    	DIRECTORY SNMP FOO_NS:.snmp.node1
    
    
    and get the same answer (try it). What we do is if we get an Internet
    Name for SNMP, we try to get the entity from the namespace. If it
    succeeds, we return it. If not, we build a fullname from the Internet
    Name and try to get the entity again. So in effect, when we get an
    Internet Name, we try both Internet Name and fullname.
    
    
    	The fact that SHOW SNMP * works fine is because when FCL sees the
    wildcard, it calls DIRECTORY SNMP * first to get each instance (return as
    fullname form) and then call SHOW SNMP with the fullname for each
    instance.
    
    	Does this explain your problem?
    
    /Ed
2184.3TOOK::SWISTJim Swist LKG2-2/T2 DTN 226-7102Fri Jan 24 1992 10:0610
    NCL has (IMHO) a serious flaw in that you don't say *which* identifier
    attribute you are specifying, yet it allows syntactically ambiguous
    datatypes to be used for the identifiers.  Unfortunately there isn't
    much MCC can do about this at this late date.  I note with some
    amusement that X.500 naming solves this problem (you say which
    attribute's value you are giving), but then introduces a worse problem
    (the CLASS is not specified - it must be inferred from the attribute
    name).   
    
    Standards.  Grumble.
2184.4SNMP AM adding similar "feature"CHRISB::BRIENENDECmcc Bridge|Station|SNMP Management.Fri Jan 24 1992 10:0714
>   	Just an additional information, the REGISTRATION FM directives
>   DIRECTORY, SET reference attributes and SHOW reference attributes do
>   have some special processing for SNMP....
>    
>   ... What we do is if we get an Internet
>   Name for SNMP, we try to get the entity from the namespace. If it
>   succeeds, we return it. If not, we build a fullname from the Internet
>   Name and try to get the entity again. So in effect, when we get an
>   Internet Name, we try both Internet Name and fullname.
 
  The SNMP AM is in the process of adding this "feature" as well
(should be available in for EFT Update (if there is one) and V1.2 SSB).

						Chris
2184.5Using SNMP synonym works as wellCUJO::HILLDan Hill-Net.Mgt.-Customer ResidentSun Jan 26 1992 23:1510
    Thanks for your answers.  I pleased this will be addressed in an
    up-coming release.
    
    By the way, not only does this work:
    MCC> SHOW SNMP my_ns:.snmp.node1 ALL IDENT
    
    So does this (assuming the synonym is "node1"):
    MCC> SHOW SNMP node1 ALL IDENT
    
    -Dan