HP Operations Manager

Note: HP renamed the product called now HP operations manager way too many times, damaging bland name and hampering its popularity.  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 :-)

This set of pages was created on the base of author's limited experience of porting Tivoli TEC infrastructure to HPOM 9.01.  That's why Tivoli terms are used along and something instead of terms used in HPOM community.  See  Tivoli Alternatives and  Migration from Tivoli TEC  for more information about migration.

HP Operations Manager  (HPOM, aka HPOM, aka OVO) is  the central component of the HP monitoring suit.  Like Tivoli it is client-server solution with agents required on each node. Like Tivoli Monitoring it provides simple Java-based event console and dashboard.  Along with "classic" Tivoli (which will be discontinued in 2012) this is one of the oldest surviving  enterprise system management (ESM) suits. Development  have stalled and nothing useful was done by HP from 2010 to 2013. Operations Agent was upgraded to version 11 but with some "independency" twist that I don't understand. GUI remain basic with no real enhancements since version 9.0.  

In HPOM 9.0 network monitoring was moved into a separate product -- HP NNM. This cuts the cost of the license in case you do not need NNM. It is rather cheap rpoduct in comparison with HPOM.

Historically HPOM was built upon the foundation of DEC Network Node Manager (NNM) product. Older version on NNM was licensed by IBM and distributed under the name IBM Netview (now discontinued). The current name HP Operations Manager  (HPOM) is the third in HP product renaming binge which competes with Sun Microsystems traditions (anybody knows how many names Sun had given to Netscape Enterprise webserver? ;-). Two previous names are:

• HP OpenView Operations (OVO) -- this is the dominant name and it should be used for Google searches.
• HP VantagePoint Operations (VPO)

Gartner (if you are interested in their highly misleading analysis ;-) ranks HPOM 9.0 as No. 1 in Gartner Magic Quadrant for IT Event Correlation and Analysis (Gartner2009).. Unlike original NNM agentless SNMP traps orientation HP Operations Manager (HPOM) is agent based solution and uses Tivoli-style agents installed on each node. According to Gartner  HP Operations Manager has the second largest installed base (behind Microsoft).

One important attraction of HPOM 9 is that it can be used as a target system for migrating from classic Tivoli TFM+TEC+ITM infrastructure as new Tivoli transition involves similar, if not higher transition cost and consists of totally dissimilar (acquired from competitors) products. Also the cost structure of IBM products make them less competitive. For example, in calculating agent cost IBM uses number of cores of the server. That's a cheap trick designed to inflate the licensing costs.

HPOM is a pretty old product first released in 1993. With Tivoli  they defined the enterprise system management (ESM) field.  Only classic Tivoli is older then HPOM (Tivoli was founded in 1989, but released their first product a couple years later; it was bought by IBM in 1996, one year after IPO).  Here is the HPOM Timeline:

HP Operations Manager 9.0  (HPOM), which is the central part of HP ESM offering, looks very similar in functionality to Tivoli framework, Tivoli Monitoring 5.x and TEC in classic Tivoli (TFM+TEC+ITM) combination. Here are some strong points:

• Large part of existing skills on administrator and operator level are reusable. In a way HPOM is more "classic Tivoli" friendly then IBM new Tivoli and migration to it is less costly. It has a very similar, almost identical client-server model. Both functionality and complexity are close to combination of Tivoli framework, Tivoli Monitoring 5.x and TEC in classic Tivoli.  In other words it is powerful and flexible product. Based on my evaluation it looks like considerable part of Tivoli know-how can be almost instantly transferred to HPOM environment. Most concepts and administration procedures of TMF, TEC and ITM looks familiar to seasoned HPOM users and vise versa. Java-based HPOM Event Console is very similar to TEC Enterprise console, so operators need minimal retraining. It looks like TEC operator console should have been: more powerful and more flexible. There is also possibility to create a dashboard directly or using SiteScope.
• Agent is way too complex; the same as in Tivoli set of popular platforms is supported.  Linux is slightly better supported then in Tivoli with separate agents for 32-bit and 64-bit environments. But agent is more complex (half a dozen processes) and more capricious with it prerequisites and installation then Tivoli agent (which is just one process). Agents can be distributed to nodes using SSH or RSH. They also can be installed manually by FTPing relevant files to the nodes.  Version 9.0 comes with agent version 8.60 which refuses to install on a particular older Unix platform and older agent needs to be used (this is the case for AIX 5.2 and older, HP-UX 9.x. etc). Version 9.1 comes with agent version 11, with which situation probably is even worse.
  
  Communication between agents and the mothership is via HTTPS. Certificates necessary for HTTPS communication not always are installed correctly and resolution of such problems at the beginning is challenging. HP support in this area is weak. There is also a capability of agentless monitoring (using telnet of SSH) via a bridge to SiteScope (which is an acquired product which actually should be integrated into HPOM, but it never was. In other words HP is suffering from the same overcomplexity disease as IBM, just to a lesser extent because it implements far better architecture.
  
• Agents are capable to filter messages. Like in classic Tivoli, agent on each node is simultaneously is the repository of probes (called smart plug-ins) that send messages to the "mothership". HPOM policies determine all aspects of converting an event into operator console message provide pretty powerful capability to specify simple event processing (rewording, duplicate suppression, etc) without actual programming. This is a strong point of HPOM -- simple processing is simple, and complex is possible, while in Tivoli everything is complex but possible.  Policies are essentially a set of if-then rules.  Power of policies based filtering in HPOM is substantial and covers all typical areas were TEC was successful and more.  It is really much better deal both from engineering perspective and, especially, from system administrator perspective: regular sysadmins can be quite productive with the tool.  Policies has their warts. For example regular expressions are idiosyncratic and incompatible with Perl regex. In other words they are a joke.

  HPOM agents are complex (multicomponent) and thus extremely unreliable with some components that tend to fail spontaneously. For each 20 servers with HPOM typically there is at least one failure in 24 hours. That means for 200 servers you have around a dozen of such problem in 24 hours (same days more, some days less).  This is a major problem with HPOM. If agent health is monitored, helpdesk tickets about them became major nuisance for system administrators and source of well-deserved hate of HPOM.

  Agents are extremely unreliable with some components that tend to fail spontaneously. For each 20 servers with HPOM typically there is at least one failure in 24 hours. This is a major problem with HPOM. If agent health is monitored, helpdesk tickets about them became major nuisance for system administrators and source of well-deserved hate of HPOM.

• HP did a very good job in fault tolerance area: much better then IBM with "classic" Tivoli. The product can be installed on  two servers which can be used in round-robin fashion: you can switch primary server to the secondary (from the secondary server) for maintenance. Before that you can synchronize the configurations by backuping it and importing on the second server.  There is also support for clusters and such configuration are widely used. All-in-all the ability to use backup manager for maintenance of primary and "follow the time" functionality as well as ability to send different events to different managers are better then in Tivoli.  HPOM also has the concepts of outages and service hours which are not explicitly present in Tivoli (Tivoli implicitly assumes 24x7 environment).  Planned outages of individual servers is an important feature of any datacenter. In Tivoli that can be solved using correlation engine, but HPOM provides an explicit mechanism. 
  
• HPOM is more Unix friendly then Tivoli. First of all it mixes directories for binaries and directories for data files much less then Tivoli. HPOM tries to adhere to classic Unix scheme using /etc/opt/OV tree for configuration files, /opt/OV/opc for binaries and /var/OV/opc for data). But the directory trees are as deep and as obscure as in Tivoli.  Without using Midnight Commander or similar tool they are a mess to work with even with aliases and special variables defined.
  
• Like in Tivoli most operations can be performed from the command line. Commands for most operations that can be performed via GUI are available. That created possibilities of automation for example in installation of agents on the nodes. On a negative side command syntax is, like in Tivoli, a mess with different prefixes and different options style for different commands. Here HPOM matches or even exceeds Tivoli in a very bad sense ;-)
  
• HPOM matches skills of the typical system administrator much better then Tivoli. For example probes (smart plug-ins in HPOM terminology) can be written in shell, Perl or other scripting language. In Tivoli ITM 5.x they are written in JavaScript which is the language few sysadmin know, while correlation engine uses Prolog, a non-procedural the language similar to regular expressions that requires special training to master.  In HPOM any scripting language can be used. Actually, examples supplied with HPOM are written in Born shell (disk_mon.sh, cpu_mon.sh, proc_mon.sh, mailq_l.sh, etc) and Perl (bridge to SiteScope). Sending the alert from the probe involves using the utility opcmsg   (or similar utility opcmon) which in many ways is similar to  wpostemsg in Tivoli. It works only on nodes with the installed agent as communication is via HTTPS.

• Messages can be distributed between multiple "expert centers"; protection from event storms is better as agent can contain correlation engine. There is no gateways but servers are relatively cheap (~$12-18K per server license; the main cost is node licensing, which is around $400-$500 depending on volume) and can be linked hierarchically. There is also a unique capability for "horizontal" message forwarding between two or more managers on the same level of hierarchy. This is called "Message forwarding" and it can be used for implementing "Expert centers" concept, when particular group of messages is forwarded for specific group responsible for resolving it (for example network group, Unix admin group, Windows admin group, etc) from the "total message view" on operator console.  This is a clean and very powerful concept that is very useful in large organizations:  it helps to prevent infighting for  the access to the HPOM server administration capabilities.
  
• Correlation engine is different. Provided by default capabilities include:
  •  deduplication available directly from open message protocol policies only
  • Correlation composer which provides six predefined correlation templates (event suppression, transient states, duplicate events, event timing, event create and annotation). 

  This is much weaker the Prolog capabilities in TEC but for most organizations this is not the problem as they never used advanced capabilities of TEC (few organizations have capable Prolog programmers). 

  For more powerful correlation capabilities you need to buy ECS Designer which permits defining your own correlation templates.  In other words each HPOM installation contains fully fledged correlation engine, capabilities of which are hidden by HP, which supplies ECS Designer as a separate product.   An interesting feature is that correlation engine exists on node level, not on the server level, which improves tremendous scalability (at the risk of hosing the node the agent is running on ;-).   Unlike programming in Prolog-like rules language used in TEC, the correlation engine is of "click and enjoy" type which has major negative aspects as without programmability the system is "half-baked", even if rich  functionality is provided out of the box. IF you looks at discussion at HPOM forums it is clear that people lack a systematic approach of dealing with correlation and are slaves of the provided GUI style "click and enjoy" approach.  But one positive aspect of this approach is that elementary tasks can be performed by people with minimal or no programming skills. Again, the fact that there is no algorithmic language in which to program correlation rules  is a weakness, but truth be told Prolog was mostly ignored in a typical Tivoli deployment. Often no custom rules were used or only a few (often outdated and not well maintained) rules developed by IBM or external Tivoli consultants were used.   As with enough trust pigs can fly you probably can get some API and thus programmability using add-in correlation engine called OMi Topology Based Event Correlation which is installed on a separate box and is a Windows-only product that HP recently acquired.
  

• Documentation is frustrating and minimal; manpages lack examples and often are sketchy. This is huge deficiency but:
  
  • First of all this is so typical for enterprise software products that should not probably even be mentioned as a shortcoming,
  • For those who got used to Tivoli documentation it is OK and conciseness might be seen as an improvement over IBM-style when a 300+ pages document can carry almost no useful information.
  • Taking "Essentials" course provide aspiring HPOM admins with two volumes of relatively well written and really useful documentation (and only idiotic IT managers prevent the staff attending at least Essential course after buying this complex and rather expensive, product). 

  At least documentation does reflect the current version of software. An interesting nuance is that HP provides a separate set of documentation for each platform (Windows, Linux, Solaris and HP-UX on Itanium).  There is just a half-dozen books that you need to read  ( Installation Guide, Concepts Guide, Administrator's Reference,  HTTPS Agent Concepts and Configuration Guide, UI installation and admin guides). For people with the multi-year training in reading obscure IBM documentation, deciphering main ideas, extracting typical operations procedures from HP documentation presents the same challenges as before. It's not an improvement, but they are not much worse either.  As usual you can compensate for the incompleteness of documentation with training.  In essence, all HPOM personnel needs training as many aspects of the system are not covered in documentation and man pages often does not have useful examples or have no examples at all.
  

• Training is better organized, better structured and cheaper then outsourced training that IBM provides, which, based on my experience, is a mixed blessing despite generally good curriculum and manuals.  Two major HPOM admin courses are $7.5K per person (3750*2).  HP virtual rooms software is used, which is adequate for the purposes. Students are supplied with own private network of several virtual linux (including two Linux HPOM servers and a client) and Windows servers. That makes possible to use identical IPs for all students and simplifies instructor life.
  
• License cost consists of the cost of server license (deployment can consist of multiple hierarchically interconnected servers) and the flat cost of agent for each server (the cost of agent does not depend on the number of cores or number of CPUs.  HP is more reasonable then IBM and does not resort to cheap tricks like charging per CPU core ;-).  So both the initial acquisition cost and the annual maintenance cost are lower. Not dramatically (the product is still expensive), but lower.  If intelligent IT staff was outsourced you still can get a prepackaged offering of installation of the server plus 50 nodes from HP Professional services for approx $50K. Otherwise taking two telecourses is enough to get you to the level when you can install the server and configure several agents with some basic probes. Migration from Tivoli TEC is more complex issue and here a good consultant can be tremendous help (but only a good one, which is difficult to find). 
  
• Integration with scheduler is on the same level as in Tivoli and several different schedulers can be integrated. ORSYP, UC4 and probably several other enterprise scheduler vendors have (outdated, if we judge from versions on HP site) Smart Plug-Ins for HP Operations Manager. For example ORSYP has a smart plug-in for HPOM 8.x, but hopefully a new version exists or is at work that works with 9.x. It also lists plug-in on its site (Enterprise Scheduler for HP Operations Manager)

  Dollar Universe Manager for HP Operations Manager is a fully integrated, out-of-the-box solution for HP OM systems. The tight integration makes Dollar Universe the natural choice for HP, integrating and scheduling all IT & business processes and further augmenting the value of the HP suite for customers. Dollar Universe is a certified HP OM Smart Plug-In.

  There some positive stories about successful integration of UC4 with HPOM by large organizations on HP website.

  In most cases you can use SNMP for basic integration even if no smart plug-in exists or supplied smart plug-in is of low quality.

• During the planning phase, the key issue are event processing and implementation of filesystems monitoring.

Event processing usually does not represent too big a problem as facilities of HPOM are adequate for "imitating" useful part of TEC. Please note that most firms use TEC in extremely primitive way so they can actually benefit form more user friendly event processing and correlation infrastructure that HPOM provides. The product does have some shortcomings:

• HP does not provide any useful monitoring scripts with HPOM: the sample script that comes as an example of monitoring free space on root filesystem is a joke. So here you need to write some custom scripts, which in my view is a good thing.  In a way, while HPOM does not requires from sysadmin knowledge of JavaScript and Prolog like Tivoli, it does require a very good knowledge of shell and Perl.  Quality of probes determines the quality of monitoring and if your sysadmin is of garden know-nothing variety regarding scripting, the results can be very disappointing.

• There should be more emphasize on scripting in the product and built-in interrupter is a must. Existing scripting capabilities in policies are really backward.
• Supplied with the product plug-ins leave much to be desired. May be two levels of complexity should be provided. On the second level Perl probably should be more widely used instead of shell.
• Ability to check the amount of free space on mounted filesystems should be built-in and should not require any additional plug-ins. The same should be true for any parameters present in Linux /proc pseudo filesystem.  It is strange that you need your own plug-in for such a basic for any monitoring software function as checking the amount of free space on a filesystem. 
• Perl integration is absent on the level of policies. Regular expressions used should be Perl compatible.  Lua might be used instead of Perl, but some scripting engine should be integrated with HPOM.  This is not a shareware, after all...
• And again, major parameters from /proc should be transparently available for viewing and operating in policies without additional plug-ins. This should be a function of standard agent. 
• Correlation should be made simpler and available without additional licensing. This is one area were the product is inferior to Tivoli (in most other aspects it is superior). I think for competitive reasons HP need to walk an extra mile in this area. 
• Administration GUI is bolted-on product and it shows. More effort needs to be put into making interface more standard (Microsoft products interface looks like unachievable perfection in comparison)

Situation with filesystem monitoring is more complex. As a minimum you need to create infrastructure for regular filesystems monitoring and Oracle archive filesystem monitoring. While primitive, Tivoli Monitoring 5.x  does provide ability to create hierarchical set of filesystem monitoring profiles. Say one "universal" profile is used for monitoring standard Unix filesystems such as /usr/, tmp. /var and then individual profiles are used to monitoring filesystems that are critical for the particular box or particular set of boxes (for example, Oracle servers).

Previous version of the product was known under the more common name OpenView Operations (OVO) and this name is still used in the agent documentation.  There is a certain confusion and interchangeability in usage of the term of Operations Manager and Operations Center, although recently the term Operations Center is used an umbrella term that also includes SiteScope. For example prefix opc is used for many commands as well as user names which adds to the confusion.   Like any large corporation HP development has its problems, but still the product looks better engineered than classic Tivoli.

With HPOM version 9 network manager is a separate product and that reduced the cost of the server.  To cut costs for networking part you can use Nagios, or other open source product. 

Additional components include:

• HP Performance Manager software for examinations of resource utilization and performance trends of monitored objects. This is a Unix application that can be installed on the same server.  HP usually tries to sell it with HPOM but if you do not need it avoiding it can help save the money (you can always buy it later, and probably it will be cheaper, if only because you'll have better understanding of HP and its products).  
• HP Reporter is a Windows-only component from Opsware acquisition.
• HP Operations Manager i  software HP Operations Manager i 8.0 (OMi) is a Windows-based add-on product licensed separately (joy of dealing with IBM HP and like ;-). Important modules are:
  • OMi Event Management Foundation is the base product and is a requirement before either of the other two products can be installed.
  • OMi Topology Based Event Correlation  analog of Tivoli TEC.
  • OMi Health Perspective Views
• HP Operations Smart Plug-ins are scripts that are already integrated into OM framework and provide useful alerts about some part of Unix system or particular application.  There is nothing particular smart about them ;-). Several simple plug-ins written in shell and policies for their use are free with the HP OM license (Webserver monitoring is one example). See  HP Operations Smart Plug-ins for Windows, UNIX, and web servers. Those need to be downloaded and installed separately.

The general structure of HPOM

Here is raw structure of costs taken from Groundwork Monitor vs. HP Operations Manager GroundWork Open Source (GWOS) (please note that comparison is biased toward GroundWork offering; also in HPOM 9 network manager was split and sold as separate product so for those who do not need it cost is dramatically reduced).

HP Operations Manager i (OMi) software is an acquired by HP event correlation engine that runs on Windows. They duplicate event management that exist in HPOM and supposedly provide enhanced correlation capabilities.  If you are moving from TEC and need advanced correlation engine in addition to basic correlation functionality present in Operations Manager by default, you might need to license three separate OMi modules.

• OMi Event Management Foundation is the base product and is a requirement before either of the other two products can be installed.
• OMi Health Perspective Views
• OMi Topology Based Event Correlation

Each module is priced / licensed separately and the pricing model is 'flat'  (no CPU or tier or connection based pricing).

Please note that default installation of HPOM does not include HP Operations Smart Plug-ins for Windows, UNIX, and web servers. Those need to be downloaded and installed separately.

Pre-defined management policies for Windows, UNIX, and Web Servers, complimentary with HP Operations:

• Windows NT, XP, 2000, 2003
• HP-UX, Tru64, Linux, Solaris, AIX • MS IIS, Apache, Stronghold, Netscape/iPlanet/SunONE
• Work standalone or in combination with HP Performance Agent

HP Smart Plug-ins (SPIs) are fully integrated, out-of-the-box solutions for managing specific IT elements, mostly applications. They work seamlessly with HP Software products.

HP Operations provides complimentary Smart Plug-Ins for Windows, UNIX and Web Servers. Pre-defined management policies for the OS and web server layer enable you to quickly gain control of the essential elements of your IT infrastructure.

Smart Plug-ins for Windows and UNIX re-use operating system data collected by HP Performance Agent, if deployed, and allow for central configuration of alarm setting in a large-scale IT environment. But they also work standalone.

Features

• Pre-defined management policies, representing best practices for OS and web server monitoring
• Service discovery and service model creation for key OS elements
• Performance data logging and visualization
• Support local and global configuration settings, for example in process or file system monitoring
• Smart Plug-in for Windows OS only: light-weight management policies for key Windows applications and tools

HP Operations Manager can aggregate management information from HP SiteScope. The bridge is included with the product and is free.  But the quality of it is so low that it is a mixed blessing.

HP SiteScope is completely different/independent monitoring product which provides much simpler then HPOM simple agentless (via telnet of SSH) monitoring. It has independent and very good simple web dashboard. Initially it was called Freshwater which was acquired by Mercury Interactive, which in turn was acquired by HP.

Banal Corporate Idiotism of HPOM developers

 Madness constitutes a right, as it were, to treat people as vermin.

—LORD SHAFTESBURY,
Diaries, 5 September 1851

Design, architectural choices for large monitoring systems are not made in a vacuum. In substantial measure they are dictated by a complex interaction between previous versions constrains (legacy constrains) and intellectual limitations of the current product management team of which we are seldom fully aware. In largely unintended ways, such systems are never allowed to break with their past. This is a vital principle of a strange asylum for mentally disturbed patients which large corporate software development organizations often represent ;-) 

While large monitoring product developers such as Tivoli, Open View and CA Unicenter periodically invade each other's ecological niche they never really threaten to occupy it and displace the other player. Competition is reduced through a corporate dysfunction which I will call "banal corporate idiotism". In a fairy tale propagated by mainstream press developers are portrayed as hard laborers, engaged in the relentless pursuit of the particular "high" goal. In reality they are prisoners of previous generations of products and talantless, technically weak  management. As a result they often are unable to correct even most blatant and obvious mistakes made by previous generation of developers. Compatibility is the God which requires human sacrifices :-). 

In HPOM the following legacy features are the most annoying:

1. As /proc filesystem is available on most Unixes absence of clear, well-documented  interface between coda and /proc filesystem is worse then a crime it is a blunder ;-).

2. Rudimentary, inconsistent and idiosyncratic implementation of regular expressions. See Patterns in HP HPOM. Even a user like me it is clear that style of regular expressions can be specified "per policy" as policy parameter, but unfortunately nobody high enough in HP HPOM development brass hierarchy could come with a similar idea...
3. Extremely primitive abstraction of monitoring with a threshold situation. Capabilities of Measurement Threshold Policies are significantly more primitive that capabilities of Open Message Interface Policies. And I wonder why. Just two examples:
   • No ability to invoke the "threshold processing" script (which can be written in Perl) on a node different then the node on which monitoring script is deployed.
   • No built-in "canary in the mine" type of monitoring where the fact that messages seized to come for some predefined interval serves as a sign of an important situation to develop.  This is a simple extension of existing functionality for suppression of events, that is already present in HPOM. You can probably hack something using a set of policies and/or correlation capabilities provided by ECS Designer which permits defining your own correlation templates. By this is a basic monitoring functionally: when particular type of messages stop arriving rise alert.
4. Overcomplexity and "grandiosity" of the agent. The absence of concern about the constraints that sysadmin experience by trying to maintain this infrastructure. For example how many sysadmins or persons who are responsible for HPOM (which is less good situation as HPOM is a sysadmin tool, first and foremost) know about that fact that built in performance agent (coda) provides basic filesystem and CPU metrics and continue massage output of uptime and df -k to get those metrics :-).
5. Bad general architecture and unnecessary proliferation of command line utilities. The latter are badly integrated with each other and sometimes just belong to different generation of the system. Command line interface is too important to deal with it by just adding new commands without deep analysis of what is already available and what was made redundant by current development...
6. Lack of programmability on the server/admin GUI side of HPOM. There are some modest attempts to integrate Perl but they are really modest and really insufficient. Such a complex product as HPOM should have built-in scripting language interpreter. That's comes with territory.
7. Quality of documentation.  As typical for corporate products with multi-year history, documentation is badly written, heavily influenced by previous generations of products, is fragmentary and incomplete. Still in some respects is marginally better then in Tivoli. May it is as bad, but it least it is much shorter :-). You need to rely on Operations Manager forum for most questions.  See HPOM Documentation

NEWS CONTENTS

• 20171104 : Time to move away from HPE Software by Lindsay Hill ( Nov 04, 2017 , lkhill.com )
• 20171104 : Has HP Abandoned Operations Manager Lindsay Hill ( Nov 04, 2017 , lkhill.com )
• 20131021 : Has HP Abandoned Operations Manager by LINDSAY HILL ( Jul 9, 2013 )
• 20130219 : Transport of OmU Templates with agent assignment - HP Software Solutions Community online forum ( Transport of OmU Templates with agent assignment - HP Software Solutions Community online forum, Feb 19, 2013 )
• 20130219 : HP Communities - HPOM upload of policies - Enterprise Business Community ( HP Communities - HPOM upload of policies - Enterprise Business Community, Feb 19, 2013 )
• 20110121 : Comparison with other network management systems - OpenNMS The OpenNMS Project ( Comparison with other network management systems - OpenNMS The OpenNMS Project, Jan 21, 2011 )
• 20110121 : Component Mapping ( )
• 20101119 : HP Software Universe 2010 session recordings ( HP Software Universe 2010 session recordings, Nov 19, 2010 )
• 20100907 : HP Operations Smart Plug-ins for Windows, UNIX, and web servers ( HP Operations Smart Plug-ins for Windows, UNIX, and web servers, Sep 07, 2010 )
• 20100903 : IT Resource Center forums - Operations Manager for Linux! ( Oct 15, 2009 )
• 20100728 : OMiDeepDive2009Jul ( OMiDeepDive2009Jul, Jul 28, 2010 )
• 20100728 : GroundWork Monitor vs. HP Operations Manager GroundWork Open Source (GWOS) ( GroundWork Monitor vs. HP Operations Manager GroundWork Open Source (GWOS), )

Old News

[Nov 04, 2017] Time to move away from HPE Software by Lindsay Hill

Nov 04, 2017 | lkhill.com

Time to move away from HPE Software 15 September 2016 · Filed in Opinion

If you are still using HPE Software, you should actively plan to migrate away. The recent divestiture does not look good to me - I think existing customers are going to get soaked. Plan your migration now.

I've said it before, that I retain a soft spot for Hewlett-Packard. They gave me my first professional job out of university. I served my sentence doing HP OpenView consulting, and HP-UX Administration, but still: it got me started. Once you have some professional experience, it's much easier to move to the next role.

It saddens me to watch HP's ongoing struggles. It's sad to watch a big ship get broken up for parts. But things had to change. They need to do something to adapt to the realities of modern IT demands.

There was one line in the recent announcement about divesting HPE's software assets that stood out to me:

Micro Focus expects to improve the margin on HPE's software assets by approximately 20 percentage points by the end of the third full financial year following the closing of the transaction

Press Release

(Emphasis added).

It has been clear for a while that HP Software was no longer a core asset for HPE. It was clear that it was not adapting, and was being starved for investment. Revenues have seen decline. Smart customers have seen this coming, and have been actively migrating away from HPE Software.

But if you're still using it, you should pay attention to that press release. How do you think Micro Focus plans to improve margins by 20 percentage points? That's a lot of margin. You've got three options:

1. Increase sales. Software development has high fixed costs, so margin improves with additional sales.
2. Increase prices, collecting more money from existing customers.
3. Reduce investment, spending less to improve margins, and hope customers don't notice.

This is a mature business. They will have a low percentage of new customers. Most revenue will be coming from existing customers. It is not a growth market. So what's left? Raise prices, and reduce investment.

If you're an existing customer, expect to see more license audits, and higher renewal quotes. Expect to see feature stagnation.

It won't happen straight away, but it will happen. If you're still delaying that migration, time to get a move on.

[Nov 04, 2017] Has HP Abandoned Operations Manager Lindsay Hill

Nov 04, 2017 | lkhill.com

HP OM has not adapted well to modern demands. It does not deal well with VMs being deployed at a high rate. It does not offer service monitoring capabilities. It does not offer any way to connect to cloud provider APIs. The agents have continued to be unstable. The administrative interface for OML/OMU looks like something I wrote over a weekend, based on a dodgy PHP shopping cart. It does not look like a piece of software that costs tens of thousands of dollars. Or actually maybe it does - Enterprise software in general tends to be ugly. HP didn't even develop it themselves - they licensed the admin interface from Blue Elephant Systems . The Java GUI for OML/OMU was a disgrace in 2002 - and it hasn't changed since.

William , April 13, 2016 10:30 AM

Again, at another site where they are attempting to move to OMi ( BSM ) Just a note here. BSM is the top tier interface through which other products flow. A crude anology would be MicroSoft Office is the suite in which many other products like Access, Outlook, One Note...etc...etc are pieces or parts. OMi is a piece of the comprehensive suite of tools offered by HP Software. Just like "OpenView" was the umbrella word used for all HP tools like OM-W, OM-U, NNM, OV...PI, TA, SI, PM and a host of other products. The jury is still out on whether the products are viable as a management suite. One major consideration is ROI. Problems still exist in ALL the tools, SiS does not provide capabilities or granularity agents have. I could write or borrow scripts ( Perl, Shell, VB, Powershell ) to effectivly do everything it does. OMi loses CI's, does not get critical mesaages forwarded, loses communication with the agents it is supposedly managing for starters, NNMi has issues not finding nodes that it should discover when discovery filters are configured. And I could add a dozen other "dirty diapers" in the suite. Yet, one can see where HP is trying to go here. IF a few of those 400 million in development dollars are thrown at the suite it could prove a valuable suite in any IT departments arsenal.

Hank Williams , October 9, 2013 10:08 AM

Theoretically BSM/OMi looks like an HPOM alternative, but looking at the scalability, the TCO, the complexity (and, and, and ...) it isn't. If you are wary about migrating to BSM, be provocative and ask HP for a reference implementation and analyse the length and cost of the implementation.

William Linn Hank Williams , July 28, 2017 3:45 PM

OMi is a little cleaner, on my last customer site it at least functioned in the 10.12 version. HP couldn't sell BSM with all the integrations like they thought. I personally know of several large enterprises that unceremoniously dumped ALL HP products, like Data Protector, HP-UX when the monitoring tool became an albatross around their necks as far as implementation and complexity of BSM/OMi. So, HP has done what HP always does when they have a major malfunction in marketing. They "REBRANDED"!!!! Seems that is what you see in companies that go out of business in one location, then move to a secondary spot OR, better yet they have a huge "going out of business" sale and the products never get lowered in price, they actually mark them up, if they sell great, if not then they close for a couple of weeks and company A opens as company B with all the same inventory at a marked up price. Maybe not really the scenario HP is using, but close. OMi by itself without the uCMDB ( which causes other issues when reconciliation occurs between agent based CI' and CIT and what is found via the scripts uCMDB uses to collect data, mismatches as one sees it differently and then the CI or CIT is removed, IF a critical system...boom...no monitoring as the policies are gone and there is only a reference to the CI in OMi. ) but...as noted, OMi by itself seems stable, though they are not in version 10.61...and by the way...the patch from 10.60 to 61 is flawed. But aside from the complications of TQL's, RTSM, etc...etc...it looks a whole lot more stable.

Lindsay Hill Hank Williams , October 9, 2013 11:57 PM

You're right - I've seen those implementation plans, and it gets very expensive, very quickly. You have to put in a lot of effort just into getting software installed and integrated - none of which is of any direct value to the customer. Maybe justifiable in huge environments, but for the rest of us? Not really.
Customers shouldn't have to pay for fixing broken integrations, they should be able to just start using the software to solve their business problems. We're years away from reaching that point though.

[Oct 21, 2013] Has HP Abandoned Operations Manager by LINDSAY HILL

Sure the OMU development is stalled, but in no way BSM/OMi is an alternative. This is just overcomplexity play.

Jul 9, 2013

So what's the future of OMW/OMU? Let's try reading between the lines – look at the recent announcement by HP about OMi Monitoring Automation. This separates monitoring policies (configuration, thresholds, etc) from implementation (agent-based, agentless). It bypasses the OM server requirement, with agents directly managed by the OMi server. I haven't seen enough of the implementation details yet to confirm that OM has been completely replaced, but it's clear enough to me what the future direction is. Development has continued for Operations Agent, but clearly Operations Manager is surplus to requirements. Well maybe it all makes sense – why the hell did they ever have two separate products, one named "Operations Manager", and another named "Operations Manager i"?

What future for HP OM then? It now only makes sense as a Manager-of-Managers for organisations that are too small to commit to the whole HP BSM suite. Even those organisations need to re-think their use of OM though, as it can't handle a dynamic environment, and stands little chance of being able to integrate proper APM, or cloud service monitoring. There are other products out there that are better suited to modern medium-sized organisations. --[ It would be interesting to know what are they ? NNB]

To the HP people reading this: Obviously you can't publicly confirm any of this. You've promised ongoing support to those still paying their annual support fees. But if I'm wrong, then show me the code. Deliver some updates to the product, and show us that it is being actively developed. Vague promises of continued commitment mean nothing without shipping code. To customers using HP OM: My advice is to start planning your migration away from it, if you haven't already. To customers considering purchasing it: Don't, unless you're buying it as part of an overall BSM/OMi implementation, and the salesfolk have guaranteed you can change your licensing over at no cost in future.

Hank Williams

Theoretically BSM/OMi looks like an HPOM alternative, but looking at the scalability, the TCO, the complexity (and, and, and ...) it isn't. If you are wary about migrating to BSM, be provocative and ask HP for a reference implementation and analyse the length and cost of the implementation.

[Feb 19, 2013] Transport of OmU Templates with agent assignment - HP Software Solutions Community online forum

11-25-2010 06:45 AM

After our template admins again disabled our whole platinum service monitoring by a well placed condition, I finally got fed up on letting them work with our productive management server for Template/Policy changes.

My idea is to allow changes to templates and conditions only on the development system, and then transport those changes to our productive management server for roll-out to our HPOVO agents.

Regarding this, there is a issue with opccfgdwn and opccfgupld:

When I download templates, and upload them with opccfgupld -subentity -replace, all changed policies get updated and new policies get inserted. BUT when I delete old policies, those deleted policies are not removed on the target server where I upload the data.

When I use -deloldtempls, I can circumvent this issue, and the uploaded templates look perfectly the same like in my dev system. But then all ovo agent assignments are lost.

Again, I can circumvent this by exporting the node bank, too, as the assignment information is stored there, but this does NOT work if the new management server already has the node, as the information update then is skipped and no template assignment is made.

As we assign many templates to many agents, I cannot assign the templates manually after each transport. Does anybody know a way to transport Templates from Management Server A to Management Server B including deleted Policy deletion AND agent assignment conistency? Any suggestions are highly appreciated as I am running out of ideas in this subject. The main issue is: Transport of whole templates with regard to all added/changed/removed policies.

brian_bes

Hi,

we, blue elephant systems, have developed various products to help resolve this issue and, luckily for us, you are not the only one who has run into this problem :smileywink:

The MIDAS product is the basis for the HP HPOM 9 Admin UI and also supports HPOM 8. With MIDAS you can access multiple HPOM servers from a single console, with extended user rights so that you can give developers write access to the development server, and read access to the product server(s).

Also there is a packaging concept, that allows you to easily move the monitoring configuration between servers. For this we had to implement an "intelligent" package upload, so that you can get all the policy(group) - node(group) assignments, and still have the correct policies (it also supports the removal of old policies). The basic concept that we use is that the upload must be done in multiple steps, with different sub-entity options - opccfgupld just does not have the correct options to do this in one step!

If you want further information please have a look on our website (http://www.blue-elephant-systems.com/midas4/admini​strator) or contact me directly and I can organize a demo for you. You can download a short white paper that I did a while ago on "Release Management for HPOM Monitoring" which discusses some of the issues that you are experiencing, with solutions, at link to: Release Management for HPOM Monitoring Whitepaper.

Brian Hubbard

Product Manager

blue elephant systems GmbH

[Feb 19, 2013] HP Communities - HPOM upload of policies - Enterprise Business Community

‎08-10-2009 04:15 AM

Hi all,

I have some OMW poicies that i would like to upload to an HPOM server.

I have converted all the OMW policies to get the .data files which I can use with opctempl command to upload onto HPOM.

I would like to be able to specify a template group where these policies get uploaded instead of the Default group.

Is this possible

Sukru ARSLAN_1

No, it is not possible. The template is put in the top level. To do this in the browser, Edit->Copy, go to the desired group and Edit-Paste.

[Jan 21, 2011] Comparison with other network management systems - OpenNMS The OpenNMS Project

The OpenView® framework is one of the oldest surviving network management platforms that is still popular today. Several of the original creators of OpenNMS came from a company that became part of the OpenView business unit, and at least one came from a company that was one of the largest OpenView NNM shops in the world. It's unsurprising, then, that OpenNMS borrows some concepts, goals, and terminology from NNM.

Unlike OpenNMS, the OpenView suite is commercially-licensed proprietary software.

Component Mapping

OpenView Component(s)	OpenNMS Component(s)	Notes
Network Node Manager	Pollerd, Collectd, Trapd	Service monitoring, performance data collection, reception of events as SNMP traps
OpenView Operations	Pollerd, Collectd	OpenNMS supports data collection and trap reception from HP's OVO SNMP agent
OpenView Performance Insight	Collectd, ad-hoc resource graphs, KSC reports, thresholds, Statsd	OVPI was formerly DeskTalk

[Nov 19, 2010] HP Software Universe 2010 session recordings

[Sep 07, 2010] HP Operations Smart Plug-ins for Windows, UNIX, and web servers.

They are complimentary with HP Operations. Still they need to be downloaded and installed separately.

Pre-defined management policies for Windows, UNIX, and Web Servers, complimentary with HP Operations:

• Windows NT, XP, 2000, 2003
• HP-UX, Tru64, Linux, Solaris, AIX • MS IIS, Apache, Stronghold, Netscape/iPlanet/SunONE
• Work standalone or in combination with HP Performance Agent

HP Smart Plug-ins (SPIs) are fully integrated, out-of-the-box solutions for managing specific IT elements, mostly applications. They work seamlessly with HP Software products.

HP Operations provides complimentary Smart Plug-Ins for Windows, UNIX and Web Servers. Pre-defined management policies for the OS and web server layer enable you to quickly gain control of the essential elements of your IT infrastructure.

Smart Plug-ins for Windows and UNIX re-use operating system data collected by HP Performance Agent, if deployed, and allow for central configuration of alarm setting in a large-scale IT environment. But they also work standalone.

Features

• Pre-defined management policies, representing best practices for OS and web server monitoring
• Service discovery and service model creation for key OS elements
• Performance data logging and visualization
• Support local and global configuration settings, for example in process or file system monitoring
• Smart Plug-in for Windows OS only: light-weight management policies for key Windows applications and tools

[Sep 03, 2010] IT Resource Center forums - Operations Manager for Linux!

Oct 15, 2009

sean

HP seem to have quietly release something ive been hoping for for years - OM for Linux! There is an OM(L) eval .iso for download on the BTO software site. I'm surprised there is no chatter in here about it. I'll be trying it out myself later today i hope.

I would imagine Centos will work OK for testing. It allows me to install NNMi

Martin Pronk

Oh, please note that OML 9 doesn't allow NNM and OML run on the same server.

See attached release notes

Peter Marko

Hi guys,
here are the other docs ...

OML9.01_Linux_Concepts.pdf - KM772790
http://support.openview.hp.com/selfsolve/document/KM772790/binary/OML9.01_Linux_Concepts.pdf
OML9.01_Linux_ReportDB_Schema.pdf - KM772791
http://support.openview.hp.com/selfsolve/document/KM772791/binary/OML9.01_Linux_ReportDB_Schema.pdf
OML9.01_Linux_Installation.pdf - KM772792
http://support.openview.hp.com/selfsolve/document/KM772792/binary/OML9.01_Linux_Installation.pdf
OML9.01_Linux_Java_GUI_Operator.pdf - KM772793
http://support.openview.hp.com/selfsolve/document/KM772793/binary/OML9.01_Linux_Java_GUI_Operator.pdf
OML9.01_Linux_ReleaseNote.pdf - KM772794
http://support.openview.hp.com/selfsolve/document/KM772794/binary/OML9.01_Linux_ReleaseNote.pdf
OML9.01_Linux_ServerConfigVariables.pdf - KM772795
http://support.openview.hp.com/selfsolve/document/KM772795/binary/OML9.01_Linux_ServerConfigVariables.pdf
OML9.01_Linux_DevToolRef.pdf - KM772789
http://support.openview.hp.com/selfsolve/document/KM772789/binary/OML9.01_Linux_DevToolRef.pdf
OML9.01_Linux_FirewallConceptsConfig.pdf - KM772796
http://support.openview.hp.com/selfsolve/document/KM772796/binary/OML9.01_Linux_FirewallConceptsConfig.pdf
OML9.01_Linux_WebServIntegration.pdf - KM772797
http://support.openview.hp.com/selfsolve/document/KM772797/binary/OML9.01_Linux_WebServIntegration.pdf
OML9.01_Linux_HTTPSAgent.pdf - KM772798
http://support.openview.hp.com/selfsolve/document/KM772798/binary/OML9.01_Linux_HTTPSAgent.pdf
OML9.01_Linux_SecurityAdv.pdf - KM772788
http://support.openview.hp.com/selfsolve/document/KM772788/binary/OML9.01_Linux_SecurityAdv.pdf
OML9.01_Linux_AdminRef.pdf - KM772787
http://support.openview.hp.com/selfsolve/document/KM772787/binary/OML9.01_Linux_AdminRef.pdf
OML9.01_Linux_Oracle_RAC_whitepaper.pdf - KM772786
http://support.openview.hp.com/selfsolve/document/KM772786/binary/OML9.01_Linux_Oracle_RAC_whitepaper.pdf
OML9.01_Linux_DevToolkitAppInteg.pdf - KM772785
http://support.openview.hp.com/selfsolve/document/KM772785/binary/OML9.01_Linux_DevToolkitAppInteg.pdf
OML9.01_Linux_ServNav_ConceptConfig.pdf - KM772784
http://support.openview.hp.com/selfsolve/document/KM772784/binary/OML9.01_Linux_ServNav_ConceptConfig.pdf

sean

Well i have it working now after a few days stuffing around (hey, it's HPOM afterall :).

Server:
VMware guest
2GB RAM
40GB disk
CentOS 5.3 (no patches)
Oracle 11.2.0.1 x64(no patches)

Issues:
- had to install about 20 extra RPM packages on top of the default CentOS install to satisfy oracle, including one that wasn't in yum (pdksh).
- had to modify kernel params for both oracle and OML
- oracle 11.2.0.1 x64 doesn't seem to install the legacy 32bit libclntsh.so library by default, which is required by OML. I manually copied this file from the 11.2.0.1 x86 oracle client over to the OML server to allow OML to install. (i installed the x86 oracle client in a different location and manually copied the libclntsh.so file to the location OML wanted it (/opt/oracle/product/11.2.0/lib32/libclntsh.so)

- if /etc/services has an entry for TCP port 1521, regardless of whether that port is ACTUALLY in use by a daemon, OML will refuse to configure the DB listener on that port. Remove the 1521 entry from /etc/services before installing

Goran Koruga

Hello.

Just to clarify:

OML does *not* need 32bit version of libclntsh Oracle library, it needs a 64bit one.

Goran

sean:

the exact error i got was:
Oracle Database not installed correctly. Missing file /opt/oracle/product/11.2.0/lib32/libclntsh.so

So i'm assuming that when it needs a file out of "lib32" it needs be 32bit.

Goran Koruga:

Hi.

Ahh yes, that one - it's a bug in the ovoconfigure script. Easy to fix.

You don't really need it except to get past that stage during the installation. Hopefully this will be fixed soon.

Regards,
Goran

sean

...or as Goran said, it's a bug in the ovoconfigure script. I just had another look and it seems if you edit ovoconfigure and remove or modify the "if" statement starting on line 9945, you can prevent the check for libclntsh in the lib32 path.

try just creating a dummy file in that location
i.e.
touch /opt/oracle/product/11.2.0/lib32/libclntsh.so
(assuming that is the path for your Oracle home).

I think the installer is just looking for the existence of that file and never actually makes use of it.

PSilva

You'll find the libclntsh.so located on the lib folder (instead of lib32), so you can make:

cd $ORACLE_HOME
ln -s lib lib32

[Jul 28, 2010] OMiDeepDive2009Jul

Presentation that provides some information about OMi and event correlation.

GroundWork Monitor vs. HP Operations Manager GroundWork Open Source (GWOS)

In 2007, a whopping $4.3 billion was spent on availability, performance, and network management-33% of the total budget for IT Operations Management. 70% of this was spent on the Big-Four solutions, BMC, CA Unicenter, HP Operations Manager (formerly OpenView), and IBM Tivoli.

Curious about just how much HP monitoring solutions cost, line item by line item?

This twelve-page paper provides a head-to-head cost comparison of GroundWork Monitor, HP Operations Manager, and associated products, finding that GroundWork provides an 82% cost savings over three years.

Recommended Links

Softpanorama Recommended

Top articles

Sites

• Vivit Worldwide - Deep Dive HP Operations Manager i
• HP OMi TBEC concepts and operation HP Enterprise TV Online Videos and Podcasts
• HP Operations Manager i software - HP - BTO Software

Downloads

• Download Center - HP - BTO Software
• OVInternals for OV manager for Windows. Some scripts.

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 quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard 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 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

Classic books:

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 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

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: February 19, 2020