[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

4015.0. "SNMP icons and alarms problem" by ANOSWS::COMFORT (Spent a little time on the hill) Tue Nov 03 1992 11:44

    
    Hi,
    
    I am currently trying to ascertain answers from both internal and
    customer support services on my problem.  I now have expanded
    and more detailed information about my problem.  First the formalities:
    
    	DECmcc V1.2.0 (secured from the net from the advance SSB issue)
    
    	VMS version	V5.4-3 and V5.5
    
    Problem:
    
    SNMP icons will not change color, even though the event is indicated
    with all approriate severities, etc., in the notification window
    and if using line/form mode with a notify command is issued for the
    appropriate domain.
    
    My latest information:
    
    If the SNMP entity is registered in the DNS root directory, all
    is fine, the icons change color.
    
    If the SNMP entity is registered in a DNS subdir, the icons will
    not change color.
    
    If the SNMP entity is registered in the old MCC V1.1 .MCC_IP directory,
    the alarm fails to function at all. (This may be due to a lack of
    recorded attributes or something.  I get an "Entity Instance not
    Registered" for interface 1 of the SNMP entity and the alarm generates
    an exception).

    I now have two customer site experiencing this problem.  I was issued
    a new notification_fm.exe version 1.2.2, but could not make this
    work with the notify directive, I would get a mcc internal file
    lookup error when using this module with 1.2.0.  This error occurs
    as soon as the notify directive is entered in line mode.
    
    I would appreciate as fast an answer as possible on this issue or
    an explanation of how to get updated software to circumvent this
    problem.
    
    Thanks and regards,
    
    Dave Comfort

T.R	Title	User	Personal Name	Date	Lines
4015.1		YAHEY::BOSE		`Tue Nov 03 1992 17:15`	7
	Dave, Do you encounter this sort of behaviour with SNMP entites only? Can you try this out with other entities. Rahul.
4015.2	try fullname	CTHQ::WOODCOCK		`Tue Nov 03 1992 22:53`	8
	Greetings, You may want to try specifying the FULLNAME in the alarm expression and any specific NOTIFY commands. This worked for me after encountering similar problems. kind regards, brad...
4015.3	re -.*	ANOSWS::COMFORT	Spent a little time on the hill	`Wed Nov 04 1992 09:16`	26
	Hi, < re .-2 > Node4 and Bridges work fine. The bridges are in a subdirectory 3 levels deep. I am attempting to try TSAM, however TSAM is generating a license check fail against the DECMCC-EMS license. As soon as that is resolved, I can try it with TSAM. I will also test with the Data Collector today. Note that the domain icon of the domain that the SNMP entity resides in will light the appropriate color. < re .-1 > By fullname I assume you mean something along the lines of: .test.phred where test is the DNS subdir and phred is the entity All my alarm rules use the DNS syntax, with the exception of Node4 alarms. I have tried using the fullname and the UCX name for both the alarm rules and targeting. But I will test this again. Thank you. Dave
4015.4	include NS	CTHQ::WOODCOCK		`Wed Nov 04 1992 23:25`	12
	> By fullname I assume you mean something along the lines of: > > .test.phred where test is the DNS subdir and phred is the entity Dave, I think (memory fogged) I used the full fullname including namespace. It might be worth the shot. LOCAL_NS:.test.phred best regards, brad...
4015.5	Problem solved, thanks	ANOSWS::COMFORT	Spent a little time on the hill	`Thu Nov 05 1992 10:22`	8
	Brad - Thanks very much, this indeed solved the problem. I apologize for being dense about the fullname thing. Once again many thanks. Dave
4015.6	snmp fullname vs internet name is the problem	MCC1::DITMARS	Pete	`Thu Nov 05 1992 12:50`	28
	This problem crops up over and over again. We should clearly document this, clearly communicate it to our support organizations, and in V.next, make the code smart enough to minimize the possibility of it happening. When you enter "SNMP .foo", you may think ".foo" is a fullname. But the parser thinks it's an internet name, and in the internal AES representation, the datatype is set to internet name. The SNMP AM must be robust enough to try interpretting the instance as either internet name or fullname, regardless of the datatype. Or it's just lucky. :^) The notification FM and IMPM, however, believe the datatype in the AES. When it comes time to do targeting (in the FM) or notification correlation (in the IMPM), the fact that the datatype is "wrong" prevents the "right" things from happening. The simple solution, as Brad points out, it to always use the namespace when refering to an SNMP entity by its fullname in an alarm rule. This forces the parser to interpret the entity's name as a fullname. Leading dots are legal in an internet name, and are not enough to make the parser understand that this is a fullname. A more complicated solution is to refer to the SNMP entity by the exact string that was used when registering it, as shown by the DIRECTORY command (not SHOW!).
4015.7		YAHEY::BOSE		`Thu Nov 05 1992 15:10`	13
	>> The SNMP AM must be robust enough to try interpretting the instance >> as either internet name or fullname, regardless of the datatype. >> Or it's just lucky. :^) Pete, The SNMP AM first tries to use the instance as an Internet Name. If that fails, then it is interpreted as a FullName. This was done to overcome the ambiguity between Internet Name and Full Name. So it is not just plain luck that it works that way. :-) Rahul.