%---------------------------------------------------------------------
%
% Licensed Materials - Property of IBM, 5697-EAS
% (C) Copyright 1997-2003 IBM Corp
% (C) Copyright 1997-2003 Tivoli Systems, an IBM Company
% All rights reserved
% US Government Users Restricted Rights
% Use, duplication, or disclosure restricted
% by GSA ADP Schedule Contract with IBM Corp
%
%---------------------------------------------------------------------

%---------------------------------------------------------------------
%
% RULESET : correlation
%
%           Tivoli Enterprise Console
%           Correlation & Automation
%           IBM Corporation
%
% DESCRIPTION
%
% This ruleset implements rules supporting the correlation function.
%
%---------------------------------------------------------------------

%---------------------------------------------------------------------
directive: trace

rule:
correlation_configure:
(
	event: _event of_class 'TEC_Start'
		where [ ],
	reception_action:correlation_parameters:
	(
		
	/****************************************************************/
	/* This section customizes the rule set behavior                */
	/* The following listed parameters are safe to be changed when  */
	/* reusing this rule.                                           */
	/****************************************************************/
 
		
		% Sets the default time window when to search for events
		% for correlation and clearing sequences.
        	_correlation_time_window = 600,      % In seconds (default is 10 minutes)
        	
                % Sets the default administrator value used when a rule defined in this rule 
                % set changes an event's state. This identifier is used to differentiate 
                % operations that were originated automatically rather than by the console operator.
		%_correlation_admin = 'correlation.rls',
		_correlation_admin = 'netview.rls',
                
        	% Here you can add event sequences which will be correlated
        	% according the clearing_rule and correlation_rule defined below
        	% the format to add event sequences are through the 
        	% predicates create_event_Sequence and create_clearing_sequence
        	% For example:
        	%
        	%
                %       This defines a clearing relationship between the communicationLost
                %       event and the communicationEstablished event classes defined in
		%	the samples/correlation/apc_ups/apc.baroc file.
                %
                %       create_clearing_event('communicationEstablished',       
                %                             [],
                %                             ['communicationLost'],
                %                             [hostname]
                %                            ),
                %	
		%       This defines a cause-effect correlation sequence between the 
		%  	upsOnBattery, lowBattery,and upsDischarged eventsdefined in
		%	the samples/correlation/apc_ups/apc.baroc file.
		%
		%	 			
		%	create_event_sequence(
		%		['upsOnBattery','lowBattery','upsDischarged'],
		%			%attribute conditions for the cause chain of events
		%		[hostname,['status',not_equals,'CLOSED']],
		%		[
		%			%clearing relationships in the cause chain of events
		%			clears('powerRestored',[],['upsOnBattery'],[]),
		%			clears('returnFromLowBattery',[],['lowBattery'],[]),
		%			clears('dischargeCleared',[],['upsDischarged'],[])
		%		]),
        	%
        	%
        	% More examples of sequences can be found in the samples/correlation
		% directory.
        	%
        	%
 
                 
         /****************************************************************/
         /*  End of customization section                                */
         /****************************************************************/
                	
        	rerecord(correlation_time_window,_correlation_time_window),
                rerecord(correlation_admin, _correlation_admin),
                commit_rule
	)
).

%---------------------------------------------------------------------
% These two rules below perform correlation on incoming events using
% the information defined with the create_event_sequence and
% create_clearing_event predicates in the TEC_Start rule above.
%
% Note that these two rules execute on every event received because
% the event filters specify any event class. Normally, different
% event filters would ensure that only specific events trigger the
% appropriate rules.
%---------------------------------------------------------------------

%---------------------------------------------------------------------
% RULE: clearing_event
%
% DESCRIPTION
%
% The first rule ("clearing_event") processes clearing events only.
% Every event that the clearing event clears that was received within
% the last correlation_time_window is closed by the rule. It then exits rule
% processing.
%---------------------------------------------------------------------
rule: clearing_event:
(
   event: _event of_class _class
   where [
   ],

   action: check_for_clear:
   (
      % checks if the event is defined
      % as a clearing event
      is_clearing_event(_event),

      recorded(correlation_admin, _admin),
        
      % for every event that is cleared
      ( recorded(correlation_time_window,_correlation_time_window),
        % all_clear_targets(_event, _cleared, _correlation_time_window, 0),
        all_clear_targets(_event, _cleared, _correlation_time_window, 30),

        % close cleared event
        change_event_status(_cleared, 'CLOSED'),
        change_event_severity(_cleared, 'HARMLESS'),
        change_event_administrator(_cleared, _admin)
      ;
        commit_rule
      ),
	% Next line added by JC and comma on end of previous line
	%   to close the incoming clearing event
	set_event_status(_event, 'CLOSED')
   )
).

%---------------------------------------------------------------------
% RULE: correlate
%
% DESCRIPTION
%
% The second rule ("correlate") is executed only if the event is not
% a clearing event. It searches for the logically earliest related
% event. If it finds a related event within the last correlation_time_window, 
% it determines if the found event is a cause or effect of the new event,
% links the two events appropriately, acknowledges the effect event
% (because it is an effect of a known cause) and exits rule
% processing.
%---------------------------------------------------------------------
rule: correlate:
(
   event: _event of_class _class
   where [
   ],

	% Next action added by JC to drop duplicates and add to repeat count
%	reception_action: dup_detect:(
% 	    first_duplicate(_event, event: _dup_ev
%	      where [status: outside ['CLOSED'] ],
%	      _event -3600 -30),
%	    add_to_repeat_count(_dup_ev, 1),
%	    drop_received_event,
%	    commit_rule
%  ),

   action: check_related_events:
   (
      recorded(correlation_time_window,_correlation_time_window),
      
      % searches for the first related event in the cache
      first_related_event(_event, _related, _type, _correlation_time_window, 30),
      recorded(correlation_admin, _admin),   

      % if it is a causal relation ('c')
      ( _type == 'c',

        % acknowledges the first
        change_event_status(_event, 'CLOSED'),
        change_event_severity(_event, 'HARMLESS'),
        change_event_administrator(_event, _admin),

        % and links it to the second event
        link_effect_to_cause(_event, _related)
      ;
      
      % if it is a effect relation ('e')
        _type == 'e',
          
        % acknowledges the second
        change_event_status(_related, 'CLOSED'),
        change_event_severity(_related, 'HARMLESS'),
        change_event_administrator(_related, _admin),

        % and links it to the first event
        link_effect_to_cause(_related, _event),
	% There may be other effect events that we also want to link
	redo_analysis(_event)
      ),
      commit_rule
   )
).