[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

3038.0. "WILCARDING on ALARM_FM (DECmcc/ULTRIX T1.2.7)" by ZTOIS1::VISTA (Renato VISTA, SIS Strasbourg, France) Wed May 20 1992 12:08

    
    Hi,
    
    My customer uses a DECmcc/ULTRIX T1.2.7 platform as a Field Test
    product on a DECstation 5000/125 (32 MBytes).
    
    As he wants to evaluate the hardware and software capabilities in the
    FAULT MANAGEMENT functional domain, he defines several steps of volume,
    polling intervals via different Access Modules (including timeouts
    problems).
    
    So, he uses different FCL directives with wildcarding option :
    
    1st step...
    
    CREATE MCC 0 	ALARM RULE rule_<class>_<entity>
    		        EXPRESSION = ( 	<rule_expression>,
    					AT EVERY = <polling interval>), -
    			IN DOMAIN = <domain>
    
    2nd step...
    
    ENABLE MCC 0 	ALARM RULE *,
    			IN DOMAIN = <domain>
    
    
    3rd step... after evaluating and testing...
    
    DISABLE MCC 0 	ALARM RULE *,
    			IN DOMAIN = <domain>
    
    Messages "Normal operation will be terminated" are displayed.
    
    
    4th step...
    
    DELETE MCC 0 	ALARM RULE *,
    			IN DOMAIN = <domain>
    
    In this case, two kinds of messages are sent :
    
    "Entity deleted successfully", for rules deleted effectively...
    
    "Enabled rules cannot be deleted", for rules not deleted yet...
    For those not-deleted rules, he runs a new DELETE MCC 0...command.
    Depending of the volume he proceeds, he has to run that command more
    than two times !!...
    
    
    FIRST POINT/QUESTION :
    
    Are those consecutive streams of FCL/MCC DELETE+wilcarding commands a 
    normal and expected functional specification of DECmcc ? Or is that
    behavior the result of the DECmcc multi-processes (inter-communication)
    in ULTRIX environment ?
    
    
    SECOND POINT/QUESTION :
    
    Depending of the volume of rules to disable and delete, some rules stay
    in an ENABLED status althought many DELETE..*... commands are done
    via another FCL user-processes. And, althought they are seen as
    ENABLED, those "ghost" rules are not running effectively (no evaluation
    done)...
    
    Have you got any idea about those behaviors and problems ?
    
    Many thanks.
    Renato

T.R	Title	User	Personal Name	Date	Lines
3038.1	Also on VMS	SUBURB::SMYTHI	Ian Smyth 830-3869	`Wed May 20 1992 12:42`	37
	FWIW, I've observed similar behaviour with 1.2.7 on VMS, and not only with wildcards. eg Enable MCC 0 Alarm Rule 1...... Enable MCC 0 Alarm Rule 2...... Enable MCC 0 Alarm Rule 3...... . . . Enable MCC 0 Alarm Rule 30...... wait a while. Disable MCC 0 Alarm Rule 1...... Disable MCC 0 Alarm Rule 2...... Disable MCC 0 Alarm Rule 3...... . . . Disable MCC 0 Alarm Rule 30...... Delete MCC 0 Alarm Rule 1...... Delete MCC 0 Alarm Rule 2...... Delete MCC 0 Alarm Rule 3...... . . . Delete MCC 0 Alarm Rule 30...... Not all rules are deleted. The disable step must be repeated as per .0 . The problem doesn't occur if SPAWN WAIT 00:00:05 commands are placed between each disable command. regards, Ian
3038.2	QAR'd as 3040 in MCC_INTERNAL database	DADA::DITMARS	Pete	`Wed May 20 1992 15:54`	0
3038.3	OK for QAR MCC_INTERNAL database, but how ?	ZTOIS1::VISTA	Renato VISTA, SIS Strasbourg, France	`Thu May 21 1992 04:28`	12
	Hi Pete, My customer has DECmcc/ULTRIX T1.2.7 as an official Field Test platform. So we can access to a specific QAR database on node NACQAR via QAR_PEUGEOT account. But how can we access to MCC_INTERNAL QAR database ?? Thank you for your help ! Renato
3038.4		MCC1::DITMARS	Pete	`Fri May 22 1992 17:47`	4
	My mistake. Someone (you, your customer, or me) should QAR the problem in the external QAR database. Preferably someone using the PEUGOT account so we can respond directly to them when the problem is resolved.
3038.5	QAR #415 via QAR_PEUGEOT account...	ZTOIS1::VISTA	Renato VISTA, SIS Strasbourg, France	`Tue May 26 1992 09:21`	4
	QAR #415 sent via QAR_PEUGEOT account... Renato