Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Debugging and Testing TEC Rules

News See Also Recommended Links Tracing rules TEC Rules Programming Typical operations with the rulebase
wpostemsg, postemsg wpostzmsg, postzmsg tec_agent_demo Prolog Etc

The most common problems related to rules are:

  1. Failure to recompile, reload, and activate the rule base.
  2. Failure to restart all Tivoli Enterprise Console processes after making changes to the rule base.
  3. Editing rules in Windows with the editor that introduces Windows end-of-line (^M) character in a rule set. Due to weakness of the IBM design this causes unpredictable results, such as the TEC failing to start or the event console not being updated.

If rules are not working properly or as you expect the first step is to compile the rules with tracing on and look at the trace output on a subset of events that created specifically for debugging.

The first task is to create set of test events and send them to TEC. There are at least three methods of doing this:

  1. wpostemsg, postemsg, wpostzmsg, postzmsg commands

    These commands send events whose characteristics are specified as arguments. See the Tivoli Enterprise Console Reference Manual for the description of each command.

  2. The tec_agent_demo program. Allows you to send event in a way similar to how Unix start services. The program and the files should be run on the event server host. This is definitely not the best design so expect some learning curve. Each event file should contains a single event. The events sequencing is specified in a control file, which the program uses to prompt you before sending each event. You probably should write a Perl script to generate control file automatically from the content of the folder if you want to preserve sanity. Different test scenarios are achieved by grouping events in several different control files and then specifying the control file as an argument to the program.
  3. The SendEvents program

    The SendEvents program sends events that have been retrieved from the reception log and written to a specific directory structure. The events are sent using a time interval. The interval can be used to do the following:

To see how the message arrived and in what format, type in wtdumprl on the TEC server. For example:

wtdumprl -o DESC | more

or

wtdumprl -t 'May 16 10:00:00 2006' 
	-e 'May 10 10:30:00 2006' > tec.out

You can also create event files

From a bash or UNIX shell command line, enter the following command. The directory argument specifies the directory to write the event folders (which contain event files), events_list file, and time_list file.
wtdumprl | $BINDIR/TME/TEC/contrib/ParseEvents.pl -d directory

The event files are generated in a directory structure like the following figure. For this example, the preceding command was issued with the -d /test3 argument.

In more complex case you need tracing. Tracing is activated by option -trace in wrb -comprules command.

Here is a relevant quote from SG246614 Rule tracing and profiling :

In Tivoli Enterprise Console 3.7, the new wrb command is introduced to handle all tasks regarding rule bases. The Tivoli Enterprise Console commands of previous versions are still present for backward compatibility, but it is necessary to use only the new command set for working with rule bases in Tivoli Enterprise Console 3.7. All new architecture considerations are only supported by the new wrb command set. The CLI command to compile a rule base has the following syntax:

wrb -comprules [-profile] [-trace] <rule base name>

Where: The -trace option provides the rule trace functionality that is already known from earlier Tivoli Enterprise Console versions. Rule tracing can be activated either by using the CLI commands or the GUI. Enabling rule tracing via CLI and Enabling rule tracing via GUI describe both the CLI and GUI way to initiate rule tracing. The -profile option applies the new functionality of rule profiling to a rule base when compiling it.

See Rule profiling for more details.

Creating event files from events in the reception log

Creating event files from events in the reception log

A program is available to parse the events in the reception log for use with the tec_agent_demo or the SendEvents programs. This procedure can be a quick way for you to create events for testing rules.

To create events for testing from those in the reception log:

  1. Ensure your Tivoli environment is initialized (for example, the setup_env.sh command has been issued).
  2. From a bash or UNIX shell command line, enter the following command. The directory argument specifies the directory to write the event folders (which contain event files), events_list file, and time_list file.
    wtdumprl | $BINDIR/TME/TEC/contrib/ParseEvents.pl -d directory

    The event files are generated in a directory structure like the following figure. For this example, the preceding command was issued with the -d /test3 argument.

    Each event file is within an event folder. For example, the event0001 file is within the event0001 folder. The numbering sequence is internally generated by the ParseEvents.pl program and begins with the oldest event; that is, the event in the event0001 file was received before the event in the event0002 file.

    Once you have captured the events in event files, you can rename them, modify them, and move them for use with the tec_agent_demo program. Or, you can use the directory structure as it is with the SendEvents program.

Here is a tip from GulfBreeze Software :

One of the more common tasks is dumping received events from TEC to a flat file for archiving. Here is an example:

To do straight reception log dumps, consider using a script like this one that I run all the time. This script will dump all events from the reception log to a file named with the date and then perform a clear of the TEC database.

#!/bin/sh
. /etc/
Tivoli/setup_env.sh
LOGFILE=/usr/local/
Tivoli/custom/logs
dat=`date +"%m%d%Y" `
date=`date`
tec_date=`date +"%h %d 00:00:00 %Y"`
echo WTDUMPRL Started at $date >> $LOGFILE/tec_maint.log
`wtdumprl -t "$tec_date" >$LOGFILE/$dat.events`
echo WTDUMPRL Finished at $date >> $LOGFILE/tec_maint.log
echo STARTED TEC Event Report at $date >>$LOGFILE/tec_maint.log
echo GZIP Started at $date >> $LOGFILE/tec_maint.log
`gzip -f $LOGFILE/$dat.events`
echo GZIP Finished at $date >> $LOGFILE/tec_maint.log
echo WTDBCLEAR Started at $date >> $LOGFILE/tec_maint.log
`wtdbclear -elt 259600`
echo WTDBCLEAR Finished at $date >> $LOGFILE/tec_maint.log

Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[June 03, 2005] Dumping data from the TEC Database with WTDUMPRL by jlsham (GulfBreeze Software)

Posted by: jlsham on Friday, June 03, 2005 - 05:40 PM

One of the more common tasks is dumping received events from TEC to a flat file for archiving. Here is an example:

To do straight reception log dumps, consider using a script like this one that I run all the time. This script will dump all events from the reception log to a file named with the date and then perform a clear of the TEC database.

#!/bin/sh
. /etc/
Tivoli/setup_env.sh
LOGFILE=/usr/local/
Tivoli/custom/logs
dat=`date +"%m%d%Y" `
date=`date`
tec_date=`date +"%h %d 00:00:00 %Y"`
echo WTDUMPRL Started at $date >> $LOGFILE/tec_maint.log
`wtdumprl -t "$tec_date" >$LOGFILE/$dat.events`
echo WTDUMPRL Finished at $date >> $LOGFILE/tec_maint.log
echo STARTED TEC Event Report at $date >>$LOGFILE/tec_maint.log
echo GZIP Started at $date >> $LOGFILE/tec_maint.log
`gzip -f $LOGFILE/$dat.events`
echo GZIP Finished at $date >> $LOGFILE/tec_maint.log
echo WTDBCLEAR Started at $date >> $LOGFILE/tec_maint.log
`wtdbclear -elt 259600`
echo WTDBCLEAR Finished at $date >> $LOGFILE/tec_maint.log

Sending events with the tec_agent_demo program

The tec_agent_demo program sends events you create within event files. Each event file contains only one event. The events to send are specified in a control file, which the program uses to prompt you before sending each event. You can create test scenarios for your rules by grouping events in specific control files and then specifying the control file as an argument to the program. The program and the files it uses must be run on the event server host.

Configuration prerequisites for using the tec_agent_demo program

The tec_agent_demo program reads a control file that lists the names of files containing the events to send. The control file must be named events_list. The following example shows the contents of a control file.

TEC_Start
NT_NAV_start
NT_NAV_stop
NT_Perf_Alert
TEC_Stop

Each event must be contained within a single file, referred to as an event file. The control file and event files can be in the same directory or different directories. If they're in different directories, you must specify the paths to the event files listed in the control file; for example, /test/TEC_Start.

The example on page *** shows the contents of the NT_Perf_Alert event file. The other event files are formatted similarly but contain different events for this particular test scenario. The following is the syntax for event files:

NT_Performance_Alert;
hostname=mfoster; origin=146.84.39.103; category=0;
eventType=Information;sid=N/A;sub_source=PerfMon; id=2000;
msg='\\MFOSTER ; Object: Processor ; 
Counter: % Processor Time ; Instance: 0 ; Parent: ; 
Value: 13.586 ; Trigger: > 1.000'; 
date='Apr 29 14:36:34 2000';
sub_origin=mfoster;computer=\\MFOSTER;
END

See Creating event files from events in the reception log for information about an easy way to create event files.

Using the tec_agent_demo program

To send events:

  1. From a bash or UNIX shell command line, enter the following command after initializing the Tivoli environment (for example, after issuing the setup_env.sh command)
    export TEC_BIN_DIR=$BINDIR/TME/TEC 
  2. Enter the following command to send the events listed in the control file:
    $TEC_BIN_DIR/tec_agent_demo -data /control_file_dir
    The control_file_dir is the directory where the control file is located. The control file must be named events_list. The program displays each event that it is ready to send.
  3. Press Enter to send each event. The event is sent to the event server for processing. To exit the simulator program before all of the events listed in the control file are sent, press Ctrl+c.

Tivoli Global User Group Community Newsletter, February 2005

Hints and Tips - Tivoli Monitoring Tivoli Ideas:

To enhance the monitoring of your Tivoli infrastructure, consider the following examples:

I know my endpoints, gateways, Tivoli Servers are running because:

I know my Resource Models are working properly because: I know my Error Log forwarding is working because: You'll find 65 technical Tivoli Field Guides on the Support Web Site. Download Tivoli Field Guides from: http://www- 306.ibm.com/software/sysmgmt/products/support/Field_ Guides_Technical.html

Orb-data Tips

Tivoli Field Guide - The "If Then Else" of Event Flow in IBM Tivoli Enterprise Console, version 3.9

The purpose of this white paper is to educate the concerned audience about all the different stages and paths that an event can undergo on its way to the IBM Tivoli Enterprise Console Event Server (referred to as &#8220;Event Server&#8221; from here on out). Also, this document will be of great help to someone who is trying to diagnose a problem of events not being received. The flowcharts included that show the event flow will definitely help pinpoint specific areas to analyze further.

IBM Software Support Tivoli Tivoli Technical Field Guides

Tivoli Field Guide - Getting the Most out of Traces

If you have ever called Tivoli Support to get help figuring out what is wrong in your Tivoli environment, then you know how hard it is to get help regarding traces. This field guide will teach you to ensure that the trace files you send to Tivoli Support are useable. You will also learn how to produce and read your own trace files, so you may be able to resolve your own problem rather than calling Support.

IBM Redbooks Troubleshooting a Problem on Tivoli Enterprise Console to a IBM Tivoli Business Systems Manager Connection

If something goes wrong and the object is not shown at the IBM Tivoli Business Systems Manager console, we have to analyze the source of the failure:

  1. First, check whether the conditions have been met to cause an alert at the endpoints where the monitors have been distributed. For DM classic, we use wlseng -l <enpoint_name>, and for IBM Tivoli Monitoring or DM Advanced Edition, we use wdmlseng -e <endpoint_name> -verbose.
  2. If these monitors fire correctly and the network communications within the Tivoli Management Region are working, the next step for this event is to check the TEC. When TEC receives a recognized event, it is parsed by the rules engine. The rule that will parse and act upon classic DM events and send them to IBM Tivoli Business Systems Manager is ihstdmon.rls.
  3. The wtdumprl command is used to display all received events and their disposition, whether they are processed or get a parsing failed status. When parsing fails, it means that either the class is not defined or there is an unknown slot (field) or an unparsable slot.
  4. The wtdumptr command is used to display the completion of the action invoked from the TEC rules for an event. For example, the completion code of invoking the event enablement exits.
  5. If the received event matches the profile of an event that has been slated to be sent to IBM Tivoli Business Systems Manager, a TEC exit ihstztec is invoked. This exit also is invoked when there is a change of status of this event to ACK or CLOSE. Again, we confirm this from the rule trace, if you have enabled the rule tracing from the EventServer setting.
  6. If you examine the trace of the rules, you will see the event that matches the condition that you want and then the ihstztec exit is invoked. This formats the data and passes it onto the ITBSM Event Enablement service. This in turn sends this event to the Agent Listener. We have seen the usage of wtdumprl, wtdumptr, and the tracing of the rule base that has been used to show the data flow from within TEC. The most common problem you will see from the wtdumprl is that of an unprocessed event. If this is the case, check the classes (BAROC files) whose addition may have been missed. The most useful trace is that of the rule base, as you may have made a syntax error with the customization of a rule.
  7. The Event Enablement engine itself also keeps log files. Four log files, two for the task server and two for event enablement, are available in the $BINDIR/TDS/EventService/log directory. You need to start tracing for event enablement to get meaningful information in the log file. Run the trace using the tserver ee_utility -t command. To format these log files, we use the ihszfmt command, which is located in the $BINDIR/TDS/EventService/bin subdirectory.
  8. The next part of the data flow we examine is that of the Agent Listener. Verify that the Agent Listener is connected to the event enablement with the gemeeconfig command.
  9. The next point to check is the Agent Listener log file. The amount of information logged in the log file depends on the loglevel, which can be set in the Windows registry. When the loglevel is set to 0, everything will be traced. The default loglevel setting is 2. The file is named AL + Timestamp of creation, so the file AL200211141427.log is the Agent Listener log that is created on 14 November 2002, at 14:27.

ORB Data Links

RE [TEC] Refreshing the Rules cache

From: [email protected]
[mailto:[email protected]]On Behalf Of Blankenship, I.V.
(Contractor)
Sent: 11 March 2005 13:51
To: '[email protected]'
Subject: RE: [tme10] [TEC] Refreshing the Rules cache


The save_event_cache predicate dumps the event cache to a flat BAROC file.
This file is formatted similarly to a BAROC class definition file but does
have some differences.

CLASS_NAME ;
SLOT_NAME =
SLOT_VALUE;
.END

The restore_event_cache predicate calls bo_parse_baroc_file/2 to read the
file and add the instances to the event cache. Both save and restore
predicates call get_config_param to read the your
$BINDIR/TME/TEC/.tec_config file for the event_cache_file parameter and will
only work if that parameter is defined. To dump your cache to an arbitrary
file you can use print_cache(FILENAME). To read from any BAROC file do
something like this:

bo_get_config_options(_old_quote,_old_parse_in,_old_parse_out),
bo_set_config_options(_old_quote,0,_old_parse_out),
bo_parse_baroc_file(FILENAME,add_to_cache),
bo_set_config_options(_old_quote,_old_parse_in,_old_parse_out),


If you wanted to "reload" the event cache I suppose you could write a
program or perl script to read from the event repository to build a BAROC
file, iterate through all instances of events in your cache and remove them
with bo_delete_instance/1 and then call bo_parse_baroc_file/2 to reload the
events.

The real question is not "can you" (there is almost always a way...) but
"why would you need to?" Are you experiencing problem where you events in
cache are out of sync with your repository as a result of forced cache
cleaning? If so you would be better off implementing better duplicate detect
rules, drop and or close irrelevant events, and increase your event cache
size.

SendingEvents

Sending a Tivoli event from a Unix script involves the following steps:

- Define an event class

- Generate events

- Choose a method for closing events

Defining an event class

Every event must have an class name that identifies it to the Tivoli Enterprise Console (TEC). By convention, we will use unix_<program name> for the events sent by programs or scripts on the Unix systems, and nt_<program name> for Window NT/2000. The ESM staff will set up the event classes as requested. Put a request in the ESM-Incoming queue in TPM or send e-mail to [email protected].

Generating events

Issue a wpostemsg command to send an event to the Tivoli Enterprise Console (TEC), which is the event correlation engine.

The format of the command is as follows:

wpostemsg [-m message] [-r severity] [hostname=<host>] [value=<value>] [probe_arg=<probe-argument>] [response_level=reset] class source

The wpostemsg command requires that the proper environment be set up. The easiest way to do this is with the "tiv" script in /var/local/Tivoli/Princeton/bin. To issue a single command, just give the tiv command followed by the command. The tiv command with no arguments will start a shell with the environment set up.

Arguments:

  • message is a arbitrary text message explaining the meaning of the event.
  • severity is one of FATAL, CRITICAL, MINOR, HARMLESS, or WARNING
  • class is the class defined for this event.
  • source is "unix" or "windows_nt"
  • <host> is the unqualified name of the host for which the event is to be reported.
  • <value> is the value (if any) associated with this event.
  • <probe_argument> is any qualifier associated with the event, such as the disk, network interface, etc. to which the event applies. Use this to distinguish different events of the same class coming from the same host
  • <response_level> is an optional argument. If it is specified as "reset", then an open event with the same hostname, class and probe_arg values will be closed.

Examples:

wpostemsg -m 'Percent disk' -r WARNING hostname=isserver1 value=98 probe_arg='/tmp space' unix_dfwarn unix

wpostemsg -m 'Percent inodes' -r WARNING hostname=isserver1 value=98 probe_arg='/tmp inodes' unix_dfwarn unix

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

ORB Data Links

Rule Builder's Guide/Table of Contents

Testing and Debugging New Rules

  • Event Simulator
  • Debugging Rules
  • Debugging Information
  • Rule Debugging Example
  • Troubleshooting Tivoli Using the Latest Features

    This IBM Redbook is an update of the existing Tivoli Enterprise Internals and Problem Determination, SG24-2034 redbook. The material is revised and updated for Tivoli Management Framework and applications post Version 3.6. Some of the applications that are covered from the troubleshooting point of view in this redbook are:

    Tivoli Management Framework and related concepts
    Tivoli Enterprise Console
    IBM Tivoli Monitoring
    Tivoli Business Systems Manager
    Tivoli Enterprise Data Warehouse
    Tivoli Workload Scheduler
    IBM Tivoli Configuration Manager
    Tivoli Remote Control
    IBM Tivoli Access Manager for Operating Systems

    Another subject that is associated with troubleshooting is proper maintenance of your Tivoli environment, because proper Tivoli maintenance procedures eliminate many potential Tivoli problems. In addition to the troubleshooting information, this redbook briefly touches on some best practices information for maintaining your Tivoli environment, mostly from the troubleshooting perspective.

    Part 1. Introduction, pter 14. Tivoli Enterprise Console

    Information about an easy way to create event files.

    IBM Redbooks TEC Implementation Examples

    SG246614 Tivoli Enterprise Console

    This chapter provides information for troubleshooting Tivoli Enterprise Console (TEC) 3.7 and 3.7.1. There was a major architectural change in the product from Tivoli Enterprise Console 3.6 to Tivoli Enterprise Console 3.7, and in this chapter, we will focus on Tivoli Enterprise Console 3.7.X.

    Important: There are a number of important fixes that are included in Tivoli Enterprise Console 3.7.1, so if you are working with Tivoli Enterprise Console 3.7 level, we strongly suggest you upgrade to Tivoli Enterprise Console 3.7.1.

    We will refer the product name as Tivoli Enterprise Console 3.7, but the discussion is also relevant for Tivoli Enterprise Console 3.7.1. We will pinpoint a few places where Tivoli Enterprise Console 3.7.1 troubleshooting differs from Tivoli Enterprise Console 3.7.

    This chapter will cover the following:

    Section 14.1, Tivoli Enterprise Console architecture

    Section 14.2, Installation debugging

    Section 14.3, Tivoli Enterprise Console 3.7 tracing and logging

    Section 14.4, RIM tracing

    Section 14.5, Rule tracing, profiling, logging, and reporting

    Section 14.6, TEC Java Console 3.7 debugging

    Section 14.7, TEC Sample Event Information 3.7: Spider daemon

    Section 14.8, Tivoli Enterprise Console 3.7 Windows Event Log Adapter debugging

    Sending events with the tec_agent_demo program

    The tec_agent_demo program sends events you create within event files. Each event file contains only one event. The events to send are specified in a control file, which the program uses to prompt you before sending each event. You can create test scenarios for your rules by grouping events in specific control files and then specifying the control file as an argument to the program. The program and the files it uses must be run on the event server host.

    The tec_agent_demo program reads a control file that lists the names of files containing the events to send. The control file must be named events_list. The following example shows the contents of a control file.

    TEC_Start
    NT_NAV_start
    NT_NAV_stop
    NT_Perf_Alert
    TEC_Stop

    Each event must be contained within a single file, referred to as an event file. The control file and event files can be in the same directory or different directories. If they're in different directories, you must specify the paths to the event files listed in the control file; for example, /test/TEC_Start.

    The example on page *** shows the contents of the NT_Perf_Alert event file. The other event files are formatted similarly but contain different events for this particular test scenario. The following is the syntax for event files:

    NT_Performance_Alert;
    hostname=mfoster; origin=146.84.39.103; category=0;
    eventType=Information;sid=N/A;sub_source=PerfMon; id=2000;
    msg='\\MFOSTER ; Object: Processor ; 
    Counter: % Processor Time ; Instance: 0 ; Parent: ; 
    Value: 13.586 ; Trigger: > 1.000'; 
    date='Apr 29 14:36:34 2000';
    sub_origin=mfoster;computer=\\MFOSTER;
    END

    See Creating event files from events in the reception log for information about an easy way to create event files.

    Using the tec_agent_demo program

    To send events:

    1. From a bash or UNIX shell command line, enter the following command after initializing the Tivoli environment (for example, after issuing the setup_env.sh command)
      export TEC_BIN_DIR=$BINDIR/TME/TEC 
    2. Enter the following command to send the events listed in the control file:
      $TEC_BIN_DIR/tec_agent_demo -data /control_file_dir
      The control_file_dir is the directory where the control file is located. The control file must be named events_list. The program displays each event that it is ready to send.
    3. Press Enter to send each event. The event is sent to the event server for processing. To exit the simulator program before all of the events listed in the control file are sent, press Ctrl+c.

    Etc

    In addition, both tracing and profiling has been enhanced to allow a more rule specific debugging. This is described in Enhanced rule tracing and profiling.

    Event Activity Reports

    Event Activity Reports represent a textual listing of event activities in the rule engine. The following items can be specified to report and can be dynamically changed during reporting:

    The relevant parts of the im.rls file are shown Example 14-35. The im_configure rule includes the initial configuration settings to create an Event Activity Report (the editable parts are shown in bold):

    Example 14-35 Event Activity Report

    ----------------------------------------------------------------
    % NAME - IM Configuration.
    % This rule is used to configure the IM rule behavior.
    % Event activity reporting, event filtering, maintenance mode,
    % heartbeat, thresholding and event correlation can be activated.
    %---------------------------------------------------------------- 
    rule:  im_configure : (
      event: _event of_class  'TEC_Start'
        where [],
       reception_action: im_parameters: (
       ...
          %----------------------------------------------
          % Activate rule functionality (active/inactive)
          %----------------------------------------------
          record(event_activity,inactive),
          ...
          %------------------------------------------------------------------
          % Event activity
          % This section allows the event activity report to be customized.
          % The name of the report file, the reporting frequency, 
          % event reporting threshold, events to exclude from the report and 
          % attribute criteria to include in the report can be specified.
          %------------------------------------------------------------------
          ( recorded(event_activity,active) ->
             _reporting_frequency is 20,                     % Write statistics this often (in seconds)
             init_event_activity('/tmp/event_activity',      % Store report in this file  
                                  ['TEC_Heartbeat',          % Do not report these events
                                   'TEC_Maintenance'],
                                  [ source,                  % Attribute reporting criteria
                                    hostname,                % Can be count of single attribute
                                    severity,
                                    status,
                                    [hostname,severity],     % Or multiple attributes
                                    [class,hostname]         % use class key word to report by class name
                                   ],
                                   5                          % Do not report counts less than this 
                                  ),
             first_instance(event:_ev of_class 'TEC_Tick' where [ ]),
             set_timer(_ev, _reporting_frequency, 'Event Activity Report')
          ;
            true
          ),
       ...
    ).

    To enable Event Activity Reporting, change the line:

    record(event_activity,inactive),

    to:

    record(event_activity,active),

    In the Event activity section, all settings for what should be reported can be applied. The _reporting_frequency can be specified as well as the initial event activity settings, such as:

    init_event_activity(	output_file_name,
    	event_exclusion_list,
    	attribute_reporting_criteria,
    	reporting_threshold)

    The Event Activity rules provided with the im.rls file in the default rule base are shown Example 14-36.

    Example 14-36 Event Activity rules

    %-----------------------------------------------------------------------------------------
    % Collect event activity statistics:
    % This rule is used to collect event activity statistics. It is activated when statistics are turned on in the initialization rule.
    %-----------------------------------------------------------------------------------------
    rule: update_event_activity: (
      event: _event of_class _class
        where [],
      reception_action: update_activity: ( 
         recorded(event_activity,active),   
         update_event_activity(_event)
      )
    ). 

    %-----------------------------------------------------------------------------------------
    % Print Event Activity Report:
    % This periodic call prints the event activity report. Report properties are set in the initialization rule. After the report is printed, all statistics are reset.
    %-----------------------------------------------------------------------------------------
    timer_rule: reset_event_activity: (
      event: _event of_class _class
        where [],
      timer_info: equals 'Event Activity Report',
      timer_duration: _rep_freq,
      action: reset_activity: ( 
         recorded(event_activity,active),
         print_event_activity,
         reset_event_activity,     
         set_timer(_event,_rep_freq,'Event Activity Report')
      )
    ).


    Etc

    Society

    Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

    Quotes

    War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

    Bulletin:

    Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

    History:

    Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

    Classic books:

    The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

    Most popular humor pages:

    Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

    The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


    Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

    FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

    This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

    You can use PayPal to to buy a cup of coffee for authors of this site

    Disclaimer:

    The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

    Last modified: March 12, 2019