Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Softpanorama Search

Slightly Skeptical View on Tivoli

(Including Integration with Open Source Tools and Scripting Languages)

News Recommended Links Redbooks Support cycle Perl Scripts Security User Groups
TMF TEC ITM6.1 ITM 5.1 TCM TWS Netview
  Tivoli Technical Exchange Webcasts          
Support Field Guides Alternatives Prolog BAROC IBM humor Etc

Tivoli is a powerful and very scalable (up to several thousand nodes) closed source product that is complex to install and expensive to maintain. Historically it is one of first successful product for enterprise system management (ESM) and its systems and event management capabilities in many respects defined the field.  Tivoli documentation is probably the most rich out of any EMS systems: open or closed.

Tivoli is not an original IBM product. IBM bought Tivoli (the product and the company; the latter was located at Austin, Texas) in 1996 and retained the name of the product.  Company for several years functioned an independent subsidiary before it was integrated into the IBM software division.  The original Tivoli team used Solaris as the development platform and up to this date Solaris is preferable platform for "classic" Tivoli components.

After Tivoli acquisition large part of key developers abandoned the ship and formed the company called  IT Masters. They produced a competing product called MasterCell which at peak (2003) has had 80 employees. It was a kind of "better Tivoli then Tivoli" type of product in a sense that they tried to resolve some original architecture flaws.  The company and the product were acquired by BMC Software in March 2003 soon after release of MasterCell 3.0 (since then it was renamed BMC Event Manager).   Before that in late 2002 BMC managed to buy helpdesk company Remedy, which was the top helpdesk application as for integration with Tivoli.  That was a very shrewd move and actually left Tivoli to hang dry without clear cut path for helpdesk integration. So it's not surprising that the product sucks in this dimension. Any ESM tool is not complete unless the helpdesk product is tied in, so that serious problems are recorded as tickets and there is a formal recoded flow of actions when they are managed, diagnosed and prioritized. 

After the initial Tivoli acquisition IBM made a very good effort to market the product and it achieved considerable industry penetration. That somewhat compensate their passivity in technological area as with substantial market presence it is easier to redesign product to meet the new challenges. After all abandonment of product due to inability to market it is the most grave flaw for a commercial software development company.   Still it's sad that a redesign never happened: even today surviving products from the original  Tivoli line products still have look & feel like they came straight from 1996. The communication technology in Tivoli is also old (CORBA).

For cost-conscious enterprises comparison of  BMC Software  offerings might serve as the base of comparison both in price/performance issues as well as in quality of architectural solutions (as an underdog BMC might provide better pricing and as product was based on IT Masters, which was more recent product then Tivoli, it might have slightly better architecture although the developers retained Prolog as the base of correlation engine. Actually Prolog interpreter used in Tivoli in now owned by BMC ;-). 

All-in-all IBM's strategy of development Tivoli is typical for a large corporation and there is not much interesting in it.  For all those 10 years since acquisition they did some useful polish but mainly tried to extend Tivoli line by increasing the number of products branded as Tivoli. Some of those products were developed internally but several were bought to broaden the appeal of the brand (as well as to eliminate competition). IBM actually did very little in the area of updating existing applications and making them more modern and more flexible despite having several products that provide significant synergy with Tivoli and first of all Lotus Notes.

For very large companies Tivoli (in minimal dozes as discussed below) still makes sense first of all because it was tested on huge infrastructures, infrastructures that open source products are never designed to work with.  While from the point of view of technology used  internally (Prolog, CORBA, etc) Tivoli has lost its luster in the enterprise management market due to "age-related hardening of the arteries" (or sclerosis ;-), it still commands a dominating share in ESM market and might improve its position due to recent IBM's acquisitions, which were essentially the acquisitions of major Tivoli competitors.  After IBM bought several of them suddenly the technology with which Tivoli needed to complete can be used internally in the next release of the product. The first sign of this "new wave" was the release of ITM 6.1 in 2006. God knows how it will affect architectural integrity of the product.  Right now ITM 6.1 probably duplicates 80% of capabilities of TFM+TEC+ITM.  And this is not surprising as OMEGAMON was pretty capable competitor of Tivoli in large enterprise space. Subsequent acquisition of Netcool further complicated the picture as Netcool provided supposly (much depends of the quality of prefiltering on the gateway in TEC)  more scalable correlation engine and now IBM needs somehow to choose from three different offerings (or in best IBM-style preserve them as three complimentary options ;-). 

Actually "improvement by transplanting" somebody's else solutions into existing complex system was the typical way IBM addresses Tivoli problems. It  is very challenging way to improve the system without weakening or even completely destroying the conceptual integrity of the product.

History of IBM software development suggests that architects are usually unable to withstand management and marketing pressure. Current Tivoli product stack looks like a Christmas tree with many marginal or overlapping products. It looks like IBM brass has no sense of measure and tried to overextend the brand they created.  Usefulness of Tivoli dramatically drop beyond small set of core products and return on investment suffers if an organization buys too many "second tier" junk.  It makes sense to concentrate of a few key products to cut both the complexity and the price and supplement them whenever possible with scripting-based solutions.

Current Tivoli product stack looks like a Christmas tree with many marginal or overlapping products. It looks like IBM brass has no sense of measure and tried to overextend the brand they created.  Usefulness of Tivoli dramatically drop beyond small set of core products and return on investment suffers if an organization buys too many "second tier" junk. It makes to concentrate on the  minimal set of  key products to cut both the complexity and the price and use scripting to adapt Tivoli to new tasks.  Old Tivoli products have good extensibility and most functionality is available from command line.  New versions of the same products are typically the result of acquisitions, not the internal development, and often suffer from "Microsoft" mentality.

In it current incarnation Tivoli consists of large (over a hundred) set of component with only few deserving mentioning.  

The super-minimal set of products can consist just of ITM 6.1, but in this case you lose programmable correlation engine. The minimal set of products that can be used in more or less   "open source" way  includes TEC and probably consist of just half dozen names. The most important (and often carefully hidden)  fact is that in ESM 20% of the functionality provides 80% of the value. Tivoli most useful functionality is the ability to serve as "meta-integrator" for other ESM products that are often present in large enterprize environment either due of acquisitions or due to level of autonomy of various departments within corporate IT (for example Mercury Sitescope is popular on department level). That permits utilization of high quality TEC correlation engine and logadapters functionality but helps to avoids overpaying for nodes and maintaining legacy Tivoli endpoints on each and every server. 

The most important (and often carefully hidden)  fact is that in ESM 20% of the functionality provides 80% of the value. Tivoli most useful functionality is the ability to serve as "meta-integrator" for other ESM products that are often present in large enterprize environment either due of acquisitions or due to level of autonomy of various departments within corporate IT (for example Mercury Sitescope is popular on department level). That permits utilization of high quality TEC correlation engine and logadapters functionality but helps to avoids overpaying for nodes and maintaining legacy Tivoli endpoints on each and every server.  

The very sad fact about Tivoli, especially modern version of products (actually rebranded product from acquired competitors) is lack of understanding of scripting and compete absence of a conscious effort to integrate scripting into the products (with one minor exception ITM 5.1 which now is replaced with ITM 6.1). IBM brass never got it.  Paradoxically "Old line" of Tivoli products were more scripting friendly. To quote  Talleyrand  "This is worse then a crime this is a blunder."

Due to the level of frustration with lack of integration of scripting into Tivoli line the most advanced part of Tivoli users are open for grabs and this can represent an opening for open source competitors.  Especially on system monitoring side of the house where open source products achieved a certain level of maturity. And contrary to IBM propaganda they can do most of the tasks better and cheaper. What is currently lacking is a programmable correlation engine and GUI capabilities but this can be compensated by using Tivoli only as the alert integrator for open source products. In this case you need only as many licenses as there are satellite open source monitoring products reporting to Tivoli. That can provide for substantial savings.  That means that not outright displacement (bad idea as investments are huge) but creating a satellite line of products that complement Tivoli and can reduce licensing costs.

The major components in Tivoli product line
and minimization of Tivoli deployment

Tivoli adoption is not cheap in any case as it does require a dedicated person in the organization. As the product line was formed as a result of multiple acquisitions, loose integration, multiple agents, different user experience, redundant processes and multiple client agents make Tivoli difficult and expensive to administer. That partially is compensated by excellent IBM support.

As the product line was formed as a result of multiple acquisitions, loose integration, multiple agents, different user experience, redundant processes and multiple client agents make Tivoli difficult and expensive to administer. That partially is compensated by excellent IBM support.

But if you minimize the set of products deployed you can pay a fraction of software costs getting 80% of benefits. Please note that IBM traditionally use three/four letter abbreviations for all products (which is a very good practice that has roots in mainframe world but for some reason it did not spread outside IBM software products universe; it helps to provides meaningful prefixes to error messages and as such is much better then syslog  fixed "subsystem" approach). 

The minimum set of products that make sense in the large enterprize environment includes but is not limited to:

  1. TMF -- Tivoli Management framework. This is the key component of Tivoli. In its simplest form Tivoli Framework consists of central server (TMR) and endpoints (more complex deployments can involve a network of TMRs that can communicate with each other in hierarchical of peer-to-peer fashion).  It also contains a scheduler and the ability to run jobs on endpoints although those days it is superseded by more powerful  (and expensive) TWS (see below). TMF come with prepackaged Perl 4 and bash shell and during installation of endpoints both are installed automatically. Some prepackaged scripts are written in Perl.

    Any server or workstation with endpoint you can rely on the presence of those two pretty powerful scripting components.  Perl is now preinstalled on most flavors of commercial UNIX so the value of this solution for Unix is now close to zero but still there are cases when even in UNIX world that makes a difference.  The beauty of Perl 4 is it is a single executable (like AWK), so you do not depend on libraries, modules and other Perl 5 paraphernalia. Availability of Perl is still a nice feature for Windows to have (unless you have Cygwin or SFU 3.5 installed; you better should ;-). I do not know about handhelds.

    Generally framework with its multitude of "w" commands is like a "Lego" constructor and you have considerable freedom of creating your own applications based on it. IBM provides many prepackaged applications but if you have your own ideas on how a particular component should work you can create your ESM framework using Perl as your glue. Of course, the more complex application you want to build the more glue you need to link those building blocks together. But this way you can create the most flexible and customizable infrastructure (IBM usually does not supply source code with prepackaged components; a lot of them are written in Java and are ugly as hell).

    TMF framework interface is a classic example of an  interface used in products developed around 1996 and now looks more like a historical curiosity that a viable solution. As the initial development of Tivoli was done in mid 90th many architectural decisions which were innovative at the time (my impression is that CORBA was actually pioneered by Tivoli team) now outlived its usefulness.
     

  2. TEC -- Tivoli Enterprise Console: while formally this is an add-on product which provides GUI interface for viewing the events stream (client side of TEC), correlation engine (server side of TEC) and several adapters (including log adapters) it is actually a part of TMF as TMF is pretty much useless without it.  It shows its age and the product definitely can benefit from better event console interface GUI: the current one does not even have an animated icons and other typical for competition interface enhancements; functionality is good, though.

    The most interesting feature of TEC is the fact that it has been build using Prolog engine, so actually this is a programmable in Prolog expert system. "Programmable" for complex products usually means that it is better product then open source but non-programmable ;-).

    Any event can be changed/dropped/correlated in the most complex way imaginable. Capabilities are limited only by your skills in Prolog. For example in case you get events from logadapter you can substitute the host value supplied the system (the host of logadapter) to the host of the actual host were the event occurred.  Still Prolog  is a very unorthodox language and is quite challenging to master. And that means that while capabilities are present, it's not that it is actually used that way (most Tivoli rulebases that I personally have seen are very primitive indeed). But we should agree that for 1996 the Tivoli authors demonstrated pretty impressive level of thinking as the problem of correlation is one of the few that can benefit from recursive parsing with backtracking, the approach that Prolog exemplifies.

    There are rumors that eventually it will be replaced with Micromuse correlation engine  (Micromuse engine is based on SQL so it is easier to program then Prolog but is more closed but it's still too early to tell what IBM will do with the acquisition).  Anyway, it is logical to expect that ITM 6.1 correlation engine and GUI will probably be enhanced to handle both old TEC engine and Micromuse engine.

    Due to Prolog usage there are some problems with scalability, but generally scalability is quote adequate. Only in cases of very primitive TEC set-up (for example no pre-filtering of events on gateways) or huge installations scalability can be a problem. For good scalability architecture of both Tivoli itself and the architecture of the rulebase should be carefully thought out: order of rulesets should be optimized for the frequency of incoming events and gateways pre-filtering of events should be correctly configured. If gateway pre-filtering and rule set optimizations are used intelligently,  scalability can well be better or at least competitive with the Micromuse engine.  It might be that IBM brass bought a lemon  ;-)

    Anyway  IBM now has two products that, at least superficially, do the same thing.  See Paul Campbell assessment Orb Data - Omnibus or TEC What you need to know... for details.  It is interesting to note that Netcool used to has extremely restrictive (draconian) licensing policy. 
     
  3. TCM -- Tivoli Configuration Manager. Another good "old-style" product (no Java).  It has dual personality: inventory management and software delivery/synchronization.  'Dual functionality" -- inventory and delivery/synchronization is questionable.  In view of existence of ssh the value of delivery in the local network is questionable. Still might make sense for WAN. Contains some advanced technology for propagating packages to multiple machines developed in Japan by IBM and NTT (UDP multicasting).  Can be really useful for delivering software in WAN environment. Might also be used for collecting local reports into central location.  Those days many of the tasks that can be performed using TCM can be performed with ssh and scripting, but the product has some WAN edge.  All-in-all this is completely wasted money.
     
  4. ITM -- Tivoli Advanced Monitoring. Exists in two versions 5.1 and 6.1 which are actually two completely different products sharing little but the name:
     
  5. TWS - Tivoli Workload Scheduler. This is a pretty powerful third party (bought by IBM) enterprise scheduler that somewhat reminds me mainframes job schedulers; it is used in many large corporations, although there is nothing in it that you cannot do with simpler tools (like the original TFM scheduler).

    IBM did a very poor job integrating it with Tivoli: it requires separate endpoint agent and has completely different from Tivoli architecture and ideology.

    The idea is to provide the ability to run scripts on any computer that have endpoint installed and control the execution.  Integration with TEC is rather superficial and is based on logadapter.  This is a very expensive product.  A large part of functionality can be duplicated with TFM and TEC.  Still TWS has unmatched scalability.

This minimal set (with or without TWS depending on your needs and budget) is probably enough to provide 80% of functionality and, if necessary, can be gradually extended in house. One extension path is to replace endpoints with open source tools for less critical servers and integrate information from such tools via TEC logadapters or directly. In this case you do not need to buy licenses for all your servers: only critical one that justify additional expense. Less critical (or all) can be served with  open source tools like mon or Nagios and alerts can be converted and correlated in TEC or IBM 6.1.  In this case the value of Tivoli is connected with the value of its powerful correlation engines (either Prolog-based from TEC or Omegamon as there is no open source alternative for this functionality). Also in case of TEC  the set of concepts and documentation has its own value as intellectual property acquisition which can help to prevent you from doing many stupid architectural errors and reinventing the bicycle. 

You can supplement minimal Tivoli deployment with scriptable, programmable open source monitoring products.

There are also several Tivoli components that are problematic and cannot be recommended despite having an appealing domains: 

As many other current products on the market Tivoli definitely is suffering from over-complexity (sometimes this fact is recognized in evaluations but mostly is not. For example of the former  see old NASA  Tivoli Impact Assessment Report [PDF]).  This overcomplexity problem is rampant and while it is typical for IBM products in no way it is limited to one company.  Still IBM is very consistent in over-engineering its products and Webshere can serve as another example of this approach.

I think that while we often cannot fight overcomplexity of the products we can still be at least very selective in what we adopt: the key to success in Tivoli deployments is minimization of components and exclusion of everything besides the key functionality needed.  Also you need to cut through the smoke of marketing hype and see that IBM is facing huge problem in its software development, problems that it tries to hide behind the smoke of three-letter acronyms and buzzwords. This pathological obsession with acronyms makes IBM marketing somewhat detached from reality (which might actually be a good thing; sometimes marketing materials they produce are wonderfully ironic). Among the latest fashionable but pretty meaningless recent acronyms are "IBM IT Service Management" - ITSM and  "Information Technology Infrastructure Library" - ITIL; they are probably on par with "Capability Maturity Model" (CMM)  :-).  

The Scriptability of Tivoli Products

The value of Tivoli like is greatly enhanced by the fact that like any large organization IBM has a lot of very talented people scattered in this huge bureaucratic maze and some of them are producing really interesting and innovative solutions despite their managers and the atmosphere of three or four letters acronyms hype :-). So it is important not to throw out the child with the bath-water and distinguish between good products (and support) from problems related by the existence of huge multilayer corporate bureaucracy and architectural perversions due to badly thought out acquisitions.

One of the strong features of Tivoli is that GUI functionality is also available via set of command line tools and in this sense classic Tivoli components (framework, TEC, TCM to name a few) are almost fully scriptable.

A large part of GUI functionality is available via set of command line tools and in this sense classic Tivoli components (framework, TEC, TCM to name a few) are almost fully scriptable.

Old or "classic" Tivoli components also in a limited way can be extended via custom scripting components (especially Perl). This is true for endpoints and this is partially true for TEC (you can invoke any scripts from TEC rules) and framework. 

One problem here is it looks like scriptability is a bastard child for Tivoli brass. Usage of Perl looks more like an accident initiated by "in the trenches" developers then a conscious management-approved strategy. The actual strategy was to push Java and is to provide as many closed source "add-on" components as market can bear.  IBM hype about adopting open source looks really funny if we look how scriptability is handled in Tivoli products :-). 

Still using command line tools provided by old Tivoli components, especially TEC, framework and configuration manager, one can still do quite a lot. You can also mix and match Tivoli with open source products. For example the correlation engine that is provided by TEC has no counterparts in open source world so it does not makes much sense to reinvent the bicycle.  It is Prolog-based and while this is not probably the best choice it is programmable so in a way it can be classified as better then opened ;-). It is important to implement strong pre-filtering as simple operation are very clumsy implemented in TEC. It is suitable only for complex correlation: duplicate removal, filtering, etc should be done at the lower level.

As we mentioned before TMF is the main component of Tivoli with TEC as second in importance. The latter is pretty close to the status of an integral part of the framework, not just an add on. With some scripting those two components can provide 80% of functionality of many other components in Tivoli stack.  In this sense we can call them "semi-open" is sense that you can extend then adding scripts in Perl ( or in other scripting language) to perform specific functions on remote computers. While other Tivoli products can be useful (and first of all TCM), but, generally using  TMF and TEC you can do almost everything you want (and with some programming skills you can do better then using prepackaged semi-baked IBM extensions like Risk Manager or Security Compliance Manager).  Tivoli monitoring 6.1 is  semi-independent product and if it can be bought without the framework and TEC is can be used as a substitute for both.

Actually another IBM product ( Lotus Notes ) has a very similar distributed architecture with replication and can serve as a good reference point to the weaknesses of Tivoli  in scripting (probably both product can share a large part of codebase). Both are proprietary messaging platforms but only Lotus Notes provides builtin scripting engine.  You can think about Tivoli events as specialized SMTP or IM messages, transferred files as attachments and end points as clients communicating with the server. But the differences in the quality of implementation are simply tremendous because in Lotus Notes area probably due to the fact that in mail area Microsoft kicked IBM's ass and in Tivoli they do not have as strong and aggressive competitor.  If, for example, we compare Lotus 6.5  client and servers (with Sametime instant messaging) and the recent Tivoli version it is clear which team has better, more flexible codebase (note that the recent version of Lotus Notes can work with DB2 which makes differences even smaller).

Lotus Notes GUI is scriptable and Tivoli is not. And that fact alone spells volume about quality of architects in both teams...

Also Lotus Notes clients can switch from one server to other and connections between servers can be dynamically rerouted: if one fails the other can pick-up messaging stream even if it cannot deliver all the messages.  Tivoli has inflexible strict star architecture and that makes it much less fault tolerant.  Without clusters Tivoli servers are the weakest link in the whole ESM architecture.  And clusters drive prices through the roof.  Paradoxically the best platform for Tivoli is not AIX servers but Solaris servers are they are more fault tolerant and can switch off faulty components dynamically.

Not that Lotus Notes is perfect (and Microsoft is working on proving that IBM does not understand componentization on the level that enables them to compete in retail software business in XXI century), but due to Microsoft pressure and more customer orientation they managed to be more agile, while Tivoli largely stagnated since IBM acquisition of the company in 1998.  Of course stability of the codebase has its merits, but only up to a point.

IBM adopted Java as an internal development language and attempted to convert existing Tivoli components and write new in Java. Superficially this was a very logical decision as Java provides the level of machine independence necessary and sufficient for most Tivoli components.  But Java is a deeply flawed language for system programming and any Java implementation is subject to JVM-hell and class libraries hell problems. If you use system-provided JVM then any upgrade of JVM can break Tivoli. So Tivoli should generally use its own JVM that should be upgraded independently of the system, the situation that creates a patching logistical mess.  BTW even with this arrangement HP-UX has problems.  If instillation procedure mixes the location of JVM and upgrade the wrong one and/op upgrades class libraries you also gets a problem. 

Moreover Java applications usually use too many class libraries, loading them during application start makes the latter extremely sluggish. Tivoli Enterprise Console front-end is a classic example of this problem. In this case slow start is combined with low quality of interface. That means that "Java push" sometimes decreases availability and reliability of the components affected,  which can be quite painful as Tivoli needs to be both very fast and reliable. Some Tivoli components like Advanced Monitoring 5.1 suffered from this Java hell and reliability problems for several years before IBM was able to stabilize them (luckily ITM 5.1 was eventually replaced by version 6.1 that does not use Java on endpoints; it does use Java based interface, though). Tivoli is probably too important enterprise system to rely on JVM and IBM might be better off  absorbing the costs of development of custom compiled language based plug-ins to its so called "light-weight" end point. I do not understand why compiled language is so bad as all compilation targets in any Tivoli deployment are known in advance.  Also Java as a development platform looks inferior to the tandem of scripting language (for example TCL or Perl) and a complied language (for example C).

Note of Pricing

Tivoli pricing is highly variable but basic staff is not very expensive. Most products are sold "per managed processor" and as such the price depends on the number of clients installed. For example, the cost of  a uniprocessor license for TEC for approximately $200 per CPU and that means that minimum is around $2K (you need to buy 1- unit minimum;  the license includes Tivoli framework):

That means that classic TEC is a very attractive solution for log aggregation: you need probably no more then a four-six CPU license to implement log aggregation for a half-dozen OS + a couple of different VPN boxes + a dozen  of security devices in a midsize corporation (say, 100-400 servers).  Actually quite a lot can be done with just one server that serve as LOGHOST and simultaneously hosts all Tivoli environment including DB2 (or Oracle) database. Server suitable for this includes Sun T1 2000 with Solaris 10 as well as any 2 or 4-way Opteron based server like ProLiant DL585 (or even more powerful Intel Duo/Quattro based server) under Solaris.

As for monitoring Tivoli Monitoring Express  ($795.00) definitely deserves attention as it also can serve as an aggregator for open source tools: organizations with highly heterogeneous IT infrastructure consisting of less then a hundred servers with various flavors of Unix as well as  Windows servers (the more mixed environment is the higher is return on investment) servers can use a single Windows server for pretty comprehensive monitoring (with a lot of "out-of the box" sensors and capability to add your own scripts, simplifying detection of problems and saving considerable fraction of time for both Windows and Unix administrators.

Minimization of Tivoli components

As long as you stick to minimum number of components (the rule "no more then seven" is a good guiding principle, for example TEC, TMF, ITM and TCM) Tivoli usefulness significantly increases with the size and complexity of the infrastructure. This is first of all due to highly sophisticated correlation engine and the ability to use scripting for custom probes on endpoints. The main recipe for success is to have highly qualified system administrators and to extent Tivoli with open source tools, especially, with custom scripts (Perl is an excellent tool that can be used with Tivoli).  Similarly buying too many components is an invitation to disaster as after magic number seven each couple of "large" components probably requires a dedicated administrator.  Generally the number of Tivoli components deployed at enterprise should be kept at minimum both due to the level of complexity of the product and staffing limitations as return on investment after bare minimum quickly falls.

Tivoli framework has somewhat outdated in messaging world "star" architecture that consists of: 

Conceptually Tivoli implementation consists of one or more regions. A region (TMR) is a hierarchical entity that consists of a single Tivoli server, one of more gateways and their clients (with endpoints installed). Endpoints are always communicating with server via a gateway.  Gateway can have local correlation engine to filter events before passing them to TMR.

There is also a  region connection facility, which includes support for multiple Tivoli regions that can be connected across different networks. IMHO one of the major shortcomings of such an architecture is that unlike mail clients or instant messaging clients endpoints can not work with different gateways and/or TMR servers for different classes of events (that can easily implemented on gateway level). So for example if you have two TMA servers, one for log aggregation and another for monitoring, then all endpoints that are subscribed to monitoring server are not accessible from the log aggregation server. That also greatly complicates recovery if TMR server failed (the operation Lotus Notes performs almost flawlessly). 

Generally interaction between the TMR server, gateway and endpoints in Tivoli is implemented very weakly from the point of view of recovery: if for example you shutdown the server for a considerable period of time, both gateway and endpoints can crash under the load of unprocessed events: there is no way to re-route them even if you have additional TMRs. If  gateway got a considerable amount of events (it can buffer them to a certain point) and gateway is still alive when you are restarting the TMR server, the situation can be even worse: you can experience the situation when you cannot start the TMR server as it crushes under the load of "storm" of buffered by gateways events.

I would like to stress that productive use of Tivoli does not need to expensive but saving can be achieved only with high-level skills in Unix administration, scripting (at least Perl, JavaScript and Korn shell) as well as database management skills. If you don't have those you better have deep pockets to pay for Tivoli consultants.

Note on Micromuse Acquisition

IBM plans to replace TEC with Netcool in 2012.  This is a mixed blessing.  The main "pro" claims are that Micromuse correlation engine is more scalable and needs less efforts for programming in typical situations (it is SQL-based).  

The main problem with Prolog is that it proved to be too complex (and less then adequate simultaneously) for simple situations that are the most common in enterprise environment. At the same time very few customers are doing anything complex (expert system level staff) with TEC anyway where Prolog represents distinct advantage. 

Also as a development environment (Prolog rules programming) reminds early 60th: bad diagnostics, bad tools, need to restart the server after changes in BAROC, etc.  Although not strictly necessary most customers restart the TEC server after changing rules too. That arrangement  makes Tivoli environment a joke from the point of view of modern programming environments. Can you imagine the language  programming environment that requires rebooting OS after the compilation of the shell ?  If you cannot TEC is a very close analog.

Micromuse technology as the base of a new correlation engine does not mean that old TEC correlation engine needs to be abandoned.  Some mixed solution are probably possible. Also there are many Prolog interpreter on the market including free.  They can be used in case staff known Prolog really well and people are productive in the language.

Access to Tivoli information and documentation

IBM provides an excellent set of guides and Redbooks that significantly increase the value of the product due to know-how they contain. It cannot compensate Hamphy-Dumphy nature of the product with documentation, but at least if helps to save face.

While not that useful for users (most are outdated), they are actually pretty useful reading for the authors and users of competing products ;-).  Of course they are of varying quality and in many cases 66% of the content is fluff but still one can safely state that Tivoli is a very well documented product.

Please note that Tivoli website sometimes behaves very strangely as it is a part of a huge IBM product line. For example, if you click Library link on Tivoli page and hope to get to Tivoli documentation you might be  disappointed: this is a link to generic IBM products library.  I hope that they will fix this someday...

Notes:
  • This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
  • The site contain some broken links as it develops like a living tree... Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.
Google Search
Open directory
Research Index

Old News ;-)

[Oct 5, 2009] Tivoli Technical Exchange Webcasts

IBM - All Tivoli Web-based Titles Now Available via Education Pack Program

All Tivoli Web-based courses are now available for purchase using Education Pack credits.

The IBM Education Packs are now even better. Why? All our Tivoli Web-based courses are now available for purchase using your Education Pack credits. From IBM Tivoli Access Manager to IBM Tivoli Workload Scheduler courses, you can now apply your credits to the entire training roadmap!

More information can be found at
http://www.ibm.com/software/tivoli/education/wbt-edpack.html

Tivoli Product End-of-Support Matrix

Looks like classic Tivoli is going away in 2012 with the demice of TEC.

[Dec 2, 2008] IBM - Tivoli Framework Patch 4.1.1-TMF-0104

Download package What is DD?
Download RELEASE DATE LANGUAGE SIZE(Bytes) Download Options
4.1.1-TMF-0104.tar 9/23/2008 English 111400000 FTP DD
4.1.1-TMF-0104.README 9/23/2008 English 226000 FTP DD
411TMF104.image.rpt 9/23/2008 English 134000 FTP DD

IBM - Tivoli fix pack Strategy Update

[Apr 23, 2008] IBM Tivoli Enterprise Console Newsletter

Welcome to the first edition of the IBM TEC Newsletter which can be found at
http://www-1.ibm.com/support/docview.wss?rs=203&uid=swg27011895 

The Newsletter consists of

The Newsletter is updated as soon as relevant information is available ( and at least monthly). Visit the Newsletter frequently by bookmarking the Newsletter URL and give us your feedback.

If other colleagues could benefit from this information please ask them to send a blank email to tivnew@uk.ibm.com with "SUBSCRIBE - IBM TEC Newsletter" in the subject line

If you do not wish to receive this Newsletter, I apologise for contacting you. In this case would you return this mail with "UNSUBSCRIBE - IBM TEC Newsletter" in the subject line to remove your details from the distribution list.

Please send all comments/ feedback to tivnew@uk.ibm.com

[Mar 01, 2009] Microsoft's Ballmer On Windows Server, Yahoo, Linux -- Microsoft -- InformationWeek

InformationWeek: I think you see VMware aggressively courting virtualization customers. Customers that I've spoken with are saying Microsoft is definitely coming from behind here. You mentioned it on stage here. There's Hyper-V's delay. Does Microsoft's entrance now into the virtualization space put it at a disadvantage in the virtualization world?

Ballmer: The choice is, you know, to be first to have share or not. I guess I prefer to be first to have share. Now, you've got to remember, this market has barely been scratched, less probably in the install base -- less than 5% of all systems run virtually. Virtualization is way too complicated, way too expensive today for people to take advantage of it, and it's way too isolated from the rest of everything that happens in application development to data center deployment and operations. That's not my way of criticizing, it's just if we're going to get -- if the phenomenon is going to fully take effect, then we've got to democratize it. That might be VMware, [but] they haven't shown moves in that direction. Somebody could argue it might be one of the open source alternatives. I like what we've got. I think we pay out on those problems.

That doesn't mean the other guys are going to go away. Obviously we recognize that fact and we provide good interoperability with VMware's virtual machine. But I don't think -- there's a simplicity with performance, with management, integrated management, with everything else, I think we're going to make a real difference. Sure, I wish we had everything we're announcing now and shipping this year a year ago, sure. Two years ago? Sure. But, believe me. We're going to make a big difference.

Comments

The fact of the matter is Linux isn't much cheaper to use than Microsoft, in terms of initial expense, continued support, or even in terms of development.

What Linux excels in is its large community of free, and sometimes paid developers to fix problems corrected more quickly than a single company can possible achieve. When you take Linus' recent comments into account, about him never caring or running a Linux server, only being focused on the desktop, one has to really wonder what how it can possibly compete with commercial giants like Sun and Microsoft.

What Microsoft excels in is their world-class support and a quality product at a reasonable price with an enormous ecosystem and unlimited developmental budget.

The commercial Linux vendors, Red Hat and Suse, can't offer the ecosystem Microsoft does, nor the leverage it has with its developers or vendors. The non-commercial Linux distributions are fun to play with, but totally impractical for business use.

The war goes on... Linux and most significantly Solaris are taking a bad beating. Once MS goes full bore in the virtualization space, it's going to blow Linux, Solaris and WMWare out of the market entirely, because of its massive commitment in research and functionality.

Finally, if MS doesn't like how its being treated in the US or Europe for that matter, it might just decide to stop selling to those markets -- where would that leave customers?

... ... ...

Ballmer: "I used to always joke with IBM, you know, we were opening up the desktop to them, and they were opening up the mainframe and the data center to us. And who out-hustled who is a big deal in terms of who wins."

[Nov 20, 2007] developerWorks Tivoli Tivoli TME10 Mailing List How to create a TMF endpoint local ...

Hate installing TMF endpoint from the server? Here's how to create a TMF endpoint local install package.

http://bmitch.net/tivoli/

[Nov 16, 2007] Issue 12 of The Tivoli Advisor is now available at ftp://ftp.software.ibm.com/software/tivoli/tivoli-advisor/Tivoli-Adivisor-Issue-12.pdf

In this issue
TADDM’s Flexible Approach to Discovery
WebSphere Business Integration – an overview
An Introduction to Identity Management (IdM)
New name and new enhancements for Tivoli AF/REMOTE as it joins the IBM System Automation family
IBM launches Governance and Risk Management site

You can also download any of the other issues at http://www-306.ibm.com/software/tivoli/resource-center/overall/news-tivoli-advisor.jsp

Issue 13 will be following close on the heels of this one, so look out for it before the end of the year.

Tivoli Field Guide - Tivoli Assessment Tool (assess.pl) Guidelines for the use of the Assess tool and analysis of results obtained.  

The Assess tool consists of a suite of perl 4 scripts intended for use in capturing, and assessing of significant architectural information related to an installed Tivoli environment. It is compatible with all currently supported Tivoli Management Framework versions.

IBM Software Support Tivoli Tivoli Technical Field Guides

Tivoli Field Guide - Event Processing Tools Available in IBM Tivoli Enterprise Console 3.8   The purpose of this paper is to provide an overview of the event processing tools available in IBM Tivoli Enterprise Console version 3.8. It also ties these tools together so the customer can make informed decisions when planning event management strategies and implementations. Pre-filtering, filtering, state-based correlation, rules, gateways, and endpoints are all discussed.

Tivoli Global User Group Community Newsletter, Jan 2007

IBM Software Support Toolbar - Now available for Firefox and IE7, with Tivoli content enhancements

The IBM Software Support Toolbar. With this tool, you have a quick and easy way to find highly requested software support pages in just a click or two. Adding the ability to search IBM's multiple resources, even narrowing that search down to a specific Brand/content.

For Tivoli users, you now have toolbar access in the Tivoli options, under 'More Resources' for OPAL, Technical Exchange Webcasts, IBM Education Assistant, Product Training, Certification, User Group community site and problem support escalation contacts.

You can install from: http://www- 306.ibm.com/software/support/toolbar/index.html? ibmsst=ibmTbMenu

Increase IT productivity with technically validated extensions available on-line via OPAL
The IBM Tivoli Open Process Automation Library (OPAL) is a comprehensive on-line catalog that includes more than 300 technically validated extensions developed by IBM Tivoli Business Partners and IBM. OPAL includes services and downloadable system integrations, automation packages, integration adapters, agents and configuration files.

Tivoli Global User Group Community Newsletter, March 2007

FREE SUPPORT CUSTOMERS: IBM Support Assistant
The IBM Support Assistant (ISA) is a free local software serviceability workbench that helps users resolve questions and problems with IBM software products. It provides quick access to support-related information along with serviceability tools for problem determination. Whether you need to find information on a software fix, collect key logs, or want to build skills on a particular product, the IBM Support Assistant can help get it done. Listing of available product plug-ins.

Download the IBM Support Assistant today!

[Apr 27, 2007] 2007 Tivoli Technical User Conference directory (1.7MB)

Again too much buzz-words like ITIL, service-oriented architecture, etc ;-). Also dilution of Tivoli brand into multitude of new products did not stopped...

[Apr 26, 2006] NIST Security Configuration Checklists Program for IT Products Enterprise System Management Security Technical Implementation Guide

[Feb 24, 2006] Tivoli Links Gulf Breeze Software Partners Tivoli Consulting Training We are Tivoli experts

Posted by: martinc on Feb 24, 2006 - 08:31 PM
BlogArticle 
When looking for information on the Tivoli products there are many places to try to find this information. In fact there are so many places, you can forget where they were. Here is a list of sites that are full of useful information (ok sometimes not so useful or helpful) to help you find what it is you are looking for.

If there is a link that is not on this entry, please let me know and I would be glad to add it (martin.carnegie at gulfsoft d-o-t com)

Gulf Breeze Software - have to start somewhere :)
http://www.gulsoft.com

IBM Tivoli Homepage
http://www-306.ibm.com/software/tivoli

Tivoli Search. Includes searches of the TME10 Listserv
http://www-306.ibm.com/software/sysmgmt/products/support/consolidated.html

Tivoli Redbooks
http://publib-b.boulder.ibm.com/Redbooks.nsf/portals/tivoli

IBM Tivoli Information Center - This contains online docs of all Tivoli products
http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp

IBM Tivoli Information Center - Configuration Manager documents
http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?toc=/com.ibm.tivoli.itcm.doc/toc.xml

Support Technical Exchange (STE) - Webminars on various Tivoli products. There are also past webminars available for download
http://www-306.ibm.com/software/sysmgmt/products/support/supp_tech_exch.html

Tivoli User Groups
http://www-306.ibm.com/software/sysmgmt/products/support/Tivoli_User_Groups.html

Tivoli Security Forum - This is a recent addition from Lindsay Blanton III, nice work
http://www.tivolisecurityforums.com

Tivoli Inventory Signature files
ftp://ftp.software.ibm.com/software/tivoli_support/misc/CandO/TivoliCatalog

Tivoli FTP site for patches
ftp://ftp.software.ibm.com/software/tivoli_support/patches

AppDeploy - This is a great site to check for how to distribute a package. There is some Tivoli related information, but is generally around installing an application in an unattended mode
http://www.appdeploy.com/

Don't forgot to check Google! If you are getting some error message during your installs, check Google. There is a good chance that it is not a "Tivoli Problem".
http://www.google.com

ITIL Homepage - This is a standard that IBM (and many other companies) is following around best practices for Systems Management
http://www.itil.co.uk/

Some more links thanks to Harald Wikell, Chairman Swedish Tivoli USer Group

IBM Tivoli Field Guides
http://www-306.ibm.com/software/sysmgmt/products/support/Field_Guides.html

IBM Tivoli Catalog
http://www-18.lotus.com/wps/portal/tm

Tivoli Maillist Archive
http://tme10.uio.no/Apps/Tivoli-List.nsf/main?OpenView

Tek Tips TME 10 Forum
http://www.tek-tips.com/threadminder.cfm?pid=29

IBM Developer Works Tivoli Forum
http://www-106.ibm.com/developerworks/forums/tivoli_forums.jsp

NetView Web page
http://www.nv-l.org/twiki/bin/view/Netview/WebHome

NetView Mailing list archive
http://lists.skills-1st.co.uk/mharc/html/nv-l

TSM User Group with good web site
http://www.jasi.com/TSMUG/index.php?page=links

[Apr 2, 2005] Micromuse Buy Gives IBM Strong But Overlapping Capabilities

IBM hopes the Micromuse acquisition will strengthen its comparatively weak Tivoli NetView network management offering and position the company to address the requirements of converged voice and data networks for both enterprises and telecommunications companies (telcos). However, Tivoli has limited presence in the market for managing telco networks, and customers will likely will be skeptical of an inexperienced newcomer. Gartner believes that another, unstated reason for the acquisition is the need to dramatically increase the scalability of Tivoli’s event management. This will be necessary for IBM's service-oriented architecture strategy, which combines business, security and IT infrastructure events. However, Micromuse's functionality overlaps with that of IBM’s own Tivoli Enterprise Console (TEC) product, which has an important installed base that Tivoli cannot afford to alienate. TEC and Netcool coexist and exchange events at a number of customer sites, but in the long term, Tivoli cannot maintain two competing, overlapping products. IBM will aim to have the best of Tivoli and Micromuse functionality, and a smooth migration to a future combined product, but must select one base architecture or the other. Gartner believes it will likely be Micromuse Netcool, due to the requirement for real-time, scalable event handling.
 
Recommendations

Tivoli Technical User Conference - 2006.  Hilton Hotel in Chicago , IL April 23-27, 2006 .

MARK YOUR CALENDARS: IBM Tivoli is pleased to announce two Tivoli Technical User Conferences. The first conference will be held at the Hilton Hotel in Chicago , IL April 23-27, 2006 .

This four day conference promises to be the most dynamic events ever with a new compelling agenda that includes first rate IT education, industry thought leader and customer speakers, and the latest information on how to extend ITIL by leveraging IBM IT Service Management to automate and integrate IT processes for a more efficient and effective IT organization.

The Hilton Chicago, located at 720 South Michigan Ave is right in the heart of beautiful downtown Chicago and will serve as the host hotel for the conference. One of the leading convention hotels in Chicago, the Hilton brings the best of conference facilities to the attendees of the Tivoli Technical User conference.

[PDF] Tivoli Impact Assessment Report Old NASA report. View expressed is similar to this page: heavy, over-engineered product suffering from excessive complexity.

[Feb 24, 2006] IBM Tivoli Monitoring Flash demo Play Flash demo Download Flash demo

In this demonstration we will see how Tivoli's new Enterprise Portal provides access to all of your enterprise's monitoring data in one location. It provides superior information visualization allowing you to take quick action on those issues that are affecting the health of your enterprise. We'll also see the new easy-to-manage virtualization capabilities of the new IBM System p5, like the ability to dynamically allocate CPU resources exactly where and when they're needed. The combination of the IBM p5 systems and the Tivoli Availability solutions provide an unsurpassed solution for Server reliability and manageability.

[Feb 24, 2006] IBM Redbooks Getting Started with IBM Tivoli Monitoring 6.1 on Distributed Environments

The IBM Tivoli Monitoring Version 6.1 solution is the next generation of the IBM Tivoli family of products that help monitor and manage critical hardware and software in distributed environments. IBM Tivoli Monitoring 6.1 has emerged from the best of the IBM Tivoli Monitoring Version 5 and OMEGAMON technologies. Integration of these products creates a unique and comprehensive solution to monitor and manage both z/OS and distributed environments.

IBM Tivoli Monitoring 6.1 is easily customizable and provides real-time and historical data that enables you to quickly diagnose and solve issues with the new GUI via the IBM Tivoli Enterprise Portal component. This common, flexible, and easy-to-use browser interface helps users to quickly isolate and resolve potential performance problems.

This IBM Redbook covers planning, architecture, tuning, implementation, and troubleshooting of IBM Tivoli Monitoring 6.1. In addition, we offer scenarios for migration from Distributed Monitoring 3.7, and IBM Tivoli Monitoring 5.X coexistence with IBM Tivoli Monitoring 6.1.

This book is targeted for IT specialists who will be working on new IBM Tivoli Monitoring 6.1 installations on distributed environments or implementing migration from Distributed Monitoring 3.7 or IBM Tivoli Monitoring 5.X coexistence.

[Feb 24, 2006] IBM Redbooks Deployment Guide Series IBM Tivoli Monitoring 6.1

This IBM Redbook focuses on the planning and deployment of IBM Tivoli Monitoring Version 6.1 in small to medium and large environments.

The IBM Tivoli Monitoring 6.1 solution is the next generation of the IBM Tivoli family of products that help monitor and manage critical hardware and software in distributed environments. IBM Tivoli Monitoring 6.1 has emerged from the best of the IBM Tivoli Monitoring V5 and OMEGAMON technologies. Integration of these products makes a unique and comprehensive solution to monitor and manage both z/OS and distributed environments.

IBM Tivoli Monitoring 6.1 is easily customizable and provides real-time and historical data that enables you to quickly diagnose and solve issues with the new GUI via the IBM Tivoli Enterprise Portal component. This common, flexible, and easy-to-use browser interface helps users to quickly isolate and resolve potential performance problems.

The target audience for this book is IT Specialists who will be working on new IBM Tivoli Monitoring 6.1 installations.

Redbook/Implementing a Tivoli Solution for Central Management of Large Distributed Environments

Chapter 1. The challenges of managing an outlet environment
Chapter 2. The Outlet Solution overview
Chapter 3. The Outlet Systems Management Solution Architecture
Chapter 4. Installing the Tivoli Infrastructure
Chapter 5. Creating profiles, packages and tasks
Chapter 6. Deployment

IBM - Tivoli fix pack Strategy Update When will we ship fix packs?

The available dates on which fix packs may ship for 2004 through 2008 are listed below. Not all products will ship a fix pack on these dates, but if a product does ship a fix pack, it must be on one (or more) of these dates. This will enable customers to plan maintenance windows around these dates.

Improve security and lower costs with more effective Identity Management

Ever-increasing numbers of users are getting "connected." That's good for business but it poses a host of security, privacy and auditing challenges at a time when cost reduction is essential. Tivoli Identity Management solutions can help you satisfy user needs, optimize security and keep cost under control. Download this Identity Management whitepaper now to learn about the most cost-efficient identity management solutions utilizing reusable solution infrastructure.

IBM Redbooks Enterprise Security Architecture Using IBM Tivoli Security Solutions

Recommended Links

In case of broken links please try to use Google search. If you find the page please notify us about new location
Google     

Support cycle

IBM Software Support - Overview

The elements of the enhanced Software Support Lifecycle Policy for selected Information Management, IBM Lotus, IBM Rational, IBM Tivoli and WebSphere products are:

 

Standard IBM Support Lifecycle Policy
Products that are not currently covered by the enhanced IBM Software Support Lifecycle policy continue to have the existing software support lifecycle policy, which includes:
  • Provide a minimum of 3 years of product technical support beginning at the planned availability date of the version/release of the product.
  • Ensure support is available for all IBM components of a product or until the product or bundle is withdrawn from support. In addition, all components of a bundle have a common End of Service date.
  • Publish a notice of support discontinuance ("End of Service") for a product at least 12 months prior to the effective date.
  • Align the effective date of support discontinuance ("End of Service") to occur on common dates either in the months of April or September.
  • Make product support extensions available, where possible, that are designed to allow migration to the current release to be completed. For additional information on product technical support extensions beyond the three-year minimum period, contact your IBM representative. For details see the announcement letter USA Ann# 203-204 effective August 8, 2003.

 

IBM Software Support Tivoli product lifecycle dates

Field Guides
(Access needs IBM account)

IBM Support Get access need ICN

IBM Software Support

 

Support Cycle

IBM - Tivoli fix pack Strategy Update When will we ship fix packs?
The available dates on which fix packs may ship for 2004 through 2008 are listed below. Not all products will ship a fix pack on these dates, but if a product does ship a fix pack, it must be on one (or more) of these dates. This will enable customers to plan maintenance windows around these dates.

Tivoli Product End-of-Support Matrix

Tivoli User Groups

tme10 mailing list is the main list for Tivoli questions.  I wouldn't recommend staying subscribed to the list
unless you have an ongoing interest in Tivoli as it is rather high volume; you can read the list via Gmane

tme10 mailing list gatewayed to Gmane
news://news.gmane.org/gmane.comp.sysutils.tivoli.general

UK:

Etc

Tivoli software training and certification

IBM Customer Number Also known as "ICN" and "Customer ID". A 7-digit code (made up of numbers and/or letters) that identifies a customer's IBM software support contract. Within the IBM Software Support Web site, ICNs must be entered as seven digits. Some customers might receive ICNs with six or eight digits. If you received a 6-digit ICN, enter a zero followed by the six digits of the ICN. If you received an 8-digit ICN, you need only enter the last seven digits.

Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Disclaimer:

Last modified: November 17, 2009