IBM OMEGAMON z/OS Management Console › redpapers › pdfs › redp4166.pdfviii IBM OMEGAMON z/OS...

ibm.com/redbooks Redpaper

Front cover

Customizing and Using IBM OMEGAMON z/OS Management Console 4.1.0

Sergio BacciCurtis Massie

Provides installation options

Offers Health Checker integration

Provides sample scenarios

http://www.redbooks.ibm.com/


International Technical Support Organization


March 2007

© Copyright International Business Machines Corporation 2007. All rights reserved.Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP ScheduleContract with IBM Corp.

First Edition (March 2007)

This edition applies to Version 4, Release 1, Modification 0 of IBM OMEGAMON z/OS Management Console (product number 5698-A38).

Note: Before using this information and the product it supports, read the information in “Notices” on page v.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiThe team that wrote this IBM Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Chapter 1. Customizing IBM OMEGAMON z/OS Management Console . . . . . . . . . . . . 11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Planning the configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Installation checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.2 Data Warehousing considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3 ITSO configuration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3.1 Runtime configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3.2 Tivoli Enterprise Monitoring Server customization . . . . . . . . . . . . . . . . . . . . . . . . 161.3.3 OMEGAMON z/OS Management Console agent customization . . . . . . . . . . . . . 191.3.4 Start up procedure naming convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.3.5 WLM recommendation for z/OS Management Console execution . . . . . . . . . . . . 19

1.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4.1 Customization hints and tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Chapter 2. Using the OMEGAMON z/OS Management Console . . . . . . . . . . . . . . . . . . 232.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2 Sample scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.2.1 Adding a situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Chapter 3. Integration with Health Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.1 Health Checker workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.1.1 Adding customized situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

© Copyright IBM Corp. 2007. All rights reserved. iii

iv IBM OMEGAMON z/OS Management Console

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.

© Copyright IBM Corp. 2007. All rights reserved. v

TrademarksThe following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

AIX®Candle®CICS®IBM®OMEGAMON®

Parallel Sysplex®RACF®Redbooks (logo) ™Redbooks™Tivoli Enterprise™

Tivoli®VTAM®z/OS®

The following terms are trademarks of other companies:

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Internet Explorer, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Intel, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States, other countries, or both.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

vi IBM OMEGAMON z/OS Management Console

Preface

This IBM® Redpaper provides a description of the monitoring functions of the IBM OMEGMON z/OS® Management Console and provides an understanding of its integration with the other z/OS currently available functions.

The IBM Redpaper also covers the IBM OMEGMON z/OS Management Console customization and provides a sample on how you can provide additional customization and monitoring events that are specific to your installation.

The IBM Redpaper is based on a practical installation experience and it can be considered a complement to the standard IBM OMEGMON z/OS Management Console library. It is mainly focused on practical aspects and operations.

The team that wrote this IBM RedpaperThis IBM Redpaper was produced by a team of specialists from around the world working at the International Technical Support Organization, Poughkeepsie Center.

Sergio Bacci is a Senior Certified IT Specialist, working in IBM Italy since 1980. He started as a hardware engineer in 1980 and later, in 1983, as software support. Sergio has been working for 17 years in the IBM SW Support Center in Rome and his areas of expertise is Parallel Sysplex®, z/OS, z/OS performance and monitoring, and CICS®. Starting from 1997, Sergio has been supporting Telecom Italia for seven years and he is currently working with Banca Nazionale del Lavoro (BNL) where he supports the performance areas, Sysplex availability and products installation.

Curt Massie currently works as an IBM Advocate for Wachovia Bank. He has a total of 43 years of experience in the computer field, two years of which include working for IBM at STG, one and a half years include working as an IBM Advocate for Wachovia Bank, 11 years with Candle® Corporation, 13 years as an IBM Performance Management Analyst for mainframe computers and over 17 years in mainframe computers as a Field Engineer. Curtis authored and presented a white paper on Performance Management Analysis at the International Computer Measurement Group (CMG) Convention.

Thanks to the following people for their contributions to this project:

Paola Bari, Bob HaimowitzInternational Technical Support Organization, Poughkeepsie Center

Alice BlochIBM Software Group, Tivoli®

Bernice CaseyIBM Poughkeepsie

Michael RyanIBM Software Group, Tivoli

Samuel SantiagoIBM Software Group, Tivoli

© Copyright IBM Corp. 2007. All rights reserved. vii

Joe WintertonIBM Software Group, Tivoli

Become a published authorJoin us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You will team with IBM technical professionals, Business Partners and/or customers.

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and apply online at:

ibm.com/redbooks/residencies.html

Comments welcomeYour comments are important to us!

We want our papers to be as helpful as possible. Send us your comments about this IBM Redpaper or other IBM Redbooks™ in one of the following ways:

� Use the online Contact us review IBM Redbook form found at:

ibm.com/redbooks

� Send your comments in an e-mail to:

[email protected]

� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400

viii IBM OMEGAMON z/OS Management Console

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/residencies.html



http://www.redbooks.ibm.com/contacts.html

Chapter 1. Customizing IBM OMEGAMON z/OS Management Console

This chapter provides brief descriptions of IBM OMEGAMON® z/OS Management Console functionalities and then focuses on how to customize and use this product for a z/OS installation.

1

© Copyright IBM Corp. 2007. All rights reserved. 1

1.1 Overview

The OMEGAMON z/OS Management Console product is a member of the IBM Tivoli Monitoring Services family of mainframe monitoring products. It contains a subset of the availability and sysplex monitoring functions of the OMEGAMON XE on z/OS product. In addition, it uses IBM Health Checker for z/OS to monitor systems for potential problems, and also monitors IBM Health Checker for z/OS for problems. For example, the OMEGAMON z/OS Management Console displays the following types of z/OS data:

� Coupling facility policy information � Coupling facility systems data� Coupling facility structures data � Coupling facility paths data � XCF systems data � XCF paths data

The OMEGAMON z/OS Management Console can display IBM Health Checker for z/OS checks to help identify potential problems before they affect your availability, or, in worst cases, cause outages. IBM Health Checker for z/OS checks produce output in the form of detailed messages, which can be viewed in the OMEGAMON z/OS Management Console workspaces. If a check finds potential problems (exceptions), you can look at the detailed exception messages in OMEGAMON z/OS Management Console for information about the exceptions found and suggested actions to take. For complete information about setting up and managing IBM Health Checker for z/OS, see the IBM Health Checker for z/OS User’s Guide.

Like OMEGAMON XE, the new OMEGAMON z/OS Management Console product has a flexible, easy-to-use Java™-based interface called the Tivoli Enterprise™ Portal, which transforms systems data into the business knowledge that you can use to run your enterprise. With OMEGAMON z/OS Management Console, you can also set threshold levels and flags as desired to alert you when the systems reach critical points.

You can use OMEGAMON z/OS Management Console features to accomplish many system-management tasks:

� Monitor all systems and resources from a single integrated browser-based interface that you can customize with filters to display only the data that you want to see.

� Create comprehensive online reports about system conditions.

� Define your own queries, by using the attributes provided by a monitoring agent, to monitor conditions and data, and customize workspaces.

� Create situations, which let you set up monitoring for particular conditions and flag the condition with an alert when detected.

� Trace the causes leading up to an alert.

� Create and send commands to systems in your managed enterprise by means of the Take Action feature.

� Embed information about problem resolution in the product interface using Expert Advice, which can be edited to include knowledge and solutions specific to your environment.

1.2 Planning the configuration

The OMEGAMON z/OS Management Console consists of a client-server-agent implementation that uses the Tivoli Monitoring Services infrastructure. The Tivoli Monitoring

2 IBM OMEGAMON z/OS Management Console

Services infrastructure provides security, data transfer and storage, notification mechanisms, user interface presentation, and communication services for products in the IBM Tivoli Monitoring and OMEGAMON XE suites. Figure 1-1 illustrates the major components we use to build the ITSO configuration.

Figure 1-1 ITSO configuration

We used the following components:

� Tivoli Enterprise Monitoring Servers: HUB and REMOTE� OMEGAMON z/OS Management Console monitoring agent� Tivoli Enterprise Portal client and Tivoli Enterprise Portal Server

Figure 1-1 also illustrates the data flow configuration. When a request is generated for monitoring data from the Tivoli Enterprise Portal Server via an automatic interval update or an agent update request, or if someone expressly makes a request on the Tivoli Enterprise Portal Desktop or Browser, data flows from the OMEGAMON XE Monitoring Agent through the Tivoli Enterprise Monitoring Servers (HUB or REMOTE or both) to the portal server. The results are shown in the Tivoli Enterprise Portal Desktop or browser client.

1.2.1 Installation checklist

After completing the SMP/E installation of the OMEGAMON z/OS Management Console product, you must set up the Configuration Assistance Tool. The Configuration Assistance Tool is the ISPF application that is used to complete the OMEGAMON z/OS Management Console customization. Once the Configuration Assistance Tool is operating, you must layout the rest of your configuration procedure that will depend on the deployment configuration you have planned:

� The hub monitoring server running on a distributed system and the monitoring agent on z/OS

� The hub monitoring server and the monitoring agent running in the same address space

� The hub monitoring server and the monitoring agent running in separate address space

Tivoli Enterprise Portal Server

HubTivoli Enterprise

Monitoring Server

Remote Tivoli Enterprise Monitoring Server

Browser or Desktop

Tivoli Enterprise Portal z/OS

Omegamon z/OS Management ConsoleMonitoring Agents

Chapter 1. Customizing IBM OMEGAMON z/OS Management Console 3

For our ITSO configuration, summarized in Figure 1-2, we chose the third configuration option.

Figure 1-2 ITSO configuration

Our configuration shows the monitoring agent and hub that Tivoli Enterprise Monitoring Server installed on the same z/OS image but in separate address spaces. This configuration monitors availability and health checks on the z/OS system image where the product components are installed. You can add agents in the same monitoring agent address space or in separate address spaces. This configuration is a basic one that can be expanded easily to accommodate multiple systems.

To complete the installation, we performed the following steps:

1. Runtime environment definition: see “Runtime configuration options” on page 4

2. Runtime libraries building

3. Hub Tivoli Enterprise Monitoring Server configuration: see “Tivoli Enterprise Monitoring Server customization” on page 10

4. Monitoring agent configuration

5. Runtime libraries loading

6. Tivoli Enterprise Monitoring Server and the monitoring agent configuration

7. Tivoli Enterprise Portal Server and client installation on a Windows® workstation: see “Tivoli Enterprise Portal Server customization” on page 11

8. OMEGAMON z/OS Management Console application support installation

While the general guidelines for the execution of these steps can be found in the IBM OMEGAMON z/OS Management Console Planning, Installation, and Configuration Guide manual, here we report decisions that we made during our experience that we believe can be useful in planning and executing your installation.

Runtime configuration optionsAfter you determine which z/OS images must be monitored and decide whether to deploy the hub monitoring server and monitoring agent in the same address space, in separate address spaces, or on different systems, your next choice is deciding what types of runtime environments to use to configure the components you plan to deploy on your z/OS images. A runtime environment is a logical grouping of runtime libraries that are referenced by started

TivoliEnterpriseMonitoring

Server

Address space

MonitoringAgent

Address space

z/OS Image

TivoliEnterprise

PortalServer

Client

Tivoli Enterprise Portal


tasks as they run on a z/OS image. When you run the Configuration Assistance Tool to configure the OMEGAMON z/OS Management Console monitoring agent, you start this process by defining a runtime environment of a certain type, which determines the number and types of runtime libraries required. Table 1-1 summarizes the types of libraries created during installation and configuration of the OMEGAMON z/OS Management Console product.

Table 1-1 Libraries types

Before starting your installation, you must verify which option to configure the run time is best suited for your installation. In order to acquaint you with them, the following section provides the different configuration options you can use.

Libraries Types Description

Runtime libraries General term for libraries referenced by started task procedures. Includes SMP/E target, base, and LPAR-specific libraries.

SMP/E target libraries SMP/E maintained target libraries.

Base libraries Read-only runtime libraries that the configuration process does not alter and that are shareable between systems. These libraries physically exist in a full or base runtime environment, or as SMP/E target libraries (if a runtime environment shares with SMP/E). The base libraries can contain the actual data sets maintained by SMP/E, or a copy of them. Use a clone or copy of the SMP/E installation libraries for a production environment.

LPAR-specific libraries Runtime libraries that are built during configuration to run on a specific LPAR. These libraries contain the unique elements required for a particular LPAR and cannot be shared among z/OS images.


Full self-contained environment With this option, the full runtime environment is self contained (see Figure 1-3): it contains both the base libraries and the LPAR specific libraries. It is useful for a customer who wishes to install products on only one LPAR. It has the advantage of being easy to set up.

Figure 1-3 Full self-contained runtime environment

Figure 1-4 illustrates this type of configuration when spanning multiple z/OS images. Each run time is self-contained and there is no sharing between images.

Figure 1-4 Full-runtime-environment on several systems

The full runtime environment (shown in Figure 1-4) is replicated on several systems with no sharing for the base libraries. The disadvantage with this configuration are maintenance tasks because maintenance has to be installed separately on each LPAR. This type of runtime environment is required if there is no shared DASD across systems.

System A

Full runtimeenvironment X

LPAR-specificlibraries

Baselibraries

System A System B System C



Baselibraries

Full runtimeenvironment Y


Baselibraries

Full runtimeenvironment Z


Baselibraries


Base runtime environmentThe base runtime environment, shown in Figure 1-5, is a configuration where more than one system shares both the base and runtime libraries. One disadvantage of this type of environment is that if one changes the configuration files, the same configuration change takes place for the Tivoli Enterprise Monitoring Servers and OMEGAMON Monitoring Agents that service all the LPARs. This configuration is only suitable for a configuration in which all of the LPARs have similar applications running on them. Also, the Tivoli OMEGAMON products running on each LPAR have to be the same. The advantage of this type of configuration is that when maintenance or configuration changes are made, it must be executed on only one base library or one base runtime environment or both.

Figure 1-5 BASE Runtime environment

Sharing-with-base runtime environmentThe Sharing-with-base runtime environment (see Figure 1-6) requires shared DASD across all the LPARs in the configuration. It has the advantage of requiring a single copy for the base libraries. For this reason, there is a saving from a storage point of view and it also simplifies

Base runtime environment Q

Baselibraries


System D


maintenance since there is only one set of base libraries where maintenance requires to be applied.

Figure 1-6 Sharing-with-base runtime environment

Sharing-with-full runtime environment

Figure 1-7 is an example of sharing-with-full runtime environment. The sharing-with-full runtime environment allocates LPAR-specific libraries only, and obtains its base library information from a full runtime environment that contains the same combination of

System A

Sharingruntime

environment T


System B

Sharingruntime

environment U


System C

Sharingruntime

environment V


Base runtime environment QBaselibraries


OMEGAMON products.This configuration requires shared DASD. The sharing-with-base runtime environment is superior to this example because it is easier to maintain.

Figure 1-7 Sharing-with-full runtime environment

Sharing-with-SMP/E runtime environmentThe sharing-with-SMP/E runtime environment (see Figure 1-8) allocates LPAR-specific libraries only and obtains its base library information from target libraries managed by SMP/E. Note that the target SMP/E libraries must be copies (cloned) rather than the system libraries. Use the sharing-with-SMP/E configuration if at least one of the following statements is true:

� Space is limited on storage devices. This configuration method does not allocate base libraries in the runtime environment, thereby reducing storage requirements.




Baselibraries



Sharingruntime

environment Y

Sharingruntime

environment Z


� You want to activate SMP/E applied OMEGAMON product maintenance immediately.

Figure 1-8 Sharing-with-SMP/E runtime environment

After looking at the available options, we chose the sharing-with-base runtime environment. We decided this was the most advantageous environment for our configuration. Because the base libraries are shared, we had the advantage of only having to apply maintenance to the base library once. Additionally, because the library is shared, there are savings in storage resources.

Tivoli Enterprise Monitoring Server customizationOne instance of the Tivoli Enterprise Monitoring Server must also be installed and configured. OMEGAMON XE on z/OS and OMEGAMON XE for Storage on z/OS are the two OMEGAMON XE products that require the monitoring agent to be configured in the Tivoli Enterprise Monitoring Server address space.

In case of a single Tivoli Enterprise Monitoring Server instance, it is required to be a HUB. In case of a configuration with multiple systems, a single HUB instance might suffer performance if you choose not to install any REMOTE monitoring server because both local and remote agents are connected to the same HUB. Also, the single HUB can use an excessive amount of CPU resources under these circumstances. For these reasons, in all but limited configurations, we recommend that one must install multiple REMOTE monitoring servers, possibly one per z/OS image, on all images except where the HUB is installed.

For the purpose of our configuration, we installed one HUB and one REMOTE monitoring server.

The OMEGAMON z/OS Management Console agent can be run as a stand-alone address space, or it can share the Tivoli Enterprise Monitoring Server address space. It might be an advantage to run it in a shared address space for a customer who wishes to have a minimum amount of address spaces running on their system. However, to simplify troubleshooting problems that involve either the Tivoli Enterprise Monitoring Server or the OMEGAMON z/OS Management Console, or both, we recommend separate address spaces. We chose separate address spaces for our configuration.

System A


Sharingruntime

environment X

System B


Sharingruntime

environment Y

System C


Sharingruntime

environment Z

System D

Cloned copy of theSMP/E target libraries,including base libraries


Tivoli Enterprise Portal Server customizationThe OMEGAMON z/OS Management Console configuration requires at least one Tivoli Enterprise Portal Server for each Tivoli Enterprise Monitoring Server HUB. Tivoli Enterprise Portal Server can be installed on Windows, Linux® for Intel®, 31-bit Linux on z/OS or AIX® systems. In any OMEGAMON z/OS Management Console configuration, one must install at least one Tivoli Enterprise Portal Client on either Windows, or Linux. The Tivoli Enterprise Portal is used to facilitate configuration of the Tivoli Enterprise Portal Server. Other users can either install a Tivoli Enterprise Portal, or use an Internet Explorer® Client to access OMEGAMON z/OS Management Console.

For our configuration, we chose to install one Tivoli Enterprise Portal desktop client on a Windows system and we used the browser client on four other Windows systems. The advantage of using Internet Explorer to access the OMEGAMON z/OS Management Console is that if maintenance must be installed on the Tivoli Enterprise Portal, these users are exempt from the Tivoli Enterprise Portal maintenance update. On the other hand, if one chooses to install a Tivoli Enterprise Portal for each user, each of the Tivoli Enterprise Portals must be updated. One advantage of using the Tivoli Enterprise Portal is that it gives a slight performance advantage compared to the Internet Explorer Client.

1.2.2 Data Warehousing considerations

Our configuration did not include the Data Warehousing option. If you plan to use this feature, you also must install OMEGAMON XE for z/OS.

1.3 ITSO configuration considerations

These sections summarize considerations, which we have been making while running our customization, that might be helpful for your installation.

The ITSO configuration was based on two z/OS LPARs with shared DASD. We used a Windows system for the Tivoli Enterprise Portal Server and Tivoli Enterprise Portal Client.

1.3.1 Runtime configuration

Before starting to customize the run time, we must mention a few words about the decisions taken and the names in the convention adopted to make you have a better understanding of our environment. When we defined our base and sharing runtime environments, we decided to use the following name for the base one and for the sharing environments. For a full explanation about the runtime environment and the variables mentioned below, see chapter 2 in IBM OMEGAMON z\OS Management Console Planning, Installation, and Configuration Guide.


Figure 1-9 shows the definitions used to build the ITSO environment.

Figure 1-9 Runtime environments

The base runtime environment containing the common data for all partitions is called BASE1 and it contains either the DASD or the SMS definitions. For this run time, we recommend a generic name that can include the maintenance level or the environment. For the sharing run time, we suggest a name that helps identifying the target environment.

For each run time, you must also specify additional information that describes the environment. For example, Figure 1-10 shows additional information tailored to the base runtime.

Figure 1-10 Base RTE Definitions

In our configuration, we chose OMEGACON as the value for the first level qualifier (&rhilev) and BASE for the mid level qualifier (&rte). Table 1-2 describes the meaning for the different qualifiers.

Table 1-2 Variables description

Type of Library Description

Base librariesAbbreviated &rhilev or &rhilev.&rte.

Read-only runtime libraries that the configuration process does not alter and that are sharable between systems. These libraries physically exist in a full or base runtime environment.

LPAR specific librariesAbbreviated &rhilev.&rte.

Runtime libraries that are built during configuration to run on a specific LPAR. These libraries contain the unique elements required for a particular LPAR and cannot be shared among z/OS images.


As a result of our customization, the allocation task for the runtime environment BASE libraries allocated the set of libraries, which is shown in Figure 1-11.

Figure 1-11 Data sets for the BASE runtime environment.

After the base environment definition, we defined the sharing environments, one for each LPAR. This definition contains only the parameters distinctive for one LPAR as shown in Figure 1-12 and Figure 1-13 for SC63.

Figure 1-12 Sharing runtime environment: first panel

Continuing with the sharing environment definition, as shown in Figure 1-13, you can also use the z/OS system variables and use the definition used in the IEASYM parmlib member related to the LPAR values to solve these definitions. As you can see at this level, we defined the Tivoli Enterprise Monitoring Server name (and not the startup procedure name) that will be defined in the Tivoli Enterprise Monitoring Server descriptive definition later. At this time


you must also provide the TCP/IP descriptive definition about your LPAR environment like host name, address, TCP/IP started task name (leave the *) and the default port number.

Figure 1-13 Sharing runtime environment: second panel

The sharing environment data set names that are descriptive for one LPAR. For example SC64 is shown in Figure 1-14: as you can see, the first level qualifier (&rhilev) and (&rte) mid

Attention: Tivoli Enterprise Portal Server configuration: you must carefully complete the KCIPRTV1 panel shown in Figure 1-13. Remember that you defined the Tivoli Enterprise Monitoring Server name here and you must remember the HUB monitoring server name, the host name, the TCP/IP address and the port number. If you change this value from the default, when you install the Tivoli Enterprise Portal Server you must use the previous defined information to perform a correct customization. Remember (and write down) that the portal server requires the HUB monitoring server name (SC63TEMS) and not the HUB monitoring server procedure name (OM63HCMS). This can be a source of confusion and can generate some trouble during the configuration of the portal server and during SITUATION creation.


level qualifier have been substituted by OMEGACON and SC64. The same configuration applies to the SC63 sharing environment.

Figure 1-14 Sharing runtime environment for SC64

Figure 1-15 summarizes our ITSO configuration for the OMEGAMON z/OS Management Console environment with the set of libraries used for the BASE and for both of the SHARING environments:

� One set for base runtime environment, whose data set name starts with OMEGACON.BASE.xxxxxxxx

� One set for SHARING runtime environment for LPAR SC64, where the data set name starts with OMEGACON.SC64.xxxxxxxx.


� One set for SHARING runtime environment for LPAR SC63, where the data set name starts with OMEGACON.SC63.xxxxxxxx.

Figure 1-15 Our environment configuration

We decided to call every sharing environment with the LPAR name that it is referring to, this way it is impossible to get confused. Figure 1-15 illustrates the z/OS environment used to implement the OMEGAMON z/OS Management Console.

1.3.2 Tivoli Enterprise Monitoring Server customization

In our environment we decided to have two separated address spaces, one for Tivoli Enterprise Monitoring Server and one for OMEGAMON z/OS Management Console agent. This environment is similar on both LPARs. The first defined Tivoli Enterprise Monitoring Server is the HUB monitoring server. You can define only one HUB monitoring server in your installation, for example, for our SYSPLEX we put our HUB on system SC63 shown in Figure 1-16. The other monitoring server on SC64, connected with the HUB monitoring server, must be defined as REMOTE. You can have more than one REMOTE monitoring

The z/OS environment

SC63 SC64

OMEGACON.BASE.RKANCLI OMEGACON.BASE.RKANDATROMEGACON.BASE.RKANEXECOMEGACON.BASE.RKANHENUOMEGACON.BASE.RKANISPOMEGACON.BASE.RKANMOD OMEGACON.BASE.RKANMODLOMEGACON.BASE.RKANPENUOMEGACON.BASE.RKANSAMV OMEGACON.BASE.RKANSAS OMEGACON.BASE.RKANSQL OMEGACON.BASE.RKNSLOCL

SBOX0E

OMEGACON.SC64.RKANCMD OMEGACON.SC64.RKANCMDU OMEGACON.SC64.RKANDATV OMEGACON.SC64.RKANMODU OMEGACON.SC64.RKANPAR OMEGACON.SC64.RKANPARUOMEGACON.SC64.RKANSAM OMEGACON.SC64.RKANSAMU OMEGACON.SC64.RKANSQLU OMEGACON.SC64.RKDSACTP OMEGACON.SC64.RKDSACTP.DATA OMEGACON.SC64.RKDSACTP.INDEX OMEGACON.SC64.RKDSAGGR OMEGACON.SC64.RKDSAGGR.DATA OMEGACON.SC64.RKDSAGGR.INDEXOMEGACON.SC64.RKDSCATC OMEGACON.SC64.RKDSCATC.DATA OMEGACON.SC64.RKDSCATC.INDEX OMEGACON.SC64.RKDSCCT OMEGACON.SC64.RKDSCCT.DATA OMEGACON.SC64.RKDSCCT.INDEX OMEGACON.SC64.RKDSCKPT OMEGACON.SC64.RKDSCKPT.DATA OMEGACON.SC64.RKDSCKPT.INDEX

OMEGACON.SC63.RKANCMD OMEGACON.SC63.RKANCMDU OMEGACON.SC63.RKANDATV OMEGACON.SC63.RKANMODU OMEGACON.SC63.RKANPAR OMEGACON.SC63.RKANPARUOMEGACON.SC63.RKANSAM OMEGACON.SC63.RKANSAMU OMEGACON.SC63.RKANSQLU OMEGACON.SC63.RKDSACTP OMEGACON.SC63.RKDSACTP.DATA OMEGACON.SC63.RKDSACTP.INDEX OMEGACON.SC63.RKDSAGGR OMEGACON.SC63.RKDSAGGR.DATA OMEGACON.SC63.RKDSAGGR.INDEXOMEGACON.SC63.RKDSCATC OMEGACON.SC63.RKDSCATC.DATA OMEGACON.SC63.RKDSCATC.INDEX OMEGACON.SC63.RKDSCCT OMEGACON.SC63.RKDSCCT.DATA OMEGACON.SC63.RKDSCCT.INDEX OMEGACON.SC63.RKDSCKPT OMEGACON.SC63.RKDSCKPT.DATA OMEGACON.SC63.RKDSCKPT.INDEX

HUB TEMS PROC NAME :OM63HCMS

HUB TEMS NAME:SC63TEMS

TEMS PROC NAME :OM64RCMS

HUB TEMS NAME:SC64TEMS

Console Agent PROC NAME :OM63MC

Hostname : WTSC63IP Address : 9.12.6.70

Console Agent PROC NAME :OM64MC

Hostname : WTSC64IP Address : 9.12.6.9

BASE RUN TIME ENVIRONMENT : BASE1

SHARING RUN TIME ENVIRONMENT : SC63 SHARING RUN TIME ENVIRONMENT : SC64

&rhilev &rhilev

&rhilev

mid level qualifier

mid level qualifier

mid level qualifier

LOGICAL PARTITION NAMES


server in your environment, one for each z/OS image. One remote monitoring server for each z/OS image is the maximum but is not required.

Figure 1-16 ITSO Tivoli Enterprise Monitoring Server configuration

As you can see, we defined only one HUB Tivoli Enterprise Monitoring Server, which is on system SC63. The others must be defined with the REMOTE attribute.

You must configure and build the runtime environment as a whole before you can configure the monitoring server and monitoring agent in the runtime environment.

To start the Tivoli Enterprise Monitoring Server customization, select the option Select product to configure from the Configure Product panel. This takes you to the Product selection Menu panel that lists IBM Tivoli Monitoring Services and the OMEGAMON z/OS Management Console (shown in Figure 1-17).

Figure 1-17 Product Selection Menu

IBM Tivoli Monitoring Services must only be selected from this menu if the Tivoli Enterprise Monitoring Server is a standalone monitoring server (without a monitoring agent on the same LPAR). Otherwise, you select OMEGAMON z/OS Management Console, and then select the Tivoli Enterprise Monitoring Server from this menu, as shown in Figure 1-18 with the initial panel of the Tivoli Enterprise Monitoring Server customization.

---------------------------- PRODUCT SELECTION MENU ------------------ COMMAND ===> Actions: S Select product IBM OMEGAMON z/OS Management Console V4.1.0

IBM Tivoli Monitoring Services on z/OS V6.1.0


From this panel, you select the Tivoli Enterprise Monitoring Server (option 1), and later the OMEGAMON z/OS Management Console (option 2). You must perform these activities for each defined sharing runtime environment, in our environments: SC63 and SC64.

Figure 1-18 Product component selection menu

Once you have selected the Tivoli Enterprise Monitoring Server customization, you must obtain the panel shown in Figure 1-20 with all the required steps to customize the Tivoli Enterprise Monitoring Server environment. Figure 1-19 shows the Tivoli Enterprise Monitoring Server for SC64 LPAR but this step is required for both Tivoli Enterprise Monitoring Servers in both LPARs.

Figure 1-19 Tivoli Enterprise Monitoring Server definitions steps for SC64

Note: For a complete description of the Tivoli Enterprise Monitoring Server customization steps, see IBM OMEGAMON z/OS Management Console Planning, Installation and Configuration Guide.


1.3.3 OMEGAMON z/OS Management Console agent customization

The following steps described in Figure 1-20 are referring to the OMEGAMON Management Console agent customization. Remember we have one agent on one LPAR. The following steps are used to build the agent for the sharing environment.

Figure 1-20 OMEGAMON z/OS Management Console agent definition

1.3.4 Start up procedure naming convention

During the definition of the procedure names for the Tivoli Enterprise Monitoring Server and the agent, we adopted a naming convention that allows us to understand the component from this procedure name and in which system it is running.

The Tivoli Enterprise Monitoring Server procedure names are OM63HCMS and OM64RCMS where:

� OM stands for OMEGAMON.

� The value 63 or 64 refers to the distinctive partition where the procedures are running.

� The value H (HUB) or R (REMOTE monitoring server) refers to the Tivoli Enterprise Monitoring Server. Remember that in every installation you can have just one HUB Tivoli Enterprise Monitoring Server, and all of the others must be REMOTE.

� The CMS represents the Tivoli Enterprise Monitoring Server. We cannot use the full name Tivoli Enterprise Monitoring Server because it causes the procedure name to be too long.

The OMEGAMON z/OS Management Console agent procedure names are OM63MC and OM64MC, where:

� OM stands for OMEGAMON.� The value 63 or 64 refers to the distinctive partition where the procedures are running.� MC refers to OMEGAMON z/OS Management Console agent.

1.3.5 WLM recommendation for z/OS Management Console execution

Both the procedures, referring to the Tivoli Enterprise Monitoring Server and the z/OS Management Console agent, require the SYSSTC Service Class definition because they monitor the system activity. You can define your own reporting class for accounting scope.


1.4 Security

When you log on to the Tivoli Enterprise Portal Client, the portal client authenticates the User Identifier (USERID) by comparing it against a table that contains all approved USERIDs. The USERID is then sent to the Tivoli Enterprise Monitoring Server where the USERID must be authenticated by either Resource Access Control Facility (RACF®), or equivalent products.

The security package must be defined to the Tivoli Enterprise Monitoring Server during configuration and creation of the runtime environments. In the Tivoli Enterprise Portal, USERIDS are defined by a person who has system administration authority. The first time during the Tivoli Enterprise Portal customization, you must use the System Administration Identifier (SYSADMIN) to log on to the Tivoli Enterprise Portal. Once logged on with SYSADMIN, the system administrator can then define USERIDS and authorities in the portal client. This provides a great granularity. For instance, to log onto the portal client, you are required to have a valid USERID on the monitored systems. If the portal client system administrator has given you view only authority, you are only able to monitor the subject systems, you are not allowed to make any changes to the portal client monitoring controls.

1.4.1 Customization hints and tips

During the ITSO customization of the IBM OMEGAMON z/OS Management Console Version 4.1.0 we ran into a few hindrances. The following is a list to identify them for future reference:

� One problem we ran into was with regard to the procedure of configuring the Tivoli Enterprise Monitoring Server for Simple Object Access Protocol (SOAP). We were using the IBM Configuration Assistance Tool on the KDS61PPD panel with the following field “Access TEMS list via SOAP Server?”

The IBM Tivoli OMEGAMON z/OS Management Console Planning, Installation, and Configuration Guide, GC32-1954-00 provides the following instructions for this field: “Accept the default value of Y. The Web Services SOAP Server is required to be enabled for a hub monitoring server, even though the OMEGAMON z/OS Management Console product does not use the SOAP Server. Press F1 for information about the SOAP Server.”

In our configuration, we did not see a default value of Y for the Web Services SOAP server, we saw N as the default and we attempted to configure it to Y. When we returned to this panel later, N was still shown. The following is the explanation on how to handle this definition: This process works as per its design. The SOAP Server configuration is not something an installation would want to navigate to as part of the normal Tivoli Enterprise Monitoring Server configuration. Once the local Hub Tivoli Enterprise Monitoring Server is part of the SOAP Server table, then defaults are automatically used for the local SOAP Server (using the same port number, protocol, Tivoli Enterprise Monitoring Server name, and so on) enough to generate the KSHXHUBS member in the RKANPARU library. If the initial KSHXHUBS member has been created and no further configuration changes are required to the SOAP Server values, you can set this field to N. Also, you can tell if the SOAP Server is enabled/configured by checking in the KDSENV member of RKANPARU to see if KSH_DIRECTORY=RKANDATV and KSHCMS.WEBSQL;\ are in the KDS_RUN statement. SOAP Server support is only applicable to a Hub Tivoli Enterprise Monitoring Server.

� This item is with regard to a problem we had while attempting to complete the configuration of the Tivoli Enterprise Monitoring Server and the monitoring agent when attempting to work with panel KCIMRTU and one of our shared environments. For details, see IBM Tivoli OMEGAMON z/OS Management Console Planning, Installation, and Configuration Guide, GC32-1954-00, under heading “Step 6. Complete the configuration of the Tivoli Enterprise Monitoring Server and the monitoring agent”: “On the RTE Utility Menu, enter 6 to display the Generate sample system procedure copy JCL.”


After we completed this step, we attempted to perform step 7 described in step 2c. Instead of going to the panel, which displayed the job control language (JCL) that creates member KCISYNJB in the RKAMSAMU library, we got the message System copy unavailable at the top right corner of panel KCIMRTU. The VTAMLST system copy function is not available when the z/OS system variable support is enabled was displayed in a box in the middle of the panel. If this problem occurs in your installation, we suggest you manually set up a batch job to copy the VTAM® definitions from the RKANSAMU library to VTAMLST.

� The first time we configured the Tivoli Enterprise Portal Server and attempted to log onto it, we received the error message KFWITM257E. The problem was solved by adding USE_EGG1_FLAG=1 to the portal server. USE_EGG1_FLAG=1 is only required if you have not configured the ICSF runtime library for use in cryptographic processing and this depends on the hardware configuration. Setting this flag disables that level of security and directs the portal server to use a different encryption algorithm acceptable to a Tivoli Enterprise Monitoring Server running without the ICSF library.

If you are required to set up this flag, you can right click the portal server from the Manage Tivoli Monitoring Service window, select Advanced and select Edit ENV File to open the Tivoli Enterprise Portal Server environment parameters file. You must then add the bottom line USE_EGG1_FLAG=1. The Tivoli Enterprise Portal Server must then be stopped and restarted.



Chapter 2. Using the OMEGAMON z/OS Management Console

This chapter provides an overview on how to connect to the OMEGAMON for z/OS Management Console and how the monitored resources are organized.

It provides a description of the default monitored resources and provides a sample process to add new events that are tailored to your installation.

2


2.1 Terminology

Before using the Tivoli Enterprise Monitoring Server, we discuss some definitions that are used in this product.

NavigatorThe Navigator view is shown on the left side of the panel and shows the hierarchy of your monitored enterprise, from the top level (Enterprise) down to individual groupings of information collected by the monitoring agents. When you click on an item in the Navigator, its default workspace displays in the application window on the right side of the panel. See Figure 2-9 on page 31 to have a view of the Navigator (physical view). The Tivoli Enterprise Portal Navigator provides a physical view of your monitored enterprise. Under the nodes that represent the monitoring agents, you can find a list of workspaces for the data collected by each agent.

WorkspacesA workspace is the work area of the Tivoli Enterprise Portal application window and is made up of one or more views. A view is a pane in the workspace (typically a chart, graph, or table) showing data collected by a monitoring agent as shown in Figure 2-9 on page 31. As you select items in the Navigator, each workspace presents views relevant to your selection. Every workspace has at least one view, and every view has a set of properties associated with it. You can customize the workspace by working in the Properties Editor to change the style and content of each view. You can also change, add, and delete views on a workspace. Tivoli Enterprise Portal can present data in the following types of graphical views:

� Table view� Pie chart view� Bar chart view� Plot chart view� Circular gauge view� Linear gauge view

Additional functions are provided in the following Tivoli Enterprise Portal views:

� Notepad view� Message log view: showing the status of the situations associated with the system� Take Action view: used to send a command to the monitored system� Terminal view: from which you can start a 3270 or 5250 work session� Browser view: from which you can open a browser to see HTML pages and Web sites� Take Action view: used to send a command to the system

The OMEGAMON z/OS Management Console provides a set of predefined workspaces that allow you to start monitoring your environment immediately. As you become more familiar with the product, you can modify the predefined workspaces or create new workspaces.

Situations and situation eventsA situation describes a condition, or set of conditions, that you set to determine whether a problem exists in one or more monitored systems and resources. A condition consists of an attribute, a value, and a comparison operator. The value of the attribute is compared with the value set for the condition to determine whether the condition is met. For example, the KHL_HealthChecker_Problems situation is TRUE when the value of the Health_Monitor_Status attribute is anything other than Active.

You can create complex situations that contain more than one condition, allowing you to compare attributes and values that represent characteristics of specific problems. When all


the conditions of a situation are met (the situation is triggered), a situation event is registered. The operator is alerted for situation events by indicator icons that are displayed in the Navigator. Operators can also be alerted by sound.

As you move up the Navigator hierarchy, as shown in Figure 2-9 on page 31, situation events are consolidated to show only the indicator with the highest severity level (Critical, followed by Warning, then Informational).

A situation can also include a Take Action command that runs when the situation is triggered. This allows you to automate a response to a specific system condition. In addition, each situation can include text describing the probable cause and expert advice allowing you to address and resolve problems quickly.

You can create or modify situations from the Tivoli Enterprise Portal user interface by using the Situation editor. From the Situation editor, you can specify situations to run at startup or you can start and stop situations manually. OMEGAMON z/OS Management Console provides a set of default situations to enable you to start monitoring your enterprise as soon as the product is installed. You can also use the Situation editor to create new situations to meet the requirements of your enterprise.

Investigating a situation eventWhen the conditions of a situation have been met, the situation evaluates TRUE, causing a situation event indicator to be displayed in the Navigator. You can investigate the cause of a situation event by opening its workspace. The situation event workspace shows two table views: one with the values of the attributes when the situation evaluated TRUE, and the other with the current values of the attributes. The event workspace also displays any expert advice written by the author of the situation, and a Take Action view that enables you to send a command to the z/OS system.

Predefined situations The predefined situations packaged with the OMEGAMON z/OS Management Console product are distributed when the Tivoli Enterprise Monitoring Server is seeded or initialized with application data. All the predefined situations are started automatically. This means that they are set to run on startup of the Tivoli Enterprise Monitoring Server. Figure 2-1 shows the complete situation list where situations starting with KHL are the predefined ones. To have an

Chapter 2. Using the OMEGAMON z/OS Management Console 25

extensive explanation about the predefined situations, see chapter 4 of IBM OMEGAMON z/OS Management Console User’s Guide.

Figure 2-1 KHL predefined situation

Predefined workspaces This section summarizes the views and types of information displayed in each predefined workspace provided with the OMEGAMON z/OS Management Console product. The list below shows the order and hierarchy of the predefined workspaces where you can see workspaces defined sysplex level and workspaces specific for a z/OS image.

� Sysplex-level z/OS Management Console node

– Coupling Facility Policy Data for Sysplex – Coupling Facility Systems Data for Sysplex– Coupling Facility Structures Data for Sysplex– Coupling Facility Paths Data for Sysplex – XCF Systems Data for Sysplex – XCF Paths Data for Sysplex

� System-level z/OS Management Console node

– AVAILABILITY node

• LPAR Cluster Data for z/OS• USS Address Spaces and Processes• Address Space Data for z/OS workspace• Operations Status Data for z/OS workspace• Paging Dataset Data for z/OS workspace


– HEALTHCHECK node

• Health Monitor Status workspace• Health Monitor Checks workspace

The following charts are an example of what information you can obtain on the sysplex level workspaces.

Coupling Facility Policy Data for SysplexThe Coupling Facility Policy Data for Sysplex workspace reports the status for the CFRM Policy active in the Sysplex as shown in Figure 2-2.

Figure 2-2 Coupling Facility Policy Data for Sysplex

Note: The system and Sysplex information provided by the OMEGAMON z/OS Management Console software is limited to selected z/OS system facilities and sysplex resources, and does not include performance data. Comprehensive performance data is provided by OMEGAMON XE on z/OS.


Coupling Facility Systems Data for Sysplex workspaceThe Coupling Facility Systems Data for Sysplex workspace reports status and storage information about the coupling facilities defined to the sysplex. This workspace displays data provided by the Coupling Facility Systems Availability attribute group as shown in Figure 2-3.

Figure 2-3 Coupling Facility Systems Data for Sysplex workspace

Coupling Facility Structures Data for Sysplex workspaceCoupling facilities provide communication among members of a sysplex, to coordinate locking and buffer pool information. The Coupling Facility Structures Data for Sysplex workspace reports usage and storage information for the coupling facility structures in the


sysplex. This workspace displays data provided by the Coupling Facility Structures Availability attribute group as shown in Figure 2-4.

Figure 2-4 Coupling Facility Structures Data for Sysplex workspace

Coupling Facility Paths Data for Sysplex workspace The Coupling Facility Paths Data for Sysplex workspace reports the status of channel paths between z/OS systems and coupling facilities in the sysplex. This workspace displays data provided by the Coupling Facility Paths Availability attribute group as shown in Figure 2-5.

Figure 2-5 Coupling Facility Paths Data for Sysplex workspace


XCF System Data for SysplexThe XCF System Data For Sysplex workspace reports the status for all the Sysplex Systems and the information from the XCF Couple Data Set as shown in Figure 2-6.

Figure 2-6 XCF Systems Data for Sysplex

2.2 Sample scenario

First of all, you must logon to the Tivoli Enterprise Portal Server distributed server. From your desktop, you can use the Internet Explorer browser by just entering the URL http://xxx.xxx.xxx.xxx:1920///cnp/kdh where xxx.xxx.xxx.xxx is the Tivoli Enterprise Portal Server server IP address. Firstly, you are asked to provide your ID and password to perform user authentication, as shown in Figure 2-7.

Figure 2-7 User authentication

After the logon is completed, the Tivoli Enterprise Portal workspace shown in Figure 2-8 is displayed. This is the main menu where you can initiate all the OMEGAMON z/OS Management functions. As you select items in the Navigator, the workspace presents views


pertinent to your selection. Each workspace has at least one view with a set of associated properties. You can customize the workspace by working in the Properties Editor to change the style and content of each view. You can resize views, add them to and remove them from workspaces, and change the types of view in a workspace.

Figure 2-8 Tivoli Enterprise Portal Server

Figure 2-9 is a detailed view of the Navigator tree: all the OMEGAMON z/OS Management Console nodes are represented, firstly your SYSPLEX environment and then each LPAR in your environment. There are two type of nodes at the system level: HEALTH CHECK and AVAILABILITY. You can also see that each entry where a critical event happened has been marked with a red bullet.

Figure 2-9 OMEGAMON z/OS Management Console nodes


From the main menu, you can also see that all the default situations have been started and you can see all the statistical data related to each event.

2.2.1 Adding a situation

Beside the default situations, you can always add a specific event to be monitored in your installation.The following is a sample sequence of how you can define a customized OMEGAMON z/OS Management Console Situation for your installation.

For example, we wanted to add a situation aiming to check if a structure is allocate and used from someone. This is a sysplex event and for this reason, our starting point is the sysplex node.

While moving the cursor over Coupling Facility Structure Data for Sysplex, you obtain a drop down menu as shown in Figure 2-10. Right-click on Situations.

Figure 2-10 OMEGAMON Management Console nodes


You must obtain the next panel: Situations for - Coupling Facility Structures Data for Sysplex editor, shown in Figure 2-11, with the current defined situations listed on the tree on the left side of the panel. On the right side of the panel, you can see the Situations editor assistance.

Figure 2-11 Situations for - Coupling Facility Structures Data for Sysplex editor

The Situation editor provides you with the main functions listed on the panel. You can initiate the editor function by clicking on the selection choice offered by the panel. Figure 2-12 lists the different choices you can have to handle situations. In our case, we selected the Create new Situation option.

Figure 2-12 Situations choices

By clicking Create new Situation, you obtain the Create Situation panel where you start the definition of the new situation by entering the name and a description. In our case, we called


our situation CHECK1 and we provided a short description about the situation activities as shown in Figure 2-13.

Figure 2-13 Create situation

By clicking OK, we start the detailed definition parameters through the multiple tabs showed in Figure 2-14. Once all the tags have been completed, the new situations are defined in the sysplex.

The first tab that we must complete is about the Formula: this tab is used to identify what is the triggering condition for this event, what is the sampling interval for the event, the criticality of the event and how the operations must be notified once the event occurs.


To define the triggering condition, you must click Add conditions.

Figure 2-14 Situation definition

Clicking Add conditions brings you to the Select condition panel where you must define the condition that you are required to monitor. As you can see in Figure 2-15, you must select the


Attribute Groups, in our case CF Structure Availability, and the Attribute Item, in our case Structure Status, where we chose the status that we would like to monitor.

Figure 2-15 Condition Type selection

After the correct attribute group and item has been selected, the Formula tab is shown again (Figure 2-16) and you are requested to define the remaining information:

� The status you want to monitor using the pull-down menu on the Structure Status field� The Sampling Interval, where the interval cannot be less than 30 seconds� If you want to play some sound at alert time

Important: This product can only check events that are within one defined time interval. It cannot check a status that changes quickly in a small interval of time.

For example, it is not possible to monitor the Rebuild status during the Rebuild command lifetime because it completes in a very short interval. It is only possible to detect if there is a problem associated with a structure rebuild when the Rebuild status lasts for a long time and can be monitored across a Sampling interval. For a detailed explanation about the attribute groups and attribute items, see IBM OMEGAMON z/OS Management Console User’s Guide.


Figure 2-16 Formula tab definition

The next definition is the Distribution tag, shown in Figure 2-17, where you must provide the environments where the new situation CHECK1 is distributed. The Assigned list shows the agents to which the situation is assigned and the Available Managed Systems shows the agents of the same type to which the situation can be distributed.

The Distribution tab (Figure 2-17) lists the agents to which the situation is distributed. When you open the Situation editor from the Navigator item menu, the default distribution for a new situation is to the managed systems assigned to that item.

Note: The situation tree partially dims the icon for a situation that has not been distributed.


If the managed system has multiple agents of this type, then distribution will be to all of the agents. For example, the type can be distributed to the Health Checker on each LPAR.

Figure 2-17 Distribution tag

You can provide some action in the Action tab (Figure 2-18), for example, a z/OS command, that is executed when the situation is triggered on the z/OS system. In our case, we issue the


z/OS command D XCF,STR,STRNM=ALL to verify the status of the structures in the coupling facility.

Figure 2-18 Action tab

Optionally, you can also define the Expert Advice and Until tabs. The Expert Advice tab can be used to enter information that is displayed when the event occurs and can be used by operations for debugging or diagnostic purposes. The Until tab provides information about how long you want this to be monitored.

After all the tabs have been defined, you can click Apply and all the changes are applied to the situation CHECK1 and by pressing OK the situation CHECK1 is started on the Sysplex environment. Figure 2-19 show the Enterprise Message LOG view where you can see that


the situation CHECK1 has been started and the situation was evaluated as TRUE and an event was opened. You can see that the event is opened in Figure 2-19.

Figure 2-19 Workspace with CHECK1 situation

If you scroll the mouse over Coupling Facility Structure Data for Sysplex, you get the pop-up window shown in Figure 2-20, where you can see all the situations active for this entry.

Figure 2-20 Pop-up window with the list of situations


You can also see information about the CHECK1 situation on the z/OS syslog for the Tivoli Enterprise Monitoring Server where we can see the following messages shown in Figure 2-21, in the STC syslog that confirms the situation is up and running.

Figure 2-21 Tivoli Enterprise Monitoring Server Joblog

When we defined the CHECK1 situation in the Action definition, we asked that the z/OS command D XCF,STR,STRNM=ALL be issued when the situation is TRUE. From the syslog shown in Figure 2-22, you can see the D XCF command issued by the STC28880, which is the Tivoli Enterprise Monitoring Server server running on our system.

Figure 2-22 z/OS syslog

KO46256 Situation definition CHECK1 created by *ENTERPRISE. KO41047 Situation CHECK1 distribution SANDBOX:zOS:ManagementConsole added. KO41046 Monitoring for enterprise situation CHECK1 started. KO41047 Situation CHECK1 distribution zOS:ManagementConsole:PLEXview added. KO41041 Enterprise situation CHECK1:SANDBOX:zOS:ManagementConsole is true. (0000-D8CA54C3:ko4sit.cpp,1270,"Situation::slice") Error : Sit CHECK1 : reflex emulation command returned 1136



Chapter 3. Integration with Health Checker

The z/OS Health Checker is integrated into the IBM OMEGAMON z/OS Management Console. This chapter shows you the integration between the two elements and how you can customize them to fit your installation.

3


3.1 Health Checker workspaces

There are two workspaces dedicated to the Health Checker, as shown in Figure 3-1 and Figure 3-2. There is a set of two workspaces for each LPAR in your z/OS OMEGAMON z/OS Management Console configuration. Health Checker is a z/OS monitoring tool that is provided for each z/OS system to monitor the well being of the system.

Figure 3-1 shows the Health Checker Monitor Status that can be used to determine how the Health Checker is performing and other information about its status.

The Health Checker Status workspace shows graphically, in the upper right corner, how many times certain check conditions have occurred. The various check conditions are shown in the bottom half of Figure 3-1 in a table.

Figure 3-1 Health Checker Monitor Status


Figure 3-2 shows the Health Checker Checks workspace. It shows graphically, in the upper right corner, how many times each check exception has been triggered. Each check condition is listed on the bottom half of Figure 3-2.

Figure 3-2 Health Checker Checks workspace

Chapter 3. Integration with Health Checker 45

For example, let us focus on the XCF_CF_CONNECTIVITY check. Clicking the link related to this check at the extreme left side provides you with a detailed explanation of this check, as shown in Figure 3-3.

Figure 3-3 shows the complete detailed explanation of the XCF_CF_CONNECTIVITY check. In our example, it provides us with the explanation that not all installed channels are online from our system to the coupling facility named DF1. It explains that only one channel path is used to communicate to coupling facility CF1. It also explains that this represents a single point of failure in the sysplex configuration and this can be a non-acceptable condition in a production environment.

Figure 3-3 Health Checker Check detail link

3.1.1 Adding customized situations

Beside the default situations provided by the Health Checker, you can define situations that are tailored to your installation and your operations. The following section is a sample on how to add a customized situation to your configuration.


Figure 3-4 shows the first step in creating customized situations. Right-click Health Monitor Checks on the tree on the upper left side and then click Situations in the drop down menu.

Figure 3-4 Beginning of the creation of situation XCF_CF_CONNECTIVITY


As shown in Figure 3-5, the next step is selecting the Create New Situation icon in the top left corner.

Figure 3-5 Create new situation


You are prompted with the panel shown in Figure 3-6, where you must enter the situation name and the description. To confirm, click OK.

Figure 3-6 Define situation name


The next step is to define the condition for the situation to occur. In our example, we select the Attribute Group “Health Checker Checks” and “Check Name” in the Attribute Item. See Figure 3-7.

Figure 3-7 Define situation attribute group

Figure 3-8 shows the definition panel for the new check. There are multiple tabs that represent all the different information, which is required to be entered, to complete the check definition. The following figures show an example of all the different tabs

Figure 3-8 also shows the first tab with the Formula information. After we entered the check name XCF_CF_CONNECTIVITY in the Check Name box, we also entered the Sampling Interval time. For this example, we chose to click on the critical wave box. This causes an audio wave file to play when this situation is triggered. You can get creative and even have your PC warn you when a critical problem occurs. Also, the lower right under “State” is where you can choose whether their situation must be shown as either “Critical” (Red), “Warning” (Yellow) or “Informational” (Blue) when it occurs.


The next action is to select the Distribution tab on the upper center of the panel.

Figure 3-8 Situation configuration

The next step is to specify where you want to distribute this event. In our case, we deploy this situation to the “SANDBOX:SC63:HEALTHCHECK” and “SANDBOX:SC64:HEALTHCHECK” managed systems. To accomplish this, you must select a Managed System from the upper right box labeled “Available Managed Systems” and then click on the arrow that points to the left to define the selection as Assigned. In our configuration we have two systems named SC63 and SC64, and therefore we had to repeat this process twice in order to include the situation for both systems. The next step deals with the “Expert Advice” tab.

Alternatively, instead of selecting each LPAR to distribute the situation, you can select MVS_HLTH in the managed systems list to distribute this situation to all nodes known to MVS_HLTH. By using MVS_HLTH, you can be sure the situation is distributed to each node as it comes online. Otherwise, if you add another LPAR to this Tivoli Enterprise Monitoring


Server, the situation must be modified to add this new node to the distribution list. This is unnecessary if you select the MVS_HLTH managed list instead. See Figure 3-9.

Figure 3-9 Situation distribution


The Text or Advice Location can be used to provide suggestions on how to react when this problems occurs. It can be a task or any type of instruction. Figure 3-10 illustrates that we entered a message into the Text or Advice Location box to advise operations, or to whomever sees this problem, what action they must take to resolve it. Next, we click the Action tab.

Figure 3-10 Situation advice

The purpose of the frame shown in Figure 3-11 is to allow one to “Take Action” from this situation. You can issue a system command if this can solve the problem or provide diagnostic information or you can also send a “Universal Message” to a console, for instance, to allow the installation to then capture it with an automation product and either notify someone, or have the automation handle it. Of course, if the first action taken has failed to solve the problem, one might not necessarily want it to continue indefinitely to issue the same commands. To control this, you can click on the Only take action on the first item box. You can also choose to execute the action at the agent or at the Tivoli Enterprise Monitoring Server by clicking on the appropriate box. In the box labeled If the situation stays active over multiple intervals you can choose to either take action at every interval, or to not take


action twice in a row (Wait until the situation goes false and then true again). The next step is to define information under the “Until” tab.

Figure 3-11 Situation automation


The purpose of the frame shown in Figure 3-12 is to control how long a situation must be fired. You can choose to have this situation continue to fire until another situation is true or until a defined interval expires. This is the last step in the definition of a situation. You must click OK to save and start this new situation. The next task is to verify if and how the situation triggers.

Figure 3-12 Situation - Until tab definition


Now that we have defined the XCF_CF_CONNECTIVITY, we can check on the console to verify when it occurs. In Figure 3-13, you can see that the situation “XCF_CF_CONNECTIVITY” is triggered by positioning the mouse cursor over the z/OS Management Control entry on the tree on the upper left side. The triggering of the event generated an audio beep as a result of our customization with the wave file in Figure 3-5 on page 48. Click on the “link” on the left side of XCF_CF_CONNECTIVITY to see additional details.

Figure 3-13 Situation triggered

Figure 3-14 shows the situation information obtained by clicking the link shown on the left side of the triggered situation. Check the two tables in the upper right side of this frame. The upper one gives a time stamp that shows when this situation was first triggered, along with other important information, such as the SMFID of the system where the failure occurred. The table just below this shows the last time this same situation was triggered. Notice that the


information we defined into the Expert Advice box in Figure 3-10 on page 53 is shown in the panel.

Figure 3-14 Situation information



Related publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this IBM Redpaper.

Other publicationsThese publications are also relevant as further information sources:

� IBM Health Checker for z/OS User’s Guide, SA22-7994-03

� IBM Tivoli OMEGAMON z/OS Management Console Planning, Installation, and Configuration Guide, GC32-1954-00

� IBM Tivoli OMEGAMON z/OS Management Console User’s Guide, GC32-1955-00

Online resourcesThese Web sites and URLs are also relevant as further information sources:

� Tivoli Software

http://www.ibm.com/software/tivoli/

How to get IBM RedbooksYou can search for, view, or download IBM Redbooks, IBM Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site:

ibm.com/redbooks

Help from IBMIBM Support and downloads

ibm.com/support

IBM Global Services

ibm.com/services




http://www.ibm.com/support/

http://www.ibm.com/support/

http://www.ibm.com/services/

http://www.ibm.com/services/

http://www.ibm.com/software/tivoli/


Index

Aagent customization 19

Bbase library 5

single copy 7

CCoupling Facility

Policy Data 26Structure Data 32

coupling facility 46structure 28

Ddetailed exception messages 2

IInstallation

checklist 3Internet Explorer

Browser 30

KKCIMRTU 20

top right corner 21

LLPAR-specific library 5

Mmonitoring agent 2, 24

OOMEGAMON XE

product 10suite 3

RRedbooks Web site 59

Contact us viiiruntime environment 11

base libraries 9

Ssituation editor 25SOAP

Tivoli Enterprise Monitoring Server 20

© Copyright IBM Corp. 2007. All rights reserved.

syslog 41Sysplex workspace 27–28

Coupling facility 28Coupling Facility Paths Data 29Coupling Facility Structures Data 28Coupling Facility Systems Data 28reports status 28reports usage 28

TTivoli Enterprise Monitoring Server 3, 24, 51

address space 10customization 16–17customization step 18descriptive definition 13environment 18Hub 11Joblog 41name 13OMEGAMON XE Monitoring Agent 3procedure name 19

Tivoli Enterprise Portal 3, 24application window 24client 3customization 20desktop 3desktop client 11maintenance update 11Navigator 24Server 3, 30user interface 25workspace 30

Tivoli Enterprise Portal Serverconfiguration 14customization 14environment parameter 21

WWLM recommendation 19

61


®

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.

For more information:ibm.com/redbooks

Redpaper


Provides installation options

Offers Health Checker integration

Provides sample scenarios

This IBM Redpaper provides a description of the monitoring functions of the IBM OMEGMON z/OS Management Console and provides an understanding of its integration with the other z/OS currently available functions.

The IBM Redpaper also covers the IBM OMEGMON z/OS Management Console customization and provides sample scenarios to show the benefits that an installation can gain by using it.

Back cover




Date post:	26-Jun-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

IBM OMEGAMON z/OS Management Console › redpapers › pdfs › redp4166.pdfviii IBM OMEGAMON z/OS...

Documents