[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

4081.0. "TSAM alarm rule to check Software Version" by CUJO::HILL (Dan Hill-Net.Mgt.-Customer Resident) Fri Nov 13 1992 01:29

    I wrote an alarm rule to poll a DECserver 100 every few days to check
    the SOFTWARE VERSION.  The error returned (sorry I don't recall the
    exact message) indicates a datatype problem.
    
    What's wrong with this expression?
    
    (TERM .DECDS1 SOFTWARE VERSION <> "V2.0.0", AT EVERY 99:00)
    
    Thanks,
    Dan

T.R Title User Personal
Name Date Lines

4081.1 Don't know... TOOK::FONSECA I heard it through the Grapevine... Fri Nov 13 1992 15:16 16

T.R	Title	User	Personal Name	Date	Lines
4081.1	Don't know...	TOOK::FONSECA	I heard it through the Grapevine...	`Fri Nov 13 1992 15:16`	16
	Dan- The data type for this attribute is Latin1String, so I assume this test should work. I'm not an expert at alarms though, so I can't tell you if there is some other problem with the alarm rule. I tried doing a show on this attribute back here on our DS100, and did not see anything unusual, so I don't have an answer. By the way, when you are having alarm rule problems, and you think it might be caused by the datatype of the attribute, you can quickly check that in the MRM. The postscript version is 500 pages long so to forgo that mess, you'll probably want to just pop into an editor on the text version (located in SYS$COMMON:[SYSHLP.EXAMPLES.MCC]MCC_TERMSERVER_AM_SPEC.TXT, or in saveset C if you did not choose to install it originally.) -Dave

Dan-

The data type for this attribute is Latin1String, so I assume this
test should work.  I'm not an expert at alarms though, so I can't
tell you if there is some other problem with the alarm rule.  I tried doing
a show on this attribute back here on our DS100, and did not see anything
unusual, so I don't have an answer.

By the way, when you are having alarm rule problems, and you think it might be
caused by the datatype of the attribute, you can quickly check that in
the MRM.  The postscript version is 500 pages long so to forgo that
mess, you'll probably want to just pop into an editor on the text
version (located in SYS$COMMON:[SYSHLP.EXAMPLES.MCC]MCC_TERMSERVER_AM_SPEC.TXT,
or in saveset C if you did not choose to install it originally.)

-Dave