||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|
|News||HP Operations Center||Recommended Links||Event Correlation Technologies||Correlation Composer|
|Perl-based Event Correlation||Duplicate Message Suppression||Auto closure of the message||Humor||Etc|
Note: HP renamed the product called now HP operations manager way too many times. Also it is very inconsistent with using abbreviations. Here we will assume that the term "HP Operations manager" and abbreviations HPOM, OMU, and OVO mean the same thing :-)
There are three level of event correlation in HPOM (aka HPOM)
The Composer comes packaged with six Correlator Templates, that ease the creation of correlation solutions by providing correlation models for the most common correlation tasks. The Composer with the Correlator Templates forms the basis for simple correlation tuning and development. The packaged Correlation Templates are:
In addition to the predefined Correlator Templates, that are explained in the sections below, custom requirements can be configured using the User-Defined Correlator Template.
In general terms, messages that are generated by the conditions defined in typical HPOM message source policies are used as input by the event correlation (EC) policies of HPOM. The event correlation policies then process the HPOM messages and, where appropriate, generate new messages, which display in the Java GUI Message Browser in the usual way.
HPOM supplies a set of default correlation policies that you can assign, distribute, and use in the same way as other HPOM policies. However, event correlation policies may be modified only with the ECS Designer GUI, which you use to create and verify new EC policies. These default event correlation policies serve as examples. You can customize these example policies to meet the needs of your particular environment.
The HPOM message source policy enables you to specify which condition generates a message. The policy also enables you to determine whether the generated message is copied or diverted to the Message Stream Interface (MSI). From the MSI, the generated message can be passed to and processed by the event correlation policy. HPOM allows you to copy, rather than divert, messages to the correlation engine. As a result, critical messages are not delayed or lost in the correlation process. This feature is particularly useful for troubleshooting.
The event correlation policy determines which event correlation circuit the messages passes through. It does so by matching the Message-type attribute specified in the message condition with the message attribute specified in the Event-type field of the Input (or first) node of the event correlation circuit.
For more information about how to set up event correlation in HPOM, see the HPOM Administrators Guide to Online Information. For information on creating and modifying event correlation policies, see the documentation provided with the ECS Designer product.
Where to Correlate Messages Before you assign and distribute event correlation policies to the management server or to the managed nodes, you need to consider the where the correlation should place. Message correlation can take place on the managed node or on the management server:
For details about platform support for event correlation in HPOM, see the HPOM Installation Guide for the Management Server.
The HPOM event interceptor is the principal link between NNM and HPOM. The HPOM event interceptor taps both the correlated and uncorrelated stream of SNMP events produced by the NNM postmaster daemon (pmd). Where appropriate, the event interceptor generates HPOM messages. The resulting messages may then be passed through the correlation policy of the HP Operations agent, along with messages generated by other HPOM sources, such as log files. Correlating Events in NNM Before They Reach HPOM You can greatly reduce the number of events intercepted by HPOM by using the correlation circuits of NNM to correlate the events before they reach HPOM. This strategy helps to reduce the overall load on the HP Operations agent. As a result, correlation is easier for HPOM to perform.
The event correlation processes of NNM and HPOM are synchronized, so events that are discarded by NNM are also suppressed by HPOM. Likewise, events that are acknowledged or deleted by the NNM circuits are also acknowledged by HPOM automatically. In addition, automatic annotations are added to each message that is associated with correlated (and therefore suppressed) events. This functionality is included in the conditions of the SNMP trap policy SNMP ECS Traps. Inspecting Correlated Events in the NNM Event Database HPOM provides applications in the NNM Tools application group that enable you to inspect correlated events from the NNM event database. However, the applications Corr Events (act) and Corr Events (hist) are configured to run on the HP Operations management server only. If you want to run these applications on the NNM collection stations, you must first customize them.
Using the HP Operations agent to correlate events on managed nodes significantly reduces network traffic between agent and server. This reduction in network traffic takes place on all managed nodes on which the event correlation agent is running. As a result, the CPU load on the management server is greatly reduced. And the management server is able to attend to other problems more efficiently. Figure 4-24 on page 418 shows how messages are generated on the managed node, how the message are processed, and how you can control the flow of messages to the event correlation agent, opceca, by enabling and disabling message output to the agent MSI.
Correlating messages on the HP Operations management server enables you to reduce the number of identical or similar messages (coming from different nodes) about a single problem. These messages display in the Java GUI Message Browser. Reducing redundant messages is particularly useful in an environment with distributed client-server applications. For example, if a database server is momentarily unavailable, you can reduce the similar messages arriving from managed nodes, which have lost contact with the database server, to a more manageable number. Figure 4-25 shows the message flow on the HP Operations management server, and how you can control the flow of messages to the correlation manager, opcecm, by enabling and disabling message output to the server MSI.
In larger corporate environments that make use of the flexible management configuration features of HPOM, message correlation can be seen in a much broader context, taking into account the relationships between the different levels in the management hierarchy. The relationship between managed nodes and the management server in the HPOM environment can be extended to the relationship between the management servers in the management hierarchy. Management servers can then correlate the messages they receive from the managed nodes, and send a newly correlated stream to the management servers to which they report. Or the management servers can send an uncorrelated stream of messages to be correlated on arrival at the next management server up the chain.
To enable this kind of message correlation in a flexible management hierarchy, you would assign and distribute management server correlation policies to HP Operations management servers on the various levels in the same way you usually assign and distribute policies to any HP Operations management server
This section provides examples of HPOM correlation scenarios. These scenarios help you understand how correlation benefits HPOM administrators and operators by reducing the number of redundant messages arriving in the Java GUI Message Browser. Clearly, the lower the number of duplicated messages, the greater the time the operators need to investigate and solve real problems. Table 4-2 lists a number of correlation policy examples. All of the example policies are visible in the output of the opcpolicy -list_pools command. If you have installed the ECS Designer GUI for NNM and HPOM, download a policy by using the opcpolicy -download command and edit it by using ECS Designer GUI.
Figure 4-26 shows the Transient Node Down policy in the ECS Designer for NNM. This correlation policy enables you to discard in the correlation process all message relating to nodes that are, for any reason, temporarily unreachable. You can discard the messages only if the node becomes reachable within a defined period of time. If the node becomes reachable within the defined period of time, the only message to display is a message indicating that the given node is once again reachable. This message is automatically acknowledged and sent to the Java GUI History Message Browser.
Figure 4-27 shows the Transient Interface Down policy in the ECS Designer for NNM. This correlation policy enables you to discard in the correlation process all message relating to an interface that is, for any reason, temporarily unreachable. You can discard messages only if the same interface comes up again within a specified period of time. In the same interface comes up again within the specified period of time, the only message to display is a message indicating that the given interface is once again reachable. This message is automatically acknowledged and sent to the Java GUI History Message Browser.
Figure 4-28 shows the Switch User policy in the ECS Designer for NNM. This correlation policy enables you to discard in the correlation process all message relating to failed attempts by users to switch to a different user. You can discard messages only if the same user subsequently manages to switch user successfully within a defined period of time. In this case, the only message to display in the Java GUI Message Browser window is a message indicating that a successful attempt to switch user has been completed.
Service hours are defined and agreed on time slots in which a service provider works on problems that are reported by HPOM and that are related to a given service. Each service may have its own period of service hours.
Complex event correlation rules requires special event correlation rules editor ( ECS designer). See Chapter 4, p 358 of Concept Guide for Linux for HPUX 9.01.
The HP HPOM Event Correlation Services (ECS) is an advanced event correlation technology, providing one of the most intelligent correlation engines to date. ECS is fully integrated with Network Node Manager (NNM) to correlate network related events and HP HPOM to correlate events coming from the different layers of environments: the network, systems, applications, databases, and the internet.
With its layered approach to event correlation, ECS distributes the ability to suppress event storms to lower layers of network equipment, while enabling the upper layers to focus on sophisticated event management functions. Using ECS, management solutions are better distributed, resulting in reduced network bandwidth usage and cost savings.
The Event Correlation Services are comprised of the following set of customizable processing components, called correlation nodes:
Each node performs a specific correlation function. These nodes can be easily combined to build simple to very complex correlation circuits, through which events flow.
ECS Designer is a value added product for creation of correlation logic rules.
HPOM 9 offers event correlation on the management server and on supported managed nodes, uniquely allowing event correlation to be distributed among systems, networks, applications, and database events.
Typical usage involves suppressing event storms on lower level HPOM servers while enabling the upper level HPOM server(s) to focus on more sophisticated event analysis.
The Event Correlation Services include three components (correlation nodes):
Each node performs a specific correlation function. These nodes can be easily combined to build simple to very complex correlation circuits, through which events flow. Click here for more information on each of these nodes.
HPOM comes integrated with the ECS Engine and required Protocol Modules. ECS Designer is a value added product for creation of correlation logic rules. Most customers will not require the ECS Designer product functionality. NNM now comes bundled with a new easier to use event correlation utility known as the Correlation Composer. Future releases of Operations will also include this new correlation functionality.
To re-organize messages into other message groups, you can establish regroup conditions. If HPOM Event Correlation Services (ECS) is installed, you can also consolidate similar messages into fewer and more meaningful messages by configuring event correlation policies.
Jul 23, 2008 | IT Resource Center forums
NNM 7.51 on Solaris 10. Not a big deal...apparently I don't know as much about correlation as I thought. We are getting piles of identical messages from several servers running NET-SNMP. I want to correlate them so as to not fill up the message browser. I've tried several different combinations and nothing seems to make any difference. The EID is 126.96.36.199.188.8.131.52.0.4
The servers are generating traps every 60 to 120 seconds. I've tried wildcarding as much as possible to try to catch these guys but so far no luck. Can anyone give me a step by step to supress/correlate these? The messages are important so I don't want to do a "log only" on them
Not a step by step by have you looked at ecsmgr -info and ecsmgr -stats to see if your correlation is active at all?
ALso $OV_CONTRIB/ecs also has some helpful files especially TroubleshootingEventCorrelation.txt
Aug 9, 2007 | IT Resource Center forums
Within our filesystem alarms, we are using three condition (Normal, Warning, Critical). The "Normal" condition is generated upon the filesystem falling below both the Warning & Critical thresholds. I am using Message Keys to acknowledge the events.
My Message Keys are as follows.
My Message Key Relations are as follows.
My problem is that I am seeing the following message in the /var/opt/OV/log/mgmt_sv/opcerror log.
[08/08/07 23:27:36 WARNING opcmsgm (Message Manager)(25341) [patmakey.y:1297]: Syntax error in pattern definition "^dskmon:blv-ecollab-05.ca.boeing.com:<fs>". (OpC20-235)]
I am wondering if it's because of the angle brackets in the Message Key Relations. Those are variables and the <fs> is the variable created from the CONDITION Message Text Pattern Match.
[Filesystem <*.fs> has fallen below threshold violation.]
I had tested this functionality, when I first built these a few years ago now and they worked fine. The message correlation still works but for some reason I get this error. Just wondering why and how I can fix whatever is incorrect.
Hp Software Universe 2010
HP Operations Manager i topology-based event correlation: concepts and operation - Presentation Transcript
- HP Operations Manager i Topology Based Event Correlation Concepts and Operation Dave Trout Hewlett-Packard Software and Solutions 1 ©2010 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice
- Agenda TBEC in action (What does it do?) Basic concepts of TBEC Using the Correlation Manager Automatic cross-domain correlation New TBEC features in OMi 9.0 Summary TBEC = Topology Based Event Correlation 2
- TBEC in Action (video) 3
- Subtitle goes here TBEC Basic Concepts 4
- BSM Service Health Hierarchy KPIs Health Indicators OMi Events with Event Type Indicators OMi Events BPM 3rd Party OM SiS NNM RUM Mgrs 5
- ETI Event Type Indicator ETI is an attribute of an event CI Type Example ETIs Database OracleReadWriteError:Occurred Indicates concise status of ArchiveMode:Enabled managed infrastructure element MemorySortRate:Normal OracleSessionCount:High Set based on a hint* in the event ReplicationStatus:Broken SQLQueryPerformance:Normal or via server based mapping Node UnexpectedReboot:Occurred filters BackupJob:Failed PingAvailability:Unavailable Are defined per CI Type LogicalDiskFreeSpace:NearCapacity MemoryUsageLevel:High Only pre-defined ETIs are Router LinkStatus:Up evaluated when events arrive NodeState:Down Valid for all derived CI Types * Custom Attribute "EventTypeIndicator" = "<ETI name>:<ETI value>" 6
- Correlation Requires ETIs Event Type Indicators are used to define correlation rules KPIs Only Events with Event Type Indicators can be Health Indicators correlated OMi Events with Event Type Indicators OMi Events BPM 3rd Party OM SiS NNM RUM Mgrs 7
- Cause and symptom events Something goes wrong in your environment Monitoring reports multiple problems via events Usually just one of the events describes the cause of the problem Others are just symptoms Fix the cause and also the symptoms go away In a nutshell, TBEC identifies CAUSE and SYMPTOM events 8
- Topology: the "T" in TBEC The other part is the CI type topology Events are correlated if the topology and the Event Type Indicators are matching Cause and symptoms are one part of a rule 9
- Correlation requires relationship Symptom Event3 Ping:Unavailable Event1 Cause Event2 Ping:Unavailable LinkStatus:Down Two events, cause and symptom not within the same topology => no correlation Cause and symptom set by event AND cause and symptom within 10 the same topology => events are correlated
- Time Window for Correlation Even if cause and symptom and the connecting topology match, events might not be correlated Events have to arrive within a certain time window A time window starts when the first cause or symptom event arrives that cannot be correlated with any other event Default time window is 16 minutes Each correlation rule can have its own time window which overrides the global setting Correlation Window Time Event Event No correlation 11
- A Simple Correlation Rule What the rule defines: IF the system receives an event that sets LinkStatus = Down AND IF the system receives an event that sets Ping Availability = Unavailable AND IF the Router and Computer are somehow connected (topology) AND IF that happens at roughly the same time THEN the system will mark the LinkStatus Down event as CAUSE and the Ping Availability Unavailable event as SYMPTOM 12
- TBEC Correlation Rules Semantics A correlation rule shows possible cause-symptom relationships: If the two events happen within a defined window of time, then correlate. Otherwise do nothing. A correlation rule does NOT say If I have that cause, then I will see that symptom (impact) If I see that symptom, then I must have this cause for it One cause can have multiple symptoms (and not all have to appear at the same time) 13
- TBEC Cause/Symptom Usage when defining rules A correlation rule must include at least one CAUSE and one or more SYMPTOMs Multiple CAUSE specifications are allowed if they reference the exact same CI Type A SYMPTOM in one rule can be configured as a CAUSE in another rule (and vice versa) 14
- TBEC Cause/Symptom Correlation Engine behavior A correlation rule triggers when a CAUSE event and any combination of specified SYMPTOM events occur within the correlation time window CAUSE and SYMPTOM events can occur in any sequence within the time window A rule which would otherwise mark an event as a SYMPTOM will be ignored for the event if it is already marked as a SYMPTOM to a different CAUSE event A duplicate CAUSE event which arrives during a correlation window is correlated and handled like a SYMPTOM event 15
- TBEC Cause/Symptom Browser-related behavior If the lifecycle state of CAUSE event is changed: CAUSE and related SYMPTOM events are marked with the new state (e.g. "Work On") CAUSE and related SYMPTOM events are assigned to the user If the CAUSE event is closed: All SYMPTOM events are also closed Additional SYMPTOM events which arrive after a CAUSE event is closed will also be closed until the current correlation window expires Can be disabled in Platform settings 16
- Correlation Window Auto Extend Mode Correlation Window Time Symptom Event Cause Event Auto Extend Mode = False Correlation Extended Correlation Windows Window Time Symptom Event Symptom Event Auto Extend Mode = True (default) Cause Event 17
- TBEC Settings Setting Default Auto-Extend Time Window Mode true Correlate Closed Cause Events true Correlation Time Window (seconds) 960 Max Waiting Queue Size (events) 5000 Admin ΰ Platform ΰ Infrastructure settings ΰ Applications ΰ Operations Management: 18
- OMi event pipeline Admin View, create Content Indicator Correlation Manager Manager and modify Manager correlation rules Events ETI OMi Browser Value Event Event Event Event Event CI CI Event Event to CI Event to ETI Event Mapping Mapping Correlation KPIs HI CI Value HI CI HI Value Value If configured, attach KPI calculation HI-Value to CI BSM Platform 19
- Subtitle goes here Using the Correlation Manager 20
- Correlation Manager Define, deploy, and manage correlation rules Visualize the topology of correlation rules View CAUSE and SYMPTOM events in rules View assigned and available Event Type Indicators and their values Browse the hierarchy of cross-domain correlation rules Access to Correlation Manager is controlled by user role settings 21
- Correlation Manager UI List of rules currently Available ETIs defined of selected CI type CI type topology of selected rule Causes and symptoms of selected rule 22
- Creating TBEC rules What you need to know Working knowledge of CI Types and the BSM type model Working knowledge of UCMDB Views Understanding of Event Type Indicators Detailed knowledge of the events which you want to correlate event domain (networking, database, storage, etc.) ETIs specified in the events event relationships (Cause, Symptom) 23
- Creating TBEC rules Basic workflow sequence 1. Create new rule using the * button 2. Define rule properties (name, description, time window, etc.) 3. Select a topology (UCMDB) view which includes the CI Types and relationships you want to use in the rule 4. Define CAUSE event(s): Select a CI Type in the View Select an ETI and ETI value from the list of available ETIs and "Add as a Cause" 5. Define SYMPTOM event(s): Select a CI Type in the View Select an ETI and ETI value from the list of available ETIs and "Add as a Symptom" 6. Correlation Manager highlights the shortest relationship path If a different path is desired, select the appropriate relationship connectors 24
- Completing rule definition Rule is After saving, valid visualized rule topology is simplified Save when finished Relations between cause and symptom CI type are automatically added 25
- Subtitle goes here Automatic Cross-domain Correlation 26
- Chaining of Correlation Rules CI Type ETI:value WebApp TXAvail:Unavailable Database Domain Database Logical Tablespace Instance Volume StorageCapacity:Critical Quota:Exceeded Storage App Server Domain Server Physical Disk Utilization:Full Storage Domain 27
- Relations Between Correlation Rules Triggered rules are connected (chained together) at runtime when they include a Cause or Symptom event that resolves to the exact same CI and has the exact same ETI and ETI value Chaining is automatic; no configuration is required Rules can trigger in any sequence 28
- Subtitle goes here New in OMi 9.0! 29
- New Features in OMi 9.0 Manually relate selected events in browser CAUSE event is marked from a group of selected events Browser shows "Cause" and "Symptom" icons on the events does not create a future relationship, i.e. no correlation rule is created event lifecycle state changes and user assignment on CAUSE event are also marked on SYMPTOM events Create new correlation rule directly from selected events (Correlation Generator) Enhance existing correlation rule directly from selected events (Correlation Generator) 30
- Subtitle goes here Manually relating events (Video) 31
- Creating A Rule From Events Using the Correlation Generator If two events often occur at the same time, and if one is always the cause... Then a new correlation rule can be created by selecting the two events and selecting Create Correlation Rule from the context menu 32
- Correlation Generator Wizard User selects CAUSE event and SYMPTOM event(s) Generator retrieves relationships between cause CI and symptom CIs from model automatically shortest route automatically selected Note: No UCMDB view required! Cause and symptom ETIs from selected events automatically added Generates a valid correlation rule 33
- Correlation Rules in OMi OMi delivers artifacts like correlation rules, ETIs, HIs, KPIs, tool definitions, etc. using Content Packs Content Packs are included with OMi license OMi 9.0 Content Packs: Infrastructure (includes system, cluster and virtualization artifacts) Oracle MS SQL Server J2EE App Server (WebLogic, WebSphere) Exchange Active Directory 140+ correlation rules are provided 34
- TBEC Delivers Operational Efficiency Operators can quickly identify cause events in the browser Operators work on cause events instead of wasting time on multiple symptom events Fewer invalid escalations to cross-domain tier 2/3 specialists Escalations which DO occur are sent to the right specialist Correlation rules continue to work as the infrastructure changes since they are based on discovered topology Rules can be created directly from events in the browser Automatic "chaining" of correlation rules to cover cross-domain scenarios Lower cost of event/fault management 35
- Thank you for Attending! 36
- Q&A 37
- To learn more on this topic, and to connect with your peers after the conference, visit the HP Software Solutions Community: www.hp.com/go/swcommunity 38 ©2010 Hewlett-Packard Development Company, L.P.
- Backup Slides 40
- BSM Service Health artifacts Acronym Full Name Definition ETI Event Type indicates concise status of infrastructure Indicator element event Custom Attribute with the name "EventTypeIndicator" Value of CA = <ETIName>:<ETIValue> can instantiate HI of the same name HI Health Indicator unique object in BSM (not an event attribute) represents indicated health of a specific CI can be set via an ETI from an event or via metrics from BSM data collectors KPI Key Performance represents calculated health of a Indicator specific CI aggregate health is calculated based on assigned HIs and business rules 41
Jun 22, 2006 | IT Resource Center forums
In that case,
In the template/policy condition for the active message, in the 'message key', enter a key e.g. <node>:<app>:<object>:down.
This if for event that specs something is down.
Then for your next message, the UP, mention in the condition to acknowledge active messages with the above key.
Make sure every key is tuned, to avoid that other messages are ack'd as well.
All variables you can use are in the help pages as well.
BTW : you posted this in NNM thread, better place it in Operations
hp HPOM event correlation services designer (outdated; February 2003)
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
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 quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
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
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 DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting 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
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haters 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|
Last modified: March 12, 2019