FTU Task 1: Understand the minimum background information needed to get started

Monitoring servers

The monitoring system employs a client/server method where various agents collect data on the items you want monitored and they send that data to a central server where the client user interfaces have access to it. The server also takes data from the user interfaces and passes it back to the appropriate agent to effect changes that the user may want.

A single hub monitoring server can have up to 20,000 agents reporting to it and many instances of user interfaces connected to it. The agents that report to the hub can reside on z/OS®, Linux® on Z or distributed systems, Windows, or UNIX, which gives you a picture of your entire enterprise, not just z/OS. Note that when many agents are reporting directly to a single hub, configuring the remote Tivoli® Enterprise Monitoring Server is important for maintaining the performance and availability of your monitoring system.

To avoid those issues, there are also remote servers. These servers can be distributed throughout the enterprise and offload work from the hub by having many of the possible 20,000 agents report to the remote servers rather than to the hub. The remote servers then interact with the hub on behalf of the agents that report to the remote. If the hub goes down, the remote servers will continue to collect data from the agents and pass it along to the hub when it comes back on line. The same is generally true for the agents themselves should the server they interact with not be available.

There is only one hub in a monitoring enterprise. If your site has more than 20,000 endpoints to be monitored, then you have set up more than one hub. As a separate system, each hub would have its own distinct group of monitoring agents, remote servers, client user interfaces, and historical data collection.

On z/OS, there are a couple of monitoring agents that must run inside the address space of the server. In those cases, there must be a server (usually a remote server) configured and running along with the agent. Note that the type of the server is controlled by a mode switch. In other words, the code and programs are the same and whether a server is a hub or remote is controlled by parameters settings.

For z/OS, all of the remote servers would be configured to run on z/OS. The hub, however, can run on other systems besides z/OS, such as Linux on Z or distributed systems, Windows, or UNIX. The FTU tasks in this guide have you set up a hub server on z/OS to start with, then you’ll have an opportunity to change that to another permanent location.

The hub server is clearly a key component in the monitoring system, one that you can’t have going down even for routine maintenance. If the hub is on z/OS, it can be configured as a high-availability hub (HA hub) using DVIPA (Dynamic Virtual IP Addressing). On the other operating systems, a “hot standby” hub can be configured that mirrors the hub and then takes over when needed.

Monitoring agents must store certain credentials and artifacts on all the servers (hub and remote) so that the servers know how to interact with them. For distributing these agent files and maintaining their currency, use the self-describing agent (SDA). The SDA feature is employed by the FTU configuration tasks, and described in a following section.

For a picture of how the basic components of the monitoring system work together, see Tivoli Management Services components.

User interfaces

There are several user interfaces available to you. The two user interfaces that this guide will talk about are the OMEGAMON® Enhanced 3270 user interface (Enhanced 3270UI) and the Tivoli Enterprise Portal.

The Tivoli Enterprise Portal is run from a browser. It connects to its own server, the Tivoli Enterprise Portal Server (the portal server). The portal server runs on Linux on Z or distributed systems, Windows, or UNIX. The portal server interacts with the hub server to display data for your entire enterprise, including data for both distributed and z/OS-based monitoring agents.

The Enhanced 3270UI provides browser-like interaction on a 3270 emulation terminal. The interface interacts with the hub server and displays data for z/OS-based monitoring agents. It is also referred to as the Tivoli OMEGAMON Manager.

There are two other z/OS-based user interfaces. The first is the “classic” or menu system interface, which is the interface provided with the original four OMEGAMONs, those for z/OS, CICS®, IMS, and Db2®. The other interface is the CUA interface, which employs a basic graphical user interface from which you can drill down to the meaningful data behind status changes. You can use any or all of these user interfaces at the same time. The FTU tasks focus on using the Enhanced 3270UI because it is useful for z/OS-based monitoring tasks.

SDA

SDA stands for “self-describing agent.” Self-describing agents include all the application support files required to recognize and process data from those agents. At startup, self-describing agents automatically push application support updates to their local monitoring server. The data is then replicated to the hub monitoring server and all other Tivoli Management Services components that require it (such as the Enhanced 3270UI, the portal server, and the Tivoli Data Warehouse).

Self-describing monitoring agents eliminate the need to recycle the monitoring server after application support updates and to ensure that application support files are current. If the SDA feature is not enabled, application support must be installed manually from a DVD and can easily get out of sync with the agent.

By default, the SDA feature is enabled for any monitoring agent that provides self-describing support, but the feature is disabled on monitoring servers. If your enterprise includes self-describing agents, you can enable SDA by changing parameter values for the monitoring servers. You can selectively enable or disable SDA for individual agents or monitoring servers. In addition, SDA provides granular control over the products and versions for which application data is automatically installed.

Activating the SDA feature for OMEGAMON requires that you specify a z/OS UNIX System Services file system to store agent artifacts that are used by the monitoring servers. The FTU model RTE used in Task 4 (@MDLHSS) is set up to use SDA, which means that the KDS_KMS_SDA parameter in the RTE configuration profile is set to Y. You can always set up another runtime environment that does not use SDA after you better understand all the components and how they interact.

For more information about SDA feature, see Self-describing agent feature.

Historical data collection

The Tivoli Data Warehouse, an optional component of Tivoli Management Services, is the long-term data store for the performance and analysis data collected by the monitoring agents. The data warehouse is stored on a supported database (such as Db2®, Oracle®, or Microsoft® SQL) by the Warehouse Proxy agent (WPA). The WPA periodically receives data (either indirectly from the hub monitoring server or directly from the monitoring agents) and inserts that data into the Tivoli Data Warehouse.

PARMGEN

Parameter Generator, or PARMGEN, is the name of the configuration tool supplied with OMEGAMON and related products. IBM supplies everything you need to get the monitoring products running; however, the supplied template files need to be customized for the specific settings used at your site.

You’re probably very familiar with modifying JCL, adding a job card, changing data set names and disk characteristics for any product you’ve ever tried to use on z/OS. You might have to change product-supplied parameters as well to suit the way you intend to use the supplied product. PARMGEN provides a framework for accomplishing all of those same updates, as well as mechanism to retain and re-implement the same modifications whenever you clone or update your monitoring system.

Each of the products in the monitoring system deals with a different application. The monitored applications clearly have unique needs and methods, so it stands to reason that the agents that monitor applications also have different needs from one another, including unique parameters that must be tuned for the application. PARMGEN helps to manage all of those things.

There are four elements at the heart of the PARMGEN process.

First, there is the PARMGEN ISPF-based menu, called the PARMGEN workflow interface. This interface guides you through the configuration work required to get the monitoring system running as desired for your site. This tool also verifies that data sets exist and that parameter values are within range.

Second, there are configuration profiles (global and RTE-specific) that contain all of the settings for parameters, switches, and variables that control how the monitoring products work at your site. The PARMGEN tool aids you in setting these values correctly for your site and updates the profile. It still may be necessary for you to review the contents of the profile manually to ensure values and switches are all correct.

Third, there are supplied templates (JCL, data, embeds, and SYSIN) used to run the monitoring programs. These templates use the same variables and strings found in the PARMGEN profile as placeholders in the templates.

Fourth, a program called $PARSE reads the PARMGEN profile and substitutes the values from the profile into the placeholder positions in all the templates. For example, $PARSE inserts an instance of your job card into all the supplied JCL and substitutes your desired high-level qualifier and disk-related values so that everything matches your data set naming conventions. $PARSE also makes updates according to all the product-specific parameter changes you’ve made and modifies data, embeds, and SYSIN accordingly.

In other words, by the time you see and submit JCL, all of your chosen values will already be in place. You just interact with the PARMGEN ISPF interface and PARMGEN updates the PARMGEN profile, makes various string substitutions, and presents updated JCL for you to submit.

A best practice is to implement user and system variables in the configuration of the monitoring system. This greatly aids in cloning to different systems. The cloned runtime environment will then pick up the values of the new system. Implementing system variables is a step in the FTU configuration process. Just follow the tasks in this guide.

For more on PARMGEN, see The PARMGEN configuration method.

RTE

A runtime environment, or RTE, is a logical grouping of runtime libraries that are referenced by started tasks running on a z/OS image. This grouping is useful because you won’t always want to implement every monitoring product that you installed via SMP/E on every system or LPAR. For example, you may have installed OMEGAMON for IMS on z/OS, but not every LPAR contains an instance of IMS to be monitored. Therefore not every RTE should have a configured version of OMEGAMON for IMS.

There are different types of RTEs you can configure that control the way SMP/E libraries are used. The initial FTU configuration uses an RTE type that concatenates the actual SMP/E target libraries in the started tasks. Sharing libraries with SMP/E can have some advantages that are appropriate for a test environment, namely that any changes or maintenance that you install are immediately employed in the RTE.

Because the immediate implementation of maintenance and changes is not typically a best practice for non-test systems, the initial SMP/E-sharing RTE created in the FTU process will be changed later to an RTE type that’s more appropriate for production, namely one that maintains a static copy of the target libraries so that it is not affected by changes to the target libraries. A static RTE type gives you control over when and how production libraries are updated.

What types of runtime environments to set up contains all the information you’ll need to understand the concept of an RTE and the types of RTEs available to you. But please follow the FTU process to begin with and set up an RTE that shares with SMP/E. Again, this will be changed to a static type of RTE later in FTU process.

Exclude Find (XF)