Longpela Expertise logo
Longpela Expertise Consulting
Longpela Expertise
Home | Press Room | Contact Us | Site Map

LongEx Mainframe Quarterly - February 2010

technical: The Basics About ITM

Almost all Tivoli monitoring products, including those running on z/OS, now use a single framework to process and display information – the IBM Tivoli Monitoring (ITM) framework. ITM provides IBM with a common front-end that allows users to integrate and combine features and information from different monitoring products. This article provides an introduction to ITM – what it is, what it does, and how it works.

When IBM acquired Candle in 2004, they also acquired three products that have become the face of almost all Tivoli monitoring products: Omegamon XE, Omegamon DE and CandleNet Portal. Today, these have become IBM Tivoli Monitoring (ITM).

ITM can be viewed as the basic building block for Tivoli (and some ISV) monitoring products. By itself, it doesn't monitor anything. What it does is to provide facilities that other monitors can use to process, archive and present performance and availability information. Facilities like warehousing, information processing, alert generation, and a framework to create workspaces that present the information.

ITM consists of several individual components, as shown below.

Let's look at each of these components.


At the heart of everything is the Tivoli Enterprise Monitoring Server (TEMS), previously known as the Candle Management Server, or CMS. This is the clearing house for alerts, and performance and availability data sent in from agents (more on these in a moment). It

  • Checks that all agents are responding by sending and receiving a regular 'heartbeat'.
  • Stores short-term data from agents.
  • Stores, starts and tracks all situations and policies.
  • Stores every active condition on every agent.

The TEMS stores all this information in a special database format called EIB (Enterprise Information Base) – essentially a group of files that are installed as part of the TEMS.

You can see that the TEMS does a huge amount of work, which can be too much for a single server. ITM allows the TEMS to be split up – so separate servers can share the load. There is at least one 'hub' TEMS (*LOCAL), which is the boss. 'Remote' (*REMOTE) TEMS control a subset of agents, and connect to the HUB TEMS.

TEMS includes ITM Web Services, a SOAP server. Any program or product can send SOAP requests to the TEMS to retrieve information, and manage policies and situations.

Tivoli hasn't forgotten users of the Tivoli Enterprise Console (TEC) and (Micromuse) Netcool/OMNIbus. ITM 6.2 can receive events from both using the Tivoli Event Integration Facility (EIF).

A TEMS can run on z/OS – installed using Tivoli's standard CICAT TSO/ISPF dialogs. However sites keen to minimise their z/OS processor usage will host all TEMS on Windows or UNIX servers.


The TEMS Agent (TEMA, previously known as the Intelligent Resource Agent, or IRA) runs on the system or subsystem being monitored – including z/OS. It sends performance and availability data back to the TEMS (including heartbeat acknowledgments). TEMAs can also process commands and SQL-like queries from their TEMS.

The TEMA comes with the product doing the actual monitoring - not with ITM. One exception is the operating system monitoring TEMAs that come bundled with ITM - for Microsoft Windows or UNIX only. No such freebies for z/OS - the separately priced Omegamon for z/OS is needed. In some products the TEMA actually performs the monitoring duties, in others it is the 'middle man' between monitors and the TEMS. The agent can run within a monitor, or as its own process or address space. In z/OS terms, the TEMA is usually a separate started task.

Developers and ISVs can build their own agents using the ITM agent builder – an Eclipse wizard.

TEPS and TEP Client

Previously called the CandleNet Portal, the Tivoli Enterprise Portal (TEP) is how users see and manage ITM. The Tivoli Enterprise Portal Server (TEPS) manages the presentation of ITM data. It

  • manages userids and user access rules
  • provides core presentation facilities

The TEPS needs a database system: either DB2 or SQL Server. TEPS cannot run on z/OS.

Users access this information from TEP clients – using either a Java client running on their PC, or the HTTP server on the TEPS via a web browser.

Whichever TEP client is used, the display is the same.

ITM comes with a basic set of workspaces, showing agents installed and alerts that are active. Individual agents add to this basic set. Each agent can supply their own workspaces to view current data, alerts, or events. They can also add functionality to issue commands via the 'Take Action' facility, and provide more information and expert advice using the ITM 'Expert Advice' feature.

Users can also define their own workspaces. A big advantage with ITM is that data from several different agents can be integrated into one single workspace.

When monitoring systems using ITM, there are three powerful features that can be used:

  1. Alert – an alert is created when something is wrong or needs attention. Alerts can be sent from agents, or created from situations. Alerts can be seen on the standard ITM workspaces.
  2. Situations - using the TEP client Situation Editor, users can define a trigger – something that is satisfied when a threshold is reached, a problem occurs, or a value is matched. Once triggered, an alert is created.
  3. Policies – policies can be setup using the Workflow Editor to automatically respond to a situation. This response can be anything from submitting an agent command, saving information in the TDW, or notifying staff.

Tivoli Data Warehouse

ITM optionally works with Tivoli Data Warehouse (TDW) to archive information for later use. It provides an agent (Warehouse Proxy Agent, or WPA) to consolidate some or all historical data from the TEMS and store in the TDW.

The Summarization and Pruning Agent processes the raw data in TDW, storing it in a more useful pattern, removing obsolete data, and generally managing the enormous amount of data that can be produced by agents. TDW needs DB2, SQL Server or Oracle Database. No components of TDW run on z/OS.


The ITM infrastructure has become the basic building block for almost all Tivoli monitoring products – including those running on z/OS. This provides a common user interface that can be used to integrate and combine different Tivoli (and possible ISV) monitoring products.

Although the ITM TEMS and z/OS related TEMAs run comfortably on z/OS, all other components must run on Windows or UNIX servers.


David Stephens

LongEx Quarterly is a quarterly eZine produced by Longpela Expertise. It provides Mainframe articles for management and technical experts. It is published every November, February, May and August.

The opinions in this article are solely those of the author, and do not necessarily represent the opinions of any other person or organisation. All trademarks, trade names, service marks and logos referenced in these articles belong to their respective companies.

Although Longpela Expertise may be paid by organisations reprinting our articles, all articles are independent. Longpela Expertise has not been paid money by any vendor or company to write any articles appearing in our e-zine.

Inside This Month

Printer Friendly Version

Read Previous Articles

Longpela Expertise understand z/OS. We can help administer your systems, train your staff, and provide locum Systems Programmers for short periods. Contact us to get your own z/OS administration expert.
© Copyright 2010 Longpela Expertise  |  ABN 55 072 652 147
Legal Disclaimer | Privacy Policy Australia
Website Design: Hecate Jay