Omxezos551 Planandconfig

IBM OMEGAMON for z/OS
5.5
Planning, Upgrading, and Configuration
IBM
SC27-4028-02
Note
Before using this information and the product it supports, read the information in “Notices” on page
59.
Edition notice
This edition applies to version 5, release 5, modification 0 of IBM OMEGAMON for z/OS (product number 5698-T01) and
to all subsequent releases and modifications until otherwise indicated in new editions.
© Copyright International Business Machines Corporation 2004, 2022.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with
IBM Corp.
Contents
Figures.................................................................................................................. v
Tables................................................................................................................. vii
Chapter 1. Planning............................................................................................... 1
Configuration prerequisites......................................................................................................................... 1
Software and hardware requirements................................................................................................... 1
Prerequisites for data collection and display........................................................................................ 2
Using RMF data collection......................................................................................................................4
Planning configuration of OMEGAMON for z/OS......................................................................................... 7
Defining Sysplexes..................................................................................................................................7
Designating the Sysplex and Plexview proxy.........................................................................................7
Defining an enqplex................................................................................................................................ 9
Planning historical data collection.............................................................................................................. 9
Configuring the historical data stores for OMEGAMON for z/OS.........................................................10
Determining DASD requirements for storing historical data...............................................................10
Historical data collection and reporting.............................................................................................. 10
Before you begin configuration................................................................................................................. 11
Chapter 2. Upgrading...........................................................................................13
Upgrading to the new release....................................................................................................................13
Configuring a high availability hub and converting a static hub to a remote............................................13
Enabling new features............................................................................................................................... 13
Performing a staged upgrade.................................................................................................................... 14
Chapter 3. Configuring......................................................................................... 17
Configuring OMEGAMON for z/OS ............................................................................................................ 17
Configuring OMEGAMON......................................................................................................................18
Completing the configuration.................................................................................................................... 21
Update the IEFSSNxx member of SYS1.PARMLIB.............................................................................. 22
Update the LINKLIST........................................................................................................................... 22
Add support for the SYSTCPD DDNAME in the started tasks..............................................................22
Copy started task procedures to your procedure library.................................................................... 23
Copy the VTAM definitions to your system VTAMLST..........................................................................23
Vary the VTAM major node active........................................................................................................ 23
APF-authorize the runtime load libraries............................................................................................ 23
Enable historical data store maintenance........................................................................................... 23
Copy CSFPRM00 into SYS1.PARMLIB..................................................................................................25
Add the KM5EXIT3 to the ICSF Configuration.....................................................................................25
Modify the ICSF subsystem JCL...........................................................................................................25
Authorize address spaces for UNIX System Services......................................................................... 25
Enable RMF data collection..................................................................................................................26
Configure historical data collection..................................................................................................... 29
Enable Warehouse agents on a z/OS hub monitoring server.............................................................. 29
Create situations to filter DASD device collection...............................................................................30
Set the PROJECTCPU control in the SYS1.PARMLIB IEAOPTxx member...........................................30
Install application and language support............................................................................................ 30
Enable security for Tivoli Enterprise Portal......................................................................................... 31
Authorize users to issue Take Action commands................................................................................31
iii
Recreate or replace z/OS Management Console situations................................................................38
Authorize users to access OMEGAMON for z/OS managed systems on the enhanced 3270 user
interface...........................................................................................................................................38
Securing OMEGAMON................................................................................................................................38
Securing OMEGAMON for MVS (Realtime collector)........................................................................... 39
Verifying the configuration.........................................................................................................................56
Support information............................................................................................ 57
iv
Figures
1. Deployment of OMEGAMON for z/OS in a multiplex environment...............................................................8
v
vi
Tables
1. Data prerequisites......................................................................................................................................... 2
2. Preconfiguration tasks................................................................................................................................ 11
3. Tasks to complete before configuring OMEGAMON for z/OS.....................................................................17
4. Choices of security facilities for implementing OMEGAMON security.......................................................40
5. Security exit routines for external command-level security...................................................................... 54
vii
viii
Chapter 1. Planning
Configuration prerequisites
The topics in this section cover the hardware and software requirements for OMEGAMON for z/OS, as well
as the prerequisites for the collection and display of certain types of data.
• “Software and hardware requirements” on page 1 summarizes the prerequisite software and the
supported operating systems and hardware.
• “Prerequisites for data collection and display” on page 2 summarizes the conditions that must be in
effect for certain types of data to be available.
• “Using RMF data collection” on page 4 provides an overview of the configuration tasks required to
enable use of data collected by z/OS® Resource Measurement Facility.
Software and hardware requirements

A complete list of the software and hardware prerequisites is provided in the IBM OMEGAMON for z/OS:
Program Directory.
The following sections provide an overview of these prerequisites:
• “Required software” on page 1
• “Supported operating systems” on page 1
• “Supported hardware” on page 2
Required software
OMEGAMON for z/OS requires Tivoli Management Services on z/OS V6.3.0 Fix Pack 6 or later.
If you are installing application support files from a DVD image or a fix pack, consult the readme.txt
file that is provided with the DVD or fix pack. This file details the minimum Tivoli Management Services
requirements that are associated with the installation media. If you are installing application support files
by using the self-describing agent feature your Tivoli Management Services server components must be
at V6.3.0 Fix Pack 6 or later.
For information about the hardware and software prerequisites for the distributed components of Tivoli
Management Services, see the the Installation and Configuration Guides in the IBM Tivoli Monitoring
documentation. For information about the software and hardware requirements for a monitoring server
on z/OS, see the Configure a Tivoli Enterprise Monitoring Server section in the IBM Tivoli OMEGAMON and
Tivoli Management Services on z/OS Shared Documentation.
To make sure that you have the latest version of all components, check for any fix packs that might
be available, go to the technote, Recommended Maintenance Service Levels (http://www-01.ibm.com/
support/docview.wss?uid=swg21290883).
Supported operating systems

LPARs on which OMEGAMON for z/OS monitoring agents are installed must be running z/OS version 2
release 1 or later.
For information about APARs (authorized program analysis reports) required, see the IBM OMEGAMON for
z/OS: Program Directory. For late-breaking information, see the Preventive Service Planning (PSP) bucket
for this monitoring agent.
© Copyright IBM Corp. 2004, 2022 1

Supported hardware
OMEGAMON for z/OS monitoring agents can be deployed on any hardware environment that supports
z/OS 2.1 or later.
Ensure that you have adequate disk space to accommodate the products you are installing. Before
installing your OMEGAMON products, review the disk space requirements and considerations for an
SMP/E installed environment, as documented in the IBM OMEGAMON for z/OS: Program Directory, to
make sure that sufficient storage is available.
Tip: During normal SMP/E processing, VSAM control interval and control area splits can occur. This causes
fragmentation, which can degrade SMP/E performance and space utilization. To reorganize the CSI, use
your site's approved utility and method for managing VSAM files.
Prerequisites for data collection and display

For an OMEGAMON for z/OS monitoring agent to collect certain types of data, the Tivoli Enterprise
Monitoring Server address space in which it is configured must be assigned a user ID and given the
appropriate authorization. In addition, some attributes or attribute groups collect and display data only if
specific conditions are met.
To monitor UNIX System Services, the Tivoli® Enterprise Monitoring Server must be identified to your
security authorization facility as a UNIX System Services user as described in “Authorize address spaces
for UNIX System Services” on page 25.
To monitor coupling facility, cross-system coupling facility, or lock data collected by RMF, the Tivoli
Enterprise Monitoring Server must have an RACF® ID and the ID must be authorized to generate
PassTickets, as described in “Enable RMF data collection” on page 26.
To collect RMF near-term history data, the Tivoli Enterprise Monitoring Server and OMEGAMON®
Subsystem must have an RACF ID and the ID must be authorized to generate PassTickets, as described
in “Enable RMF data collection” on page 26. For versions of OMEGAMON for z/OS earlier than Version
5.5 Fix Pack 6, the OMEGAMON for z/OS subsystem must also have an RACF ID, and the ID must be
authorized to generate PassTickets.
Table 1 on page 2 describes the additional prerequisites for collection and display of certain types of
data.
Table 1. Data prerequisites

Data is available for Only if
4 Hour MSUs attribute in the A defined capacity is used as a basis for pricing and the z/OS system
System CPU Utilization attributes is not running as a guest on z/VM®.
group
Channel Path attributes The Resource Measurement Facility (RMF) has been started.
Common Storage attributes The Common Storage Area Analyzer (CSA Analyzer) is started.
Note: The CSA Analyzer is shipped and installed with OMEGAMON
for z/OS. It is configured as part of the configuration of the
OMEGAMON realtime collector and is started as a separate started
task.
2 IBM OMEGAMON for z/OS: Planning, Upgrading, and Configuration

Table 1. Data prerequisites (continued)
Coupling facility and cross- • The following RMF components are activated:
system coupling facility (XCF)
data collected by the Resource – RMF Control Task (RMF)–one instance on each system
Measurement Facility (RMF) – RMF Monitor III Gatherer (RMFGAT)–one instance on each
Distributed Data Server (DDS) system
– RMF Distributed Data Server (GPMSERVE)–one instance per
Sysplex
• You have enabled RMF data collection as described in “Using RMF
data collection” on page 4.
Cryptographic attributes At least one IBM® cryptographic coprocessor is installed and

configured and the KM5EXIT3 exit is installed in the Integrated
Cryptographic Service Facility (ICSF).
Note: The KM5EXIT3 exit is shipped and installed with OMEGAMON
for z/OS. See “Add the KM5EXIT3 to the ICSF Configuration” on
page 25 for more information.
DASD MVS™ workspace and DASD RMF has been started.

MVS Devices attributes
GRS Ring Systems attributes The global resource serialization (GRS) complex is in ring mode.
(If the complex is in star mode, only the name, status, and ring
acceleration of each system are available.)
Health Check attributes IBM Health Checker for z/OS software be installed, configured, and
running.
HiperDispatch Management and HiperDispatch Management mode is On.
HiperDispatch Logical Processors
attributes
Integrated Facility for Either
Applications (IFA) on CP resource
• z/Series Application Assist Processors are configured on the
times at the address space and
systems, or
service class period level
• Java™ applications are started using a switch (-Xifa:force)
LPAR cluster attributes The z/OS system is not running as a guest on z/VM.
Model Permanent Capacity ID System hardware is z10 or later.
and Rating and Model Temporary
ID and Rating
Chapter 1. Planning 3
Table 1. Data prerequisites (continued)
Near-term history data collected The following components are activated:
by the Resource Measurement
• OMEGAMON subsystem - for versions of OMEGAMON for z/OS
Facility (RMF) Distributed Data
earlier than Version 5.5 Fix Pack 6, at least one instance per
Server.
Sysplex (two for redundancy), up to one instance on each
monitored system
• RMF Control Task (RMF) - one instance on each monitored system
• RMF Monitor III Gatherer (RMFGAT) - one instance on each
monitored system
• RMF Distributed Data Server (GPMSERVE) - one instance per
Sysplex
You have enabled RMF data collection as described in “Using RMF
data collection” on page 4.
Promoted Percent The z/OS Workload Manager blocked workload capability is enabled.
Sysplex DASD attributes (Sysplex A DASD filter situation is enabled.
DASD Device, Sysplex DASD
Group, Sysplex DASD)
Suspend lock and spin lock data • The following RMF components activated:
– RMF Control Task (RMF)–one instance on each system
– RMF Monitor III Gatherer (RMFGAT)–one instance on each
system
– RMF Distributed Data Server (GPMSERVE)–one instance per
Sysplex
• You have enabled RMF data collection (see “Using RMF data
collection” on page 4).
• Lock data collection is enabled on RMF.
zAware data The Integrated Cryptographic Service Facility (ICSF) must be active
on the LPARs where OMEGAMON for z/OS agents run. This does not
require the Tivoli Enterprise Monitoring Server to be configured for
ICSF usage.
zFS attributes zFS is specified as the file system on the monitored system
(FILESYSTEM TYPE(ZFS) is specified in SYS1.PARMLIB(BPXPRMxx)).
Note: For z/OS V1.10, OMEGAMON for z/OS uses an address
space name of ZFS, unless the parameter KM3KZFSASNM=xxxxxxxx
(where xxxxxxxx is the started task (STC) name of the zFS address
space) has been added to the &rhilev.&rte.RKANPARU(KDSENV).
z/OS UNIX System Services The address space where the OMEGAMON for z/OS product is
attributes running has SUPER USER authority. This level of authority is
equivalent to root (UID=0).
Using RMF data collection

OMEGAMON for z/OS provides the capability to collect some real-time data and near-term history data
from the Resource Measurement Facility (RMF) Distributed Data Server (DDS). OMEGAMON for z/OS can
be configured to obtain real-time coupling facility (CF), cross-system coupling facility (XCF), and system
lock data from the RMF Distributed Data Server instead of collecting its own data. Using RMF data can

eliminate duplicate data collection and provide you with consistent metrics. It can also result in some
processor usage savings. RMF data is collected at a shorter monitoring interval than the corresponding
OMEGAMON for z/OS data.
Use of RMF for real-time data collection can be enabled as part of Sysplex configuration. There are four
options:
NO
The default. Disables RMF data collection. CF and XCF data is collected from the OMEGAMON
Subsystem.
ALL
CF, XCF, and lock data is collected from RMF.
CF/XCF
CF and XCF data is collected from RMF.
LOCK
Spin and suspend lock data is collected from RMF.
Use of RMF to collect near-term history data is enabled by default. You can disable near-term history data
collection from RMF by setting a parameter in the PARMGEN configuration profile. The OMEGAMON for
z/OS agents will discover the OMEGAMON Subsystem that has registered with a configured group name
using the z/OS Sysplex Routing Services.
Use of RMF data collection for both real-time data and near-term history data requires that the following
RMF components be activated:
• RMF Control Task (RMF)—one instance on each monitored system.
• RMF Monitor III Gatherer (RMFGAT)—one instance on each monitored system.
• RMF Distributed Data Server (GPMSERVE)—one instance per Sysplex.
Note: The RMF Distributed Data Server migrates to the system running the highest level of z/OS.
For near-term history data, an additional requirement is that at least one instance (two for redundancy
and up to one instance on each monitored system) of the OMEGAMON subsystem must be active per
Sysplex.
In addition, the following tasks must be completed:
• RACF IDs must be defined for the address spaces that are collecting RMF data.
Activation of the RMF Distributed Data Server API requires a RACF user ID and password. As its user ID,
OMEGAMON for z/OS agents and the OMEGAMON subsystem use the name shown in the SDSF Display
Active screen as the OWNER of the address space. This is often the started task name but does not have
to be. The user IDs of these address spaces must be defined to RACF. You will probably want to add
those IDs to a group to simplify PassTicket authorization (see later in this section).
• RACF secured signon PassTicket function for the DDS must be enabled.
Passwords specified during configuration would have to be held in a secure, encrypted format, and
many sites have default time limits on how long passwords are viable. Instead, OMEGAMON for z/OS
agents and the OMEGAMON subsystem use the RACF secured signon function. The secured signon
function provides an alternative to the RACF password called a PassTicket. PassTicket is a one-time-
only password that is generated by a requesting product or function. OMEGAMON for z/OS agents and
the OMEGAMON subsystem generate a PassTicket for a specific address space ID when it accesses the
RMF Distributed Data Server to obtain RMF data.
To enable OMEGAMON for z/OS agents and the OMEGAMON subsystem to use PassTicket, a RACF
administrator must enable the PTKTDATA class and authorize the address spaces.
Detailed instructions for completing these tasks are provided in “Enable RMF data collection” on page
26. See the z/OS Security Server RACF Security Administrator's Guide for a full discussion of PassTicket
function and setup.
Note: You can choose to bypass user ID and password authentication for the RMF Distributed Data server
API for all or selected users using initialization parameters. For further information, refer to discussion of
the HTTP_NOAUTH in the RMF documentation.
Near-term historical RMF data in Fix Pack 6 and later

In OMEGAMON for z/OS Version 5.5 Fix Pack 6 and later, the OMEGAMON for z/OS agent in the Tivoli
Enterprise Monitoring Server (TEMS) collects RMF data from RMF Monitor III, and then stores it in the
Persistent Data Store version 2 (PDS V2). For more information, see Configuring OMNIMON Base in the
IBM Tivoli OMEGAMON and Tivoli Management Services on z/OS Shared Documentation.
Configuration of near-term history collection must be performed individually for each report that was
previously automatically collected by the OMEGAMON subsystem. The following attribute groups for
near-term history collection are available in the Enhanced 3270 user interface History Configuration
workspace (Option V.H from the command line):
• Address Space CPU Utilization History
• Address Space CPU Summary History
• CPC LPAR Details History
• LPAR Summary History
• CPC LPAR Summary History
• WLM Service Class Resources History
• KM5 CPC Details
• KM5 CPC Summary
• PCIE Device Summary
• SCM Device Summary
• Common Storage Utilization History
• KM5 Storage Details History
• Real Storage Utilization History
• KM5 Storage Summary History
• KM5 Device Resource History
• WLM Class Sysplex Metrics
• ResGroup Plex Extended Metrics
The OMEGAMON subsystem does not cache RMF Monitor III near-term historical data, and it does not
connect to the RMF Distributed Data Server started task (GPMSERVE).
Near-term historical RMF data before Fix Pack 6

In versions of OMEGAMON for z/OS before Version 5.5 Fix Pack 6, use of RMF to collect near-term
history data is enabled by default. You can disable near-term history data collection from RMF by setting
the RTE_KM5_NTH parameter in the PARMGEN configuration profile. The OMEGAMON for z/OS agents
discover the OMEGAMON subsystem that has registered with a configured group name using the z/OS
Sysplex routing services.
For near-term history data, at least one instance (two for redundancy and up to one instance on each
monitored system) of the OMEGAMON subsystem must be active for each Sysplex.
Management of near-term history data collection

In a Sysplex before OMEGAMON for z/OS Version 5.5 Fix Pack 6, one OMEGAMON subsystem in each
group runs an RMF cache. Other OMEGAMON subsystems in the group are ready to start an RMF cache if
the active RMF cache is stopped. The group contains all the OMEGAMON subsystems that are configured
with the same group name. In Fix Pack 6 and later, the OMEGAMON for z/OS agents running in the Tivoli

Enterprise Monitoring Server (TEMS), and not the OMEGAMON subsystem, collect RMF data for history
collection.
You can identify the OMEGAMON subsystem in a group that is running an RMF cache by issuing a MODIFY
command to any OMEGAMON subsystem in the same group:
F stcname,NTHCACHE LOCATE
where stcname is the OMEGAMON subsystem started task name

You can stop the OMEGAMON subsystem address space with a STOP command:
P stcname
When you stop the OMEGAMON subsystem that is running an RMF cache, another OMEGAMON
subsystem in the group obtains an ENQ using the group name and starts a new RMF cache.
You might want to suspend near-term history data collection by the OMEGAMON subsystem that is
running an RMF cache. One reason would be when you need to restart one of the RMF components.
You can suspend near-term history data collection by issuing a MODIFY command to the OMEGAMON
subsystem running the RMF cache:
F stcname,NTHCACHE SUSPEND
After the RMF component or components are restarted, you resume near-term history collection by
issuing a MODIFY command to the OMEGAMON subsystem running the RMF cache:
F stcname,NTHCACHE RESUME
The OMEGAMON subsystem will restart near-term history data collection with the next time period after
data collection was suspended. If data collection was suspended longer than the configured range in
hours (parameter RTE_KCN_CACHE_KM5_NTH_RANGE), data collection is resumed to retrieve the data
for the configured range in hours (for example, the last 24 hours).
Planning configuration of OMEGAMON for z/OS

The topics in this section describe the Sysplex-level entities you will be defining during the configuration
process.
Defining Sysplexes
A Sysplex is a set of z/OS LPARS that share a common cross-system coupling facility (XCF) environment
and a single Sysplex clock. You define Sysplexes to OMEGAMON for z/OS, and then assign runtime
environments to them during the configuration process.
When you configure each monitoring agent, you have the option of defining its runtime environment as
single LPAR environment or as a Sysplex environment. If you define it as a Sysplex environment, you must
assign it to a defined Sysplex. Data from each runtime environment in a Sysplex is pooled at the primary
Sysplex proxy (see “Designating the Sysplex and Plexview proxy” on page 7).
Designating the Sysplex and Plexview proxy

The Sysplex proxy is a Tivoli Enterprise Monitoring Server (TEMS) that is a data consolidation point for
monitoring all LPARs in a Sysplex. Sysplex situations are evaluated at the Sysplex proxy, and historical
data for a Sysplex is collected there. There is one Sysplex proxy for each Sysplex. The Plexview proxy is
a Sysplex proxy that is a data consolidation point for all Sysplex monitoring. There is one Plexview proxy
that covers all Sysplexes.
Figure 1 shows the deployment of OMEGAMON for z/OS in a multi-Sysplex environment. It shows a
representation of the communication that is required by the PLEXVIEW and SYSPLEX proxies, but it does
not show all communication lines. The PLEXVIEW proxy might need to communicate with any Remote
TEMS, in any Sysplex. For information about the ports used in the communication between entities, see
"Port number assignments" and "Displaying Data Retrieval Agents (DRA) for a hub" in the OMEGAMON
shared documentation.
Figure 1. Deployment of OMEGAMON for z/OS in a multiplex environment
Each Sysplex has a primary proxy and several backup proxies to which the function migrates when the
primary proxy goes down or is taken offline. During the configuration of each runtime environment, assign
each to a Sysplex and specify whether or not the runtime environment should be eligible to act as the
Sysplex proxy. The first runtime environment to be assigned to the Sysplex is marked as the primary
proxy. Subsequent runtime environments are defined as backups, unless you exclude them from proxy
eligibility.
The only difference between a primary proxy and a backup proxy is that the primary proxy gets priority
in becoming the proxy if several are started at the same time. Otherwise, when a current Sysplex proxy
goes down or is taken offline, the next Sysplex proxy eligible Tivoli Enterprise Monitoring Server becomes
the Sysplex proxy regardless of primary or backup setting. It remains as the Sysplex proxy until this Tivoli
Enterprise Monitoring Server goes down or is taken offline.
One Sysplex has its Sysplex proxy designated as the Plexview proxy. Only a Tivoli Enterprise Monitoring
Server that is eligible to be a Sysplex proxy can become the Plexview proxy. It remains as the Plexview
proxy until this Tivoli Enterprise Monitoring Server goes down or is taken offline. For information
about how to make Tivoli Enterprise Monitoring Server eligible to be a Sysplex or Plexview proxy, see
KM5_SYSPLEX_PROXY_POSITION and KM5_PLEXVIEW.
The z/OS hub Tivoli Enterprise Monitoring Server, Sysplex proxy, and Plexview proxy are busy servers.
Therefore, it might be a good idea to make the hub not eligible to be a Sysplex proxy or a Plexview proxy;
however, this depends on the environment and maintenance protocols. You should also exclude LPARs
that are low priority or CPU-constrained from becoming the Plexview proxy. For more information, see
“Performing a staged upgrade” on page 14.
When a Sysplex proxy receives a query for Sysplex-level attribute groups, the Sysplex proxy gathers
the appropriate data by sending queries to the Remote Tivoli Monitoring Servers running on the LPARs
in the Sysplex. Similarly, when a Plexview proxy receives a query, the Plexview proxy gathers the
appropriate data by sending queries to the Sysplex proxies or system agents running in other Remote
Tivoli Monitoring Servers. Processing the queries and communicating between Remote Tivoli Monitoring
Servers is managed by components of Tivoli Management Services on z/OS.

Defining an enqplex
In configurations where enqueue management (using CA-Multi-Image Manager, or MIM) spans two or
more Sysplexes, OMEGAMON for z/OS provides data on conflicts between Sysplexes, using the concept
of an enqplex. An enqplex is a group of z/OS images under common enqueue management. Defining an
enqplex allows OMEGAMON for z/OS to correlate enqueue information for multiple Sysplexes and identify
conflicts.
During the process of configuring OMEGAMON for z/OS, you will be asked to perform the following tasks:
• Specify one or more enqplex names
• Assign each Sysplex to an enqplex
• Assign each runtime environment to a Sysplex
• List the MIM task names in the z/OS image in which you are configuring OMEGAMON for z/OS
If you do not specify an enqplex name, or do not assign a system (that is, a z/OS image) to an enqplex, it is
assigned to the $DEFAULT enqplex and is assumed to share resources and enqueue management.
Planning historical data collection

The Planning section in the IBM Tivoli OMEGAMON and Tivoli Management Services on z/OS Shared
Documentation details the planning decisions that you make when you configure historical data
collection. This information is intended to help you understand the configuration options that you are
presented with during the configuration of OMEGAMON for z/OS.
During the configuration process, you can configure the historical data stores in four sections of the
configuration profile member:
1. Run-Time Environment (parameters that start with "RTE_PDS_"): This profile section configures
persistent data store control member options, high-level qualifier, and default maintenance procedure
name.
2. Tivoli Enterprise Monitoring Server (parameters that start with "KDS_PD_"): This section configures
the generic persistent data store (RPDSGRP). You must configure the persistent data store when you
configure the Tivoli Enterprise Monitoring Server if you intend to collect historical data for OMEGAMON
for z/OS.
3. OMEGAMON for z/OS (parameters that start with "KM5_PDS_" and "KM5_PD"): This section configures
the dedicated, or private, data sets for OMEGAMON for z/OS RKM5LPR* and RKM5PLX* for the
groups LPARDATA and PLEXDATA. The PLEXDATA data sets are allocated only on the Tivoli Enterprise
Monitoring Server that is acting as the Sysplex proxy. The LPARDATA data sets are allocated on every
Tivoli Enterprise Monitoring Server. With Persistent Data Store version 2 (PDS V2), there is only one
set of PDS datasets for OMEGAMON for z/OS, named *.HM5nnnnn, that is allocated on every Tivoli
Enterprise Monitoring Server.
4. OMEGAMON subsystem options (that is, parameters that start with RTE_KM5_ and
RTE_KCN_CACHE_): This section configures OMEGAMON for z/OS Resource Measurement Facility
(RMF) cache parameters.
In versions of OMEGAMON for z/OS before Version 5.5 Fix Pack 6, the OMEGAMON subsystem
collected data from RMF, and then stored it in an in-memory cache for retrieval by OMEGAMON for
z/OS short-term history.
After installing OMEGAMON for z/OS Version 5.5 Fix Pack 6 or later, you might want to turn off the
OMEGAMON subsystem cache: to do this, set the RTE_KM5_NTH parameter to N or NO. For more
information, see Configuring OMNIMON Base in the IBM Tivoli OMEGAMON and Tivoli Management
Services on z/OS Shared Documentation.
Notes
• If you want the OMEGAMON for z/OS monitoring agent to collect real-time CF, XCF, and LOCK data from
RMF instead of collecting its own data, you must change the KM5_RMF_DDS_COLLECTION parameter.
For more information, see “Configuring the OMEGAMON for z/OS agent to use RMF data” on page 19.
• To collect historical data, you must configure and start historical data collection by using the Tivoli
Enterprise Portal or the Enhanced 3270 user interface. For more information, see Using historical data
collection and reporting.
Configuring the historical data stores for OMEGAMON for z/OS

All OMEGAMON products use dedicated, or private, data sets. In addition, some OMEGAMON products
use general, or generic, data sets, that is, data sets that can be shared by many products.
If you want to configure OMEGAMON for z/OS to collect historical data for display in the Tivoli Enterprise
Portal, you must configure both generic and private data stores. When you configure the persistent data
store during configuration of a Tivoli Enterprise Monitoring Server, you are configuring the generic data
sets. When you configure the persistent data store during configuration of OMEGAMON for z/OS, you are
configuring the private data sets.
Persistent data store version 1

With persistent data store version 1 (PDS V1), OMEGAMON for z/OS uses two groups of private data sets
for historical data: LPARDATA (the RKM5LPR* data sets) and PLEXDATA (RKM5PLX*). The PLEXDATA data
sets are allocated only on the Tivoli Enterprise Monitoring Server that is currently acting as the Sysplex
proxy. The LPARDATA data sets are allocated on every Tivoli Enterprise Monitoring Server.
For Sysplex-level data, the Tivoli Enterprise Monitoring Servers acting as the primary proxy and the
backup proxies share the same private data set (RKM5PLX*). During the configuration process, one
set of files is created and initialized on shared DASD for the Sysplex. At runtime, the Tivoli Enterprise
Monitoring Server that becomes the Sysplex proxy allocates these files to itself. If the Sysplex proxy
function migrates to a backup proxy system, that system dynamically allocates these same files. This way,
all the Sysplex level history data is collected in a single set of persistent data store files.
Only the runtime environment that acts as the primary proxy is allowed to configure the Sysplex-level files
in the persistent data store.
Persistent data store version 2

With persistent data store version 2 (PDS V2), OMEGAMON for z/OS uses a single group of private data
sets that are named *.HM5nnnnn.
For system-level data, each runtime environment allocates files in its own persistent data store.
Determining DASD requirements for storing historical data

The OMEGAMON for z/OS: Program Directory provides the basic space requirements for the Tivoli
Enterprise Monitoring Server, Tivoli Enterprise Portal, the Tivoli Enterprise Portal Server, and the
monitoring agents themselves. These basic space requirements do not include additional space that is
required for maintaining historical data files.
Because of the variations in client distributed systems, system size, number of managed systems, and
so on, it is difficult to provide actual additional disk space requirements necessary for historical data
collection. You need to experiment to determine how much space you need.
Use the default amounts to configure the data store initially, then observe how quickly space gets used.
Eventually, you want to allocate enough space so that maintenance procedures only need to run once a
day. Use the information in Disk space requirements for OMEGAMON for z/OS historical data tables to
help determine how much space you need to allocate.
Historical data collection and reporting

OMEGAMON for z/OS has several history collection and reporting options.
• Almost all real-time data displays can be configured for history collection that is saved in the Persistent
Datastore (PDS), and then the Tivoli Data Warehouse (TDW).

• All of the system-level workspaces can record history (except the Enqueue, Reserve, and Lock
Summary workspace; Cross-system workspace; and the Integrated Cryptographic Service Facility
(ICSF) workspace).
• All of the Sysplex-level workspaces can record history (except the Users Data for CF Structure
workspace; GRS Ring Systems Data for Sysplex workspace; and the Members Data for XCF Group
workspace). For more information, see Reporting historical data.
Viewing and exporting historical data

You can view the historical data in the Tivoli Enterprise Portal (TEP), or export it to a file for viewing or
processing. (There is no batch report option.)
When historical data collection is enabled for a workspace in the TEP, the history icon is displayed in the
upper left of the display.
• To select the range of data that you want to see, click the history icon.
• To export the data to a file in .csv or .txt format that you can use in programs such as Microsoft Excel,
right-click the data, and then click Export.
Attribute groups for RMF Near Term History

For OMEGAMON for z/OS, Near Term History (NTH) in the OMEGAMON enhanced 3270 user interface
(enhanced 3270UI) displays attribute groups collected from RMF. PDS data collection can be enabled for
these RMF Near Term History (RMF NTH) attribute groups so that they can also be viewed in the TEP. For a
list of the attribute groups, see RMF near-term history attribute groups.
OMEGAMON for z/OS includes queries for these attribute groups, but it does not include workspaces for
them. To view the data in the TEP, you must create a customized workspace that issues the applicable
query.
Note: The queries for these tables are designed to be used in the enhanced 3270UI; to show useful
information in the TEP, you might need to customize them.
Before you begin configuration

Before you begin to configure OMEGAMON for z/OS, complete the tasks listed in Table 2 on page 11:
Table 2. Preconfiguration tasks

Task Location of information
Complete any preinstallation requirements. Preinstallation Requirements and Instructions

at http://www.ibm.com/support/docview.wss?
uid=swg21318692
Verify that you have the required software and IBM OMEGAMON for z/OS: Program Directory
DASD
Install the product.
Read the planning information and make any Planning section in the IBM Tivoli OMEGAMON
necessary planning decisions. and Tivoli Management Services on z/OS Shared
Review information on batch processing and Documentation
system symbolics, so your first runtime
environment is appropriate for replication.
Set up the runtime environment and allocate
the runtime libraries.
Table 2. Preconfiguration tasks (continued)
Task Location of information
Configure the Tivoli Enterprise Monitoring Configuring a Tivoli Enterprise Monitoring Server
Server in the runtime environment. section in the IBM Tivoli OMEGAMON and
Tivoli Management Services on z/OS Shared
Documentation
Verify that no user-defined ICSF service call See note.

exits have been set up.
Note: OMEGAMON for z/OS monitors Integrated Cryptographic Service Facility (ICSF) subsystems by
hooking the standard service call exits defined by IBM. If those exits are customized, data collection
cannot occur.
If you need to define your own exits, use the ICSF security exits as alternatives to the two service call
exits, CSFEXIT3 and CSFEXIT4. If the monitoring agent discovers a user-defined exit that conflicts with
a OMEGAMON for z/OS performance-monitoring exit, it replaces the user-defined exit, issues a warning
message, and proceeds with data collection.
The OMEGAMON for z/OS exits use installation word 2 (CCVTINW2) in the Cryptographic
Communications Vector (CCVT) control block. Your exits must not change this value, or fatal errors will
occur in the monitoring agent. As an alternative, you can use installation word 1 (CCVTINW1), which is
not used by the OMEGAMON for z/OS exits and can be changed without affecting the monitoring agent.

Chapter 2. Reference
This section contains information you may need to refer to while you are configuring historical data
collection or securing the OMEGAMON for z/OS components.
Upgrading to the new release

In addition to the common upgrade requirements documented in the Upgrading section of theIBM
Tivoli OMEGAMON and Tivoli Management Services on z/OS Shared Documentation, there are several
requirements specific to OMEGAMON for z/OS.
You can upgrade directly from versions 5.1 and 5.3 (any fix pack level) to version 5.5.
Configuring a high availability hub and converting a static hub to a

remote
If you intend to enable the self describing agent (SDA) feature, and you have an agent configured in the
hub monitoring server address space, configure a high availability (HA) hub on the LPAR and convert the
static hub to a static remote monitoring server that connects to the new HA hub. In addition, you must
reconfigure all the remote monitoring servers that connected to the previous hub to connect to the new
HA hub.
For instructions on configuring an HA hub, see the Configure a Tivoli Enterprise Monitoring Server section
in the IBM Tivoli OMEGAMON and Tivoli Management Services on z/OS Shared Documentation.
To convert a static hub to a remote, you must make the following changes:
• Change TCP communication values for the monitoring server:
– The name or IP address of the hub
– The port of the HA hub
• Change the type of the local monitoring server type from hub to remote.
• Change the hub type that the remote connects to to HA.
• If the static hub was excluded from proxy eligibility, change it to proxy eligible.
• Set to virtual IP address type for connecting to the hub.
• Add TEMS network interface list support.
Complete scenario PGN04, Clone an existing environment and convert its hub monitoring server to a
remote, in the Scenarios and how-tos section in the IBM Tivoli OMEGAMON and Tivoli Management
Services on z/OS Shared Documentation.
Enabling new features

If you are upgrading from OMEGAMON XE on z/OS V5.1 or V5.3 to OMEGAMON for z/OS V5.5, you do not
need to reconfigure the Tivoli Enterprise Monitoring Server or the OMEGAMON for z/OS monitoring agents.
You can simply accept the defaults and build and load the runtime libraries for the runtime environment.
However, if you want to use the self describing agent (SDA) feature, you must enable SDA on the hub
monitoring server and specify the UNIX System Services directory from which the SDA packages will be
copied for each runtime environment in which an OMEGAMON for z/OS monitoring agent is running. If you
want to control access to OMEGAMON for z/OS managed systems from the OMEGAMON Enhanced 3270
user interface (enhanced 3270UI) or to use the new product-provided Take Action commands, you must
create resource profiles for the security class that controls them.
OMEGAMON for z/OS can now collect near-term history data from the Resource Measurement Facility
(RMF) Distributed Data Server (DDS). This is in addition to, and separate from, use of RMF DDS to
collect real-time coupling facility (CF), cross-system coupling facility (XCF) and system lock data. Read

“Configuring the OMEGAMON for z/OS agent to use RMF data” on page 19 and “Enable RMF data
collection” on page 26 to configure and enable collection of RMF near-term history data.
Enabling SDA
By default, support for self describing agents is disabled on the hub monitoring server. To use this feature,
you must enable it on the hub monitoring server and configure each runtime environment in which an
OMEGAMON for z/OS monitoring agent is running to support it. To enable SDA on the hub monitoring
server, see Configuring a Tivoli Enterprise Monitoring Server section in the IBM Tivoli OMEGAMON and
Tivoli Management Services on z/OS Shared Documentation.
Note: If you are upgrading and you are installing application support manually (that is, the self describing
feature is not enabled), you will see the following message during a Linux® or UNIX installation:
KCIIN2463W Warning: This installation media does not contain any components which can be run on
the current system platform architecture. To install components which can run on this system,
please locate the installation media containing files similar to <platform>.jar.
If you are installing application support, continue with the installation to see a list of
support files.
This message should be ignored. There are no longer any platform-specific components to install.
Securing OMEGAMON for z/OS managed systems and Take Action commands
The SAF security class specified for the runtime environment (RTE_SECURITY_CLASS) controls logon
access to the enhanced 3270UI. It also controls authorization to view data from managed systems
and attribute groups in the interface, and the authority to execute OMEGAMON for z/OS Take Action
commands from either the enhanced 3270UI or the Tivoli Enterprise Portal interface.
For security to be enforced, resource profiles must be defined to the class. If a matching SAF profile does
not exist to protect queries (data collection) from a particular OMEGAMON for z/OS managed system or
attribute group, all user IDs are allowed to issue the queries. To create resource profiles that restrict
access to OMEGAMON for z/OS managed systems, you must be familiar with the form of OMEGAMON for
z/OS managed system names.
If a matching SAF profile does not exist to protect a given agent Take Action command, the request to
transmit an action to the managed system is denied.
To create resource profiles to control OMEGAMON for z/OS Take Action commands, you need to know the
resource names of the commands. In addition, if you are using the SAF class name override parameter
KM5_SECURITY_ACTION_CLASS to override the SAF security class name for Take Action commands, you
must also create resource profiles for the override class.
For more information, see “Authorize users to access OMEGAMON for z/OS managed systems on the
enhanced 3270 user interface” on page 38 and “Prefixed Take Action commands” on page 32.
Performing a staged upgrade

To make product upgrades easier, OMEGAMON for z/OS supports upgrading agents gradually, by allowing
a mixture of monitoring agents of the current version and the previous version in the same environment.
You can deploy new monitoring agents to your z/OS systems and Sysplexes along with older monitoring
agents of the same product, during an upgrade transition period. If you are upgrading from a release
before V5.3, you must upgrade to V5.3 or later before you upgrade to V5.5.
If you want to do a staged upgrade to V5.5, the Sysplex proxy, the Plexview proxy, and any monitoring
servers that are eligible to serve as backups to the Sysplex proxy must be at V5.5. (For more information
about the Sysplex proxy and the Plexview proxy, see “Designating the Sysplex and Plexview proxy” on
page 7). This means that an address space that is at V5.3 is not eligible to be the Sysplex proxy.

Scenarios
1. A single Sysplex with different versions or different maintenance levels of OMEGAMON for z/OS on
each LPAR.
Make sure that only the Tivoli Enterprise Monitoring Servers (TEMS) that are at the highest version or
maintenance level are eligible to be a Sysplex proxy.
2. Multiple Sysplexes with different versions or different maintenance levels of OMEGAMON for z/OS in
each Sysplex.
Make sure that:
• only the TEMS that are at the highest maintenance level in each Sysplex are eligible to be a Sysplex
proxy
• only the TEMS that are at the highest version (V5.5) and maintenance level are eligible to be the
Plexview proxy. In a Sysplex with all V5.3 level TEMS, the ones at the highest maintenance level can
be a Sysplex proxy, but none of them should be eligible to be the Plexview proxy. Only TEMS that are
running V5.5 can be eligible to be the Plexview proxy.
3. Multiple Sysplexes with different versions or different maintenance levels of OMEGAMON for z/OS in
various LPARs in each Sysplex.
Make sure that:
• only the TEMS that are at the highest version and maintenance level in each Sysplex are eligible to be
a Sysplex proxy.
• only the TEMS that are at the highest version (V5.5) and maintenance level are eligible to be the
Plexview proxy. Only TEMS that are running V5.5 and are at the highest level of maintenance can be
eligible to be the Plexview proxy.
For information about how to make TEMS eligible to be a Sysplex proxy or a Plexview proxy, see
KM5_SYSPLEX_PROXY_POSITION and KM5_PLEXVIEW.
Chapter 2. Reference 15
Chapter 3. Configuring
Configuration of OMEGAMON for z/OS involves setting values for a set of configuration parameters using
the Parameter Generator (PARMGEN) method.
The Parameter Generator (PARMGEN) method takes a runtime environment oriented approach to
configuration. With PARMGEN, you edit a comprehensive list of parameters to configure a runtime
environment and all the installed products and components in it. You then submit a series of jobs to
create a complete runtime environment with the parameter values you specified.
You must take additional steps outside of the PARMGEN configuration profile to complete the
configuration.
The instructions in this information assume that:
• A Tivoli Enterprise Monitoring Server has been configured in the runtime environment, as described in
IBM Tivoli Monitoring: Configuring the Tivoli Enterprise Monitoring Server on z/OS.
• You have read Planning for configuration and understand the decisions you will need to make during
configuration.
Configuring OMEGAMON for z/OS

You configure OMEGAMON for z/OS by accepting or customizing the values of parameters that begin with
KM2 or KM5.
For guidance on setting parameter values, see the following sources of information:
• comments in the configuration profiles
• online help for the configuration profile
If the supplied KCIRPLBS macro has been copied to your SYSPROC concatenation, you can enter TSO
KCIRPLBS at the ISPF command line to run the help macro. Place the cursor anywhere on the line
containing the parameter for which you want help text displayed, and then press PF14.
• the Common parameters section in the IBM Tivoli OMEGAMON and Tivoli Management Services on z/OS
Shared Documentation
• the Reference section in the IBM Tivoli OMEGAMON and Tivoli Management Services on z/OS Shared
Documentation
• Overview of configuration parameters
• KM5 parameters
• KM2 parameters
Before you configure the OMEGAMON for z/OS agent using the PARMGEN method, you should have
completed the tasks listed in Table 3 on page 17:
Table 3. Tasks to complete before configuring OMEGAMON for z/OS

Configuration task Location of instructions
Set up PARMGEN work libraries for the runtime Configuring section in the IBM Tivoli OMEGAMON
environment and Tivoli Management Services on z/OS Shared
Documentation
Set up the PARMGEN configuration profile for the Configuring section in the IBM Tivoli OMEGAMON
runtime environment and Tivoli Management Services on z/OS Shared
Documentation

Table 3. Tasks to complete before configuring OMEGAMON for z/OS (continued)
Configuration task Location of instructions
Configure a Tivoli Enterprise Monitoring Server Configuring the Tivoli Enterprise Monitoring Server
on z/OS and Reference sections in the IBM Tivoli
OMEGAMON and Tivoli Management Services on
z/OS Shared Documentation.
Note: Because OMEGAMON for z/OS runs in the
monitoring server address space, you must install a
monitoring server in every runtime environment in
which you configure the monitoring agent.
Configure an OMEGAMON Subsystem Configuring section in the IBM Tivoli OMEGAMON

and Tivoli Management Services on z/OS Shared
Documentation
Note: Configure only one OMEGAMON Subsystem
for each LPAR.
(Optional) Configure the OMEGAMON Enhanced Configuring section in the IBM Tivoli OMEGAMON
3270 user interface address space and Tivoli Management Services on z/OS Shared
Documentation
Note: You only need to configure one OMEGAMON
Enhanced 3270 user interface address space in a
hub.
Tip: If you are enabling self describing agents, configure a stand-alone high-availability hub monitoring
server. Installing a high-availability hub lets you apply maintenance or upgrades without recycling the
hub. If you have an existing static hub to which agents report, convert the hub to a remote and configure
all the remotes to report to the new high-availability hub.
After you have configured OMEGAMON (and any other agents you want to configure) using the
runtime environment profile, you must complete several configuration tasks outside of the profile. See
“Completing the configuration” on page 21.
Configuring OMEGAMON
You configure the OMEGAMON component of the monitoring product to define Sysplex-level entities,
assign the current runtime environment to a Sysplex, install product-specific data on the Tivoli Enterprise
Monitoring Server, and register the OMEGAMON for z/OS monitoring agent in the Tivoli Enterprise
Monitoring Server address space. You also configure the persistent data store for the product historical
data and allocate the data sets to store the Sysplex-level and system-level data. These parameters are
specified in the KM5 section of the PARMGEN configuration profile.
You configure RMF near-term history data collection in the global (RTE_) section of the PARMGEN
configuration profile.
Default values are provided for all required parameters and some optional ones. If you do not want to
customize these parameters, and you do not want to enable optional features, you can complete the
configuration by accepting these defaults. Alternatively, you can specify custom values. You can also
specify custom values for optional parameters that have no defaults. You must specify values for these
parameters in order to activate those features. You can supply custom values for the following required
and optional features:
• Security class and command-level control for Take Action commands
The security for Take Action commands provided with the OMEGAMON for z/OS is implemented through
direct System Authorization Facility (SAF) calls and is based on profiles and resource names. These
commands cannot be run unless security is configured.

• RMF real time and near-term history data
Optionally, the OMEGAMON for z/OS monitoring agent can be configured to use RMF data instead of
collecting its own. You can configure the agent to use all RMF-supplied real-time data, spin lock data
only, or coupling facility and cross-coupling facility data only.
The OMEGAMON for z/OS monitoring agents collect near-term history data from the RMF Distributed
Data Server.
Before OMEGAMON for z/OS Version 5.5 Fix Pack 6, the OMEGAMON subsystem collected near-term
history data from the RMF Distributed Data Server by default. You can turn off near-term history data
collection or you can specify a group name.
• Messages for proxy switch
By default, messages reporting that the location of the Sysplex proxy has changed are sent to the log.
You can configure the monitoring agent to send these messages to the operator console.
• Override zIIP offload
By default, a portion of the OMEGAMON for z/OS DASD data collection processing is redirected to
IBM System z Integrated Information Processors (zIIPs), where these are available. This frees up the
standard processors for other work.
• MIM started task names
Optionally, you can specify names for MIM started tasks.
• ICSF load library for zAware
Optionally, you can specify the ICSF load library in PARMGEN.
Configuring security for Take Action commands

OMEGAMON for z/OS agent Take Action commands cannot be issued unless a security class is defined to
the SAF security manager and the security class name configured in each runtime environment in which
an OMEGAMON for z/OS monitoring agent is configured.
To secure Take Action commands, you must configure the global security parameter
(RTE_SECURITY_CLASS). Optionally, you can use the SAF class name override parameter
(KM5_SECURITY_ACTION_CLASS) to specify a separate class for securing individual Take Action
commands. After each security class has been defined, profiles must be created to control access to
individual commands and user IDs must be given UPDATE access to those profiles. See “Prefixed Take
Action commands” on page 32.
Configuring the OMEGAMON for z/OS agent to use RMF data

The OMEGAMON for z/OS agent in the Tivoli Enterprise Monitoring Server (TEMS) collects RMF data for
near-term historical collection from RMF monitor III, and then stores the data in the Persistent Data Store
version 2 (PDS V2).
This feature is available in OMEGAMON for z/OS Version 5.5 Fix Pack 6 and later. Near-term history
collection must now be performed individually for each report (in earlier versions, it was automatically
collected by the OMEGAMON subsystem). For more information, see “Enable RMF data collection” on
page 26.
RTE_KM5_NTH
Default value is Y. If you do not want use RMF near-term history data collection, set this parameter to
N or NO.
RTE_KCN_CACHE_KM5_NTH
In OMEGAMON for z/OS Version 5.5 Fix Pack 6 and later, this parameter is deprecated and not used.
Default value is KM5WMSRS. One OMEGAMON subsystem per group in a Sysplex runs an RMF
cache. Others in the group are ready to start an RMF cache if the active RMF cache is stopped. This
parameter specifies the group name that is used by the OMEGAMON Subsystems and OMEGAMON
Chapter 3. Configuring 19
for z/OS agents. The OMEGAMON for z/OS agents discover the OMEGAMON Subsystem that uses the
z/OS Sysplex Routing Services to register with this group name.
Note: Specify the same value for RTE_KCN_CACHE_KM5_NTH in all RTEs in a Sysplex. Setting
different values results in caching data in more than one OMEGAMON subsystem per Sysplex, an
agent not finding an OMEGAMON Subsystem to retrieve data from, or both.
RTE_KCN_CACHE_KM5_NTH_RANGE
In OMEGAMON for z/OS Version 5.5 Fix Pack 6 and later, this parameter is deprecated and not used.
Default value is 24. The number of hours of near-term history data that the OMEGAMON Subsystem
loads during initialization of the RMF cache.
RTE_KCN_CACHE_KM5_RMF_DDS
By default, the RMF Distributed Data Server (DDS) is automatically discovered. Specify the RMF DDS
from which you want to retrieve near-term historical data.
For more information about these parameters, see KM5 parameters.
RMF for near-term history data collection in earlier versions

Before Fix Pack 6, the use of RMF for near-term history data collection was controlled by these
parameters: RTE_KM5_NTH, RTE_KCN_CACHE_KM5_NTH, RTE_KCN_CACHE_KM5_NTH_RANGE, and
RTE_KCN_CACHE_KM5_RMF_DDS. The default value for the RTE_KM5_NTH parameter is Y to enable
RMF near-term history data collection. Both OMEGAMON for z/OS monitoring agents and the OMEGAMON
subsystem participate in RMF near-term history data collection.
Turning off zIIP offload

A portion of the OMEGAMON for z/OS DASD data collection processing is redirected to IBM System
z® Integrated Information Processors (zIIPs), where available. This frees up the standard processors
for other work and can reduce software licensing costs. You can disable the offloading by adding
KM5ZIIPOFFLOAD=NO to the &rhilev.&rte.WCONFIG(KDS$PENV) file.
The contents of the KDS$PENV file are dynamically embedded in the KDSENV file. This prevents the
parameter from being overwritten when updates or maintenance is applied.
Sending messages for proxy switch to the console

If the Tivoli Enterprise Monitoring Server designated as the Sysplex proxy goes down, the Sysplex proxy
migrates to a backup monitoring server. You can configure the product to send a message to the operator
console when the location of the proxy changes.
To configure OMEGAMON for z/OS to send a message regarding the change of location of the proxy, set
the value of KM5_KDS_KOSWTO_FLAG in the following section to Y:
** Write Sysplex proxy message to the MVS console:
KM5_KDS_KOSWTO_FLAG N
Specifying MIM names

CA-Multi-Image Manager (MIM) is used to control an enqueue environment across multiple Sysplexes. For
systems that use MIM, you can define up to three MIM started task names.
Use the parameters in the following section to specify names for MIM started tasks:
** (Optional) Started task names for MIM support:
**KM5_MIM_STC1 MIMPROC1

Completing the configuration
There are a number of steps you must take outside of the configuration profile to complete the
configuration of OMEGAMON for z/OS. The steps you have remaining to complete depend on what steps
you have already taken, what options you have chosen, and what you intend to monitor.
If you have not already done so, complete the following steps to ensure that you have the definitions that
have been created in the configuration in your runtime environment.
The following tasks must be completed for every product and can be completed all at one time for all the
products.
• “Add support for the SYSTCPD DDNAME in the started tasks” on page 22.
• “Copy started task procedures to your procedure library” on page 23.
• “Copy the VTAM definitions to your system VTAMLST” on page 23.
• “Vary the VTAM major node active” on page 23.
• “APF-authorize the runtime load libraries” on page 23.
• “Enable historical data store maintenance” on page 23.
Note that if you run the WKANSAMU(KCIJcSYS) job (where c = P if SYSV is not enabled; V if SYSV
is enabled), all the STCs and VTAM major nodes are copied to the system libraries specified for
the GBL_DSN_SYS1_* parameter in the configuration profile. If you are using the global VTAM node
(RTE_VTAM_GBL_MAJOR_NODE parameter), you can use the WKANSAMU(ccccAPF) imbed member to
VARY the node and APF authorize the load libraries. To use ccccAPF, uncomment the placeholder INAPF
INCLUDE statement in each started task:
//******************************************************************
//* Uncomment out the INAPF statement if are using this composite
//* member to APF-authorize the libraries concatenated in the
//* STEPLIB and RKANMODL DDNAMEs.
//*INAPF INCLUDE MEMBER=IBMAPF
If you are using a local node, you must VARY the node active and authorize the libraries yourself.
To complete configuration of the OMEGAMON Subsystem:
• “Update the LINKLIST” on page 22.
• “Update the IEFSSNxx member of SYS1.PARMLIB” on page 22.
If you intend to collect ICSF data:
• “Copy CSFPRM00 into SYS1.PARMLIB” on page 25.
• “Add the KM5EXIT3 to the ICSF Configuration” on page 25
“Modify the ICSF subsystem JCL” on page 25.
If you intend to collect UNIX System Services information:
• “Authorize address spaces for UNIX System Services” on page 25.
• “UNIX commands” on page 31.
If you have configured use of coupling facility, cross-system coupling facility, or system lock data
collected by Resource Measurement Facility:
• “Enable RMF data collection” on page 26.
If you have accepted the default (enabled) or configured near-term history collection from Resource
Measurement Facility:
• “Enable RMF data collection” on page 26.
If you intend to collect historical data using IBM Tivoli Monitoring:
• “Configure historical data collection” on page 29
If you intend to warehouse the historical data in the Tivoli Data Warehouse, but the hub monitoring server
is not located on the same computer as the Tivoli Enterprise Portal Server:
• “Enable Warehouse agents on a z/OS hub monitoring server” on page 29.
To enable monitoring of Sysplex DASD device data:
• “Create situations to filter DASD device collection” on page 30.
If you want to use OMEGAMON for z/OS to help you plan special processor resources:
• “Set the PROJECTCPU control in the SYS1.PARMLIB IEAOPTxx member” on page 30.
If you previously used IBM OMEGAMON z/OS Management Console situations and you want to replace
them with OMEGAMON for z/OS situations:
• “Recreate or replace z/OS Management Console situations” on page 38
Finally, perform the following tasks to complete the configuration:
• “Install application and language support” on page 30.
• “Verifying the configuration” on page 56.
• “Enable security for Tivoli Enterprise Portal” on page 31.
• “Authorize users to access OMEGAMON for z/OS managed systems on the enhanced 3270 user
interface” on page 38
• “Authorize users to issue Take Action commands” on page 31.
Update the IEFSSNxx member of SYS1.PARMLIB

The appropriate IEFSSNxx member of SYS1.PARMLIB must be updated to identify the OMEGAMON
Subsystem to z/OS.
Member KCNDLSSI (created in the Create runtime members step) in the &rhilev.&rte.RKANSAMU data set
contains a sample IEFSSNxx update. In addition to identifying the OMEGAMON Subsystem to z/OS, this
sample causes an automatic start of the subsystem address space.
Update the LINKLIST

Load module KCNDLINT must be placed in an APF-authorized, link-listed library so that it is available
during system IPL.
Copy the module to an appropriate library in the linklist. Follow your installation standards in making this
decision.
Note: All runtime libraries concatenated in the STEPLIB DDNAME of the IBMCN started task must be
APF-authorized.
Add support for the SYSTCPD DDNAME in the started tasks

If the monitoring server is using any of the IP.UDP-related or IP.PIPE-related communication protocols
for connection, but the IP domain name resolution is not fully configured on this z/OS system, you must
specify the SYSTCPD DDNAME in the IBMDSST started task.
PARMGEN generated the IBMDSST started task with the following commented out lines. Customize the
SYSTCPD DDNAME accordingly if this scenario fits your environment:
//*SYSTCPD explicitly identifies which dataset to use to obtain

//*the parameters defined by TCPIP.DATA when no GLOBALTCPIPDATA
//*statement is configured. Refer to the IP Configuration Guide
//*for information on the TCPIP.DATA search order. The dataset
//*can be any sequential dataset or a member of a partitioned
//*dataset. TCPIP.SEZAINST(TCPDATA) is the default sample file.
//*TCPIVP.TCPPARMS(TCPDATA) is another sample and is created as
//*part of the Installation Verification Program for TCP/IP.
//*Note: Uncomment out this DDNAME and point to appropriate

//* TCPDATA library name supported at your site if domain
//* name resolution is not fully configured.
//*SYSTCPD DD DISP=SHR,
//* DSN=TCPIP.SEZAINST(TCPDATA)
When you are finished, copy the procedures to PROCLIB.
Copy started task procedures to your procedure library

During the configuration, a number of started task procedures are created in the &rhilev.&rte.RKANSAMU
data set. If you have not already done so, you must copy these procedures to your procedure library. You
can copy the procedures as part of the PARMGEN configuration process.
For more information about the PARMGEN method of parameter configuration, see the Configuring section
Copy the VTAM definitions to your system VTAMLST

The configuration process creates VTAM definitions in the RKANSAMU library. You must copy the VTAM
major node (default: IBMDSN) to your system VTAMLST. You can copy the procedures as part of the
PARMGEN configuration process.
For more information about the PARMGEN method of parameter configuration, see the Configuring section
Vary the VTAM major node active

The VTAM major node (default: IBMDSN) is created in the RKANSAMU library and copied to your system
VTAMLST. It must be VARY’d active.
To vary VTAM major node active, enter:
V NET,ACT,ID=nodeid
There is code in the IBMM2 procedure that will vary the node (see “Copy started task procedures to your
procedure library” on page 23).
APF-authorize the runtime load libraries

The runtime load libraries created during configuration must be added to the list of APF-authorized
libraries
If you have not already done so, add the following runtime load libraries to your list of APF-authorized
libraries.
• &rhilev.&rte.RKANMOD
• &rhilev.&rte.RKANMODU
• &rhilev.&rte.RKANMODL
If the runtime environment shares with SMP/E targets, you will also need to add:
• &thilev.TKANMOD
• &thilev.TKANMODL
Note: All runtime libraries concatenated in the STEPLIB DDNAME and in the RKANMODL DDNAME of any
started tasks must be APF-authorized.
Enable historical data store maintenance

If you intend to enable historical data collection and have allocated and configured maintenance of the
historical data set, you must perform three additional tasks to enable the maintenance.
Perform the following tasks:
• “Provide access to the persistent data store files” on page 24.
• “Authorize the KPDDSCO module” on page 24.
• “Verify persistent data store configuration” on page 24.
If you are upgrading an existing monitoring server or monitoring agent, you must also refresh the
KPDPROC1 maintenance procedure in your system procedure library. See the Upgrading section in the
IBM Tivoli OMEGAMON and Tivoli Management Services on z/OS Shared Documentation.
Provide access to the persistent data store files

The KPDPROC1 procedure is used to maintain the physical files that constitute the persistent data store.
Ensure that KPDPROC1 procedure has the necessary authority to read, write, and update the persistent
data store files.
Data store files are archived, exported or recycled according to the maintenance strategy that you
specified for persistent data store file groups for the product. The persistent data store subsystem
automatically submits maintenance jobs whenever a data store file becomes full. The maintenance
procedure must be available in a system procedure library for the procedure to operate. The procedure is
generic so it may be used by all runtime environment using this version of the persistent data store.
Authorize the KPDDSCO module

The KPDPROCC REXX procedure runs in a TSO environment and must be enabled to run as an authorized
program under TSO.
Authorize the KPDDSCO module by adding KPDDSCO to the system PARMLIB(IKJTSOnn) under the
AUTHPGM section and refresh the IKJTSOnn member by issuing the set command (T IKJTSO=nn). You
might also request that authorized system programmers perform this step so it can be scheduled with the
LPAR change control processes.
Verify persistent data store configuration

You can perform several steps to verify that the configuration and authorization of the procedures have
been successful.
Perform the following steps:
1. Bring up the started task (for monitoring server or monitoring agent) that will collect historical data
into the product's persistent data store libraries. In the RKPDLOG DDNAME started task, find any
persistent data store libraries in a non-Offline status (for example, Partial or Full status).
2. From a z/OS operator console, issue the following z/OS MODIFY command:
/F &stcname,KPDCMD RECOVER FILE=DSN:&pds_dataset
(where &stcname is the name of the started task performing the persistent data store collection, and
&pds_dataset is the persistent data store data set).
For example, issue the following MODIFY command for the monitoring server:
/F CIDSST,KPDCMD RECOVER FILE=+

DSN:&rhilev.&rte.RGENHIS1
3. Wait 5 minutes.
4. In the RKPDLOG DDNAME started task, find the following Command: and KPDDSTR: references as
shown in the following monitoring server RKPDLOG DDNAME example:
Command: RESUME FILE=DSN:&rhilev.&rte.RGENHIS1

KPDDSTR: CONNECT processing started for DataStore file
KPDDSTR: CONNECT processing ended for DataStore file

5. If these references are not found, view the KPDPROC1 started task in SDSF and look for any obvious
errors.
Copy CSFPRM00 into SYS1.PARMLIB

The file &rhilev.&rte.RKANSAMU(CSFPRM00) is created with the modifications necessary to successfully
run this product.
If the CSFPRM00 file in your SYS1.PARMLIB does not include the necessary EXIT parameter, CSFEXIT3 -
EXIT(CSFEXIT3,KM5EXIT3,FAIL(EXIT)), copy &rhilev.&rte.RKANSAMU(CSFPRM00) into SYS1.PARMLIB.
Add the KM5EXIT3 to the ICSF Configuration

To set up ICSF data collection, you must make KM5EXIT3 accessible at subsystem and agent startup. The
RKANMOD runtime data set contains KM5EXIT3. You can choose between two methods of adding the exit
to the ICSF configuration.
Method 1: Add RKANMOD to the ICSF STEPLIB

To use this method, modify the ICSF subsystem JCL to include the &rhilev.&rte.RKANMOD data set in the
STEPLIB DD concatenation (where &rhilev is the high-level qualifier and &rte is the runtime environment).
The data set must be APF-authorized. If KM5EXIT3 is then updated by a runtime environment load
operation, you must recycle the ICSF subsystem to use the updated exit.
Advantage of Method 1: When maintenance is applied to the RKANMOD(KM5EXIT3) load module, you do
not have to copy the module to another load library.
Drawback of Method 1: All load modules in the RKANMOD data set are exposed to the ICSF address
space.
Method 2: Copy RKANMOD(KM5EXIT3) to a new data set

To use this method, copy RKANMOD(KM5EXIT3) into either a new APF-authorized LOADLIB data set or a
data set defined to the LINKLIST. If you copy to a LOADLIB data set, you must concatenate the new data
set to the STEPLIB of ICSF. If you copy to a LINKLIST data set, you need not adjust the STEPLIB of ICSF.
Advantage of Method 2: Only the KM5EXIT3 module is exposed to the ICSF address space.
Drawback of Method 2: When maintenance is applied to the RKANMOD(KM5EXIT3) load module, you will
have to copy the updated load module to the separate LOADLIB or LINKLIST data set and then recycle the
ICSF subsystem to use the updated exit. Additionally, if you have used a LINKLIST data set, you will have
to perform a LINKLIST lookaside (LLA) refresh.
Modify the ICSF subsystem JCL

To provide sufficient storage to allow the monitoring exit to run, modify the ICSF subsystem JCL to
increase the REGION limit to REGION=0M.
Authorize address spaces for UNIX System Services

If you intend to use OMEGAMON for z/OS to monitor UNIX System Services data, you must grant
superuser authority to the address space in which OMEGAMON for z/OS is defined. This level of authority
is equivalent to root authority (UID=0). (Alternatively, privileged or trusted attributes can be associated
with the started task, or it may be given read access to BPX.SUPERUSER. See the documentation for your
security system for details on how to associate attributes or give read access.)
The user ID of the Tivoli Enterprise Monitoring Server address space is the name shown in the SDSF
Display Active screen as the OWNER of the address space, which is often the started task name but does
not have to be. An administrator must define this ID to RACF or some other security system.
Users are defined to z/OS UNIX using RACF commands. The z/OS UNIX attributes are kept in the OMVS
segment of the RACF user’s profile. This means that to enable OMEGAMON for z/OS to collect UNIX
System Services data and issue UNIX commands:
• The user ID of the Tivoli Enterprise Monitoring Server address space must be defined in RACF.
• The profile associated with the RACF user ID must contain an OMVS segment.
• In the OMVS segment, the z/OS UNIX user identifier (UID) must have a value of 0 (superuser).
• The user default group must be an UNIX System Services group.
If you recently migrated to z/OS V.1, you might find OMVS errors in the system log when you launch the
OMEGAMON for z/OS monitoring agent. Be aware that as of z/OS V2R1, the ability to use default OMVS
segments has been removed. All z/OS UNIX users or groups must now have OMVS segments defined for
user and group profiles with unique user IDs (UIDs) and group IDs (GIDs). For more information about this
error and solutions, see OMVS segment errors found in system log on z/OS V2.1 systems.
Enable RMF data collection

If you have configured OMEGAMON for z/OS to use RMF data collection for real-time or near-term history
data collection, you must perform the steps that are described in this section.
Ensure that the following RMF components are activated:
• RMF Control Task (RMF)--one instance on each monitored system.
• RMF Monitor III Gatherer (RMFGAT)--one instance on each monitored system.
• RMF Distributed Data Server (GPMSERVE)--one instance per Sysplex.
Some companies run multiple RMF DDSes in a Sysplex. The RMF DDS used by OMEGAMON for z/OS is
auto-discovered. If you want OMEGAMON for z/OS to use a different RMF DDS, specify its IP address
or host name in the PARMGEN RTE_KCN_CACHE_KM5_RMF_DDS parameter. The RMF DDS that you
specify and its port number are used by the TEMS and OMEGAMON subsystem RMF cache to retrieve
data from the RMF DDS.
OMEGAMON for z/OS Version 5.5 Fix Pack 6 and later gets RMF data for historical data collection directly
from the RMF Distributed Data Server. (Earlier versions got the data from the OMEGAMON subsystem
cache.) For more information, see Configuring OMNIMON Base in the IBM Tivoli OMEGAMON and Tivoli
Management Services on z/OS Shared Documentation.
For near-term history data collection prior to OMEGAMON for z/OS Version 5.5 Fix Pack 6, an additional
requirement is that at least one instance (two for redundancy and up to one instance on each monitored
system) of the OMEGAMON subsystem must be active per Sysplex. In OMEGAMON for z/OS Version 5.5
Fix Pack 6 and later, data from RMF is collected by OMEGAMON for z/OS agents running in the Tivoli
Enterprise Management Server, and it is stored in the Persistent Data Store version 2.
If RMF Collection has been configured, you must ensure that the RMF Distributed Data Server (DDS)
is started and RMF Monitor III tasks are started in all LPARs in this Sysplex so that the DDS can
consolidate data from each LPAR. OMEGAMON for z/OS and, for near-term history, the OMEGAMON
subsystem (OB730 or higher) must also be enabled to connect to the DDS. This is done by enabling
RACF's PassTicket service.
If OMEGAMON for z/OS is configured to use coupling facility data collected by RMF, RMF Monitor III
collection for coupling facility details (CFDETAIL) must be turned on. In RMF, collection is turned on by
ensuring the Monitor III parameters in SYS1.PARMLIB(ERBRMFnn) have CFDETAIL set. Collection can
also be turned on dynamically by issuing the following operator command:
ROUTE *ALL,MODIFY RMF,MODIFY III,CFDETAIL
See the RMF z/OS V1R12.0 RMF User's Guide for more details, in particular the section on Defining
Parameters for RMF Monitor III and the section on CFDETAIL.

If OMEGAMON for z/OS is configured to use lock data collected by RMF, RMF Monitor III collection for
LOCK must be turned on. LOCK can be set as the default in SYS1.PARMLIB(ERBRMFnn) or by using the
dynamic command:
/MODIFY RMF,MODIFY III,LOCK
Note: It is suggested that SYS1.PARMLIB(GPMSRV00) specify CACHESLOTS(10) and that

SYS1.PARMLIB(ERBRMFnn) specify DATASET(WHOLD(50)) for RMF III fixed pages (in MB) and
WSTOR(128) for RMF III size in storage buffer (in MB)
The following topics describe the additional steps that you must take to enable use of RMF data:
• “Define RACF IDs for OMEGAMON for z/OS and OMEGAMON Subsystem address spaces” on page 27.
• “Enable the RACF secured signon function (PassTicket)” on page 27.
• “Turn on RMF collection of coupling facility and lock data.” on page 28.
Define RACF IDs for OMEGAMON for z/OS and OMEGAMON Subsystem
address spaces
Activation of the RMF DDS API requires a RACF user ID and password. An administrator must define the
IDs of these address spaces to RACF.
For the user ID, OMEGAMON for z/OS and OMEGAMON subsystem use the name shown in the SDSF
Display Active screen as the OWNER of the address space. This is often the started task name, but it
does not have to be. You will probably also want those IDs added to a group to simplify PassTicket
authorization.
After you have installed OMEGAMON for z/OS Version 5.5 Fix Pack 6 or later and turned off the
OMEGAMON subsystem cache, you do not need to define a RACF user ID and password for the
OMEGAMON subsystem.
Enable the RACF secured signon function (PassTicket)

Enabling the secured signon function requires a series of coordinated RACF commands.
To enable the function, a RACF administrator must complete the following steps:
1. Activate the PTKTDATA class (if not already activated). For example:
SETROPTS CLASSACT(PTKTDATA)
SETROPTS RACLIST(PTKTDATA)
SETROPTS GENERIC(PTKTDATA)
The PassTicket key class enables the security administrator to associate a RACF secured signon secret
key with a particular mainframe application that uses RACF for user authentication. All profiles that
contain PassTicket information are defined to the PTKTDATA class.
2. Define a profile in the PTKTDATA class for the Distributed Data Server (GPMSERVE).
The name of the profile must be the name of the DDS application. For example:
RDEF PTKTDATA GPMSERVE SSIGNON([KEYENCRYPTED|KEYMASKED](key))
The profile associates a secret secured signon application key with a particular application on a
particular system. The key is a 16-digit hexadecimal user-supplied value.
Note: The default application name for PassTicket generation is GPMSERVE. If the RACF user exit
ICHRIX01 redefines this name, the OMEGAMON client must use the ID provided by the user exit. If
you need to use an alternative name, contact IBM Software Support.
3. Create a RACF profile for PassTicket generation.
This determines who can create PassTickets for GPMSERVE.
RDEF PTKTDATA IRRPTAUTH.GPMSERVE.* UACC(NONE)
4. Authorize the Tivoli Enterprise Monitoring Server and OMEGAMON subsystem address spaces to use
PassTicket services.
After you have installed OMEGAMON for z/OS Version 5.5 Fix Pack 6 or later and turned off the
OMEGAMON subsystem cache, you do not need to define a RACF user ID and password for the
OMEGAMON subsystem.
Use of R_ticketserv service to use PassTicket services (function code 3) is authorized by the resources
in the PTKTDATA class that correspond to the application ID and target userid used in the PassTicket
operation. The application server must be running with a RACF user or group that has the following
authority specified:
PERMIT IRRPTAUTH.GPMSERVE.* ID(STCUSER) ACCESS(UPDATE) CLASS(PTKTDATA)
where STCUSER is the group ID used for the monitoring server and OMEGAMON subsystem address
spaces.
SETR RACLIST(PTKTDATA) REFRESH
Note: If PassTicket authentication is used, the user ID for the monitoring server and OMEGAMON
subsystem address space cannot be defined as PROTECTED. Using PassTicket authentication is the
equivalent to using a password, and a PROTECTED RACF user ID can not have a password specified in
its definition.
Note: KEYENCRYPTED requires that the CSNBENC module reside in the link pack area (LPA) if not
already there. The CSNBENC module can be dynamically loaded, or added to PLPA or MLPA with the
respective PARMLIB members. The following modules must reside in APF-authorized link-listed data
sets: CSNBCKI, CSNBKRC, CSNBKRD, CSNBKRW.
Tip
Depending on your RACF options, the user ID of the person who enters the RDEF command might also be
on the access list for IRRPTAUTH.GPMSERVE.*. To check whether the ID is included, run the following
command, and then check the access list:
RLIST PTKTDATA IRRPTAUTH.GPMSERVE.*
To delete an unwanted user ID, issue the following command:
PERMIT IRRPTAUTH.GPMSERVE.* id(userid) DELETE class(PTKTDATA)
Note: You can choose to bypass user ID and password authentication for all or selected users through
initialization parameters. See the RMF documentation for a discussion of HTTP_NOAUTH.
Turn on RMF collection of coupling facility and lock data.

If OMEGAMON for z/OS has been configured to use RMF coupling facility data (RMF Collection =
CF/XCF), you must ensure that collection of coupling facility details is turned on in every RMF Monitor III
in the Sysplex. If OMEGAMON for z/OS has been configured to use RMF lock data (RMF Collection =
LOCK), ensure that collection of LOCK data is turned on in every RMF Monitor III in the Sysplex.
In RMF, collection of coupling facility details is enabled by setting CFDETAIL in the Monitor III parameters
in SYS1.PARMLIB(ERBRMFnn). Collection can also be enabled dynamically by issuing the following
operator command:
ROUTE *ALL,MODIFY RMF,MODIFY III,CFDETAIL
See the section on Defining Parameters for RMF Monitor III and the section on CFDETAIL in the RMF
User's Guide for details.

You can enable collection of lock data by setting LOCK as the default in SYS1.PARMLIB(ERBRMFnn) or use
the dynamic command
/MODIFY RMF,MODIFY III,LOCK
to turn on collection.
If OMEGAMON for z/OS has been configured to use RMF data for both coupling facility and lock data (RMF
Collection = ALL), both CFDETAIL and LOCK must be set.
Configure historical data collection

Tivoli Management Services provides for two kinds of history data: short-term history data, which is
stored in the persistent data store (on z/OS systems) or in files (on distributed systems), and long-term
history data, which is stored in the Tivoli Data Warehouse. Both short-term and long-term history are
optional features that can be enabled from the Tivoli Enterprise Portal.
The Tivoli Enterprise Portal History Collection dialog box displays all of the OMEGAMON for z/OS attribute
tables that are enabled for historical collection and reporting. To enable historical data collection for
these attribute groups, you must select and configure each group (attribute table) for which you want to
collect data, and then start collection of those groups. If you want to warehouse the data for long-term
historical reporting, you must set the Warehouse Interval to the interval at which data is warehoused.
For more information about configuring history data collection, see:
• Using historical data collection and reporting
• the Administrator's Guide in the IBM Tivoli Monitoring documentation
• the Tivoli Enterprise Portal online help.
Enable Warehouse agents on a z/OS hub monitoring server

If you want to store long-term history data and your hub monitoring server is on z/OS, you must transfer
the catalog and attribute files for the Warehouse Proxy agent and the Summarization and Pruning agent to
the hub using Manage Tivoli Monitoring Services.
The catalog and attribute data files are installed on the Tivoli Enterprise Portal Server when you install
application support for OMEGAMON for z/OS, using the IBM OMEGAMON for z/OS CD. You can then FTP
the files to the hub monitoring server.
If the portal server is installed on a Windows system, you can FTP the files to a z/OS hub using Manage
Tivoli Monitoring Services:
1. On the host of the Tivoli Enterprise Portal Server, open the Manage Tivoli Monitoring Services
application. For example:
Start > IBM Tivoli Monitoring > Manage Tivoli Monitoring Services.
2. Right-click the name of the portal server and select Advanced > Utilities > FTP Catalog and Attribute
files.
The Select attribute and catalog data for transfer window dialog box is displayed.
3. Select the catalog and attribute data for the Warehouse Proxy and the Summarization and Pruning
agents, then press OK.
The FTP TEMS Data to z/OS dialog box is displayed.
4. Provide the following information:
• The name of the hub Tivoli Enterprise Monitoring Server
• A valid FTP user ID and password
• The name of the domain name server of the monitoring server where the RKANDATV data set is
located
When you have completed these fields, click OK. Click OK again in the confirmation window.
5. After the FTP operation is complete, you receive a message that the operation completed successfully.
Click OK to end this operation.
After you complete these steps, restart the hub monitoring server.
Create situations to filter DASD device collection

Because of the large DASD volume counts that have become common in recent years, monitoring DASD
devices without a filter that eliminates some of the devices can lead to high CPU or storage problems and
may even cause the monitoring server to fail. Due to these potential costs, OMEGAMON for z/OS does
not collect DASD device data unless a DASD filter situation is active. An auto-started warning situation
(KM5_No_Sysplex_DASD_Filter_Warn) notifies you if no filtering situation is in place and no devices are
being monitored.
For more information, see Creating a filtering situation.
Set the PROJECTCPU control in the SYS1.PARMLIB IEAOPTxx member

If you are not currently running System z Application Assist Processors (zAAPs) or System z Integrated
Information Processors (zIIPs), but you want to use OMEGAMON for z/OS to determine how much work
can be offloaded to special processors, set the PROJECTCPU control in the SYS1.PARMLIB IEAOPTxx
member to YES.
Install application and language support

Before data collected by OMEGAMON for z/OS monitoring agents can be displayed in the Tivoli Enterprise
Portal, support for the agents must be installed and enabled. If the self describing agent feature has
been enabled, this support is installed automatically with the agent. However, if self description has been
disabled, the support must be installed manually.
Application support files provide agent-specific information for workspaces, helps, situations, templates,
and other data. Application support for a monitoring agent includes two types of files:
• SQL files are required for adding product-provided situations, templates, and policies to the Enterprise
Information Base (EIB) tables maintained by the hub monitoring server. These SQL files are also called
seed data, and installing them on a monitoring server is also called seeding the monitoring server.
• Catalog and attribute (CAT and ATR) files are required for presenting workspaces, online help, and
expert advice for the agent in Tivoli Enterprise Portal.
Application support must be configured on all instances of the following infrastructure components: Tivoli
Enterprise Monitoring Server (both hub and remote monitoring servers), Tivoli Enterprise Portal Server,
and Tivoli Enterprise Portal desktop client, if the desktop client was installed from the installation media
rather than invoked using Java Web Start. Application support for the monitoring agent is installed on the
remote monitoring servers when agents are registered with the local monitoring server.
The files required for support are contained in IBM Tivoli OMEGAMON Data Files for z/OS DVD included in
the product package. You install support on the Tivoli Enterprise Portal Server and any desktop clients on
the computer on which they are installed. If your hub is on Windows or a UNIX operating system (Linux,
AIX®, Solaris), you install support on the monitoring server locally (that is, on the computer on which it
is installed). If your hub is on z/OS, you install support from a Windows computer that hosts either a
Tivoli Enterprise Portal Server or a Tivoli Enterprise Monitoring Server. The hub monitoring server must be
running while you are installing support.
Use the procedures documented in the IBM Tivoli Monitoring: Installation and Setup Guide to add support
to Tivoli Enterprise Portal or a hub monitoring server on Windows, AIX, or Linux. Use the instructions in
IBM Tivoli Management Services on z/OS: Configuring the Tivoli Enterprise Monitoring Server on z/OS to add
support to a z/OS hub.
If you want application data, online help, and expert advice to be displayed in a language other than
English, you must also install language support.

You install language support from the IBM OMEGAMON for z/OS Language Pack CD on the same system
where you install application support. Install the language packs on any system where you have installed
the Tivoli Enterprise Portal or where you have installed a desktop client. (If you download and run a
desktop client using Web Start, you do not need to install the language packs on the local system. They
are downloaded from the portal server.) Before you can install a language pack, you must install the
component in English.
Enable security for Tivoli Enterprise Portal

After you have established that OMEGAMON for z/OS is configured correctly, you can safely enable
security.
To enable security for the Tivoli Enterprise Portal through either the hub monitoring server or the
Tivoli Enterprise Portal Server, review the planning information in the Planning section in the IBM
Tivoli OMEGAMON and Tivoli Management Services on z/OS Shared Documentation, and refer to the
appropriate guide for instructions.
To configure logon security for OMEGAMON (the realtime collector), and security for OMEGAMON
commands, see “Securing OMEGAMON” on page 38.
To enable security for OMEGAMON for z/OS Take Action commands, see “Prefixed Take Action
commands” on page 32.
Authorize users to issue Take Action commands

Certain commands, known as Take Action commands, can be issued from the Tivoli Enterprise Portal and
OMEGAMON Enhanced 3270 user interface user interfaces. OMEGAMON for z/OS supports three types of
Take Action commands: z/OS system commands, UNIX commands, and agent-provided commands. Users
must be authorized to issue these commands.
z/OS commands
By default, Take Action commands issued by OMEGAMON for z/OS through the Tivoli Enterprise Portal are
issued as z/OS system commands.
System commands issued using Take Action commands, whether issued by a user or triggered by
situations or policies, run without any authorization or audit trail. However, a monitoring server or
monitoring agent address space can be configured to redirect Take Action commands to NetView through
the Program to Program Interface (PPI). Take Action commands issued in NetView make full System
Authorization Facility (SAF) calls for authorization. NetView uses the Tivoli Enterprise Portal user ID
to determine the NetView operator on which the command authorization is performed. If command
authorization passes, the command is executed on the NetView operator. Messages are written to the
NetView log to provide an audit trail of the commands and the users that issued them. If you enable
NetView command authorization on the monitoring server, you must also enable NetView to execute the
commands.
For more information, see "Configuring NetView authorization of z/OS commands" in IBM Tivoli
Monitoring: Configuring the Tivoli Enterprise Monitoring Server on z/OS.
UNIX commands
To enable users with Tivoli Enterprise Portal user IDs to issue UNIX commands:
• The user's Tivoli Enterprise Portal user ID must be defined in RACF.
• The profile associated with the RACF user ID must contain an OMVS segment.
• In the OMVS segment, the z/OS UNIX user identifier (UID) must have a value of 0 (superuser).
By default, only user IDs that have been defined to z/OS UNIX System Services and have superuser, or
root, authority are allowed to issue UNIX commands through the Tivoli Enterprise Portal. User IDs are
defined to z/OS UNIX using RACF commands and the z/OS UNIX attributes are kept in the OMVS segment
of the RACF user's profile.
You can override the default validation behavior by adding one of two parameters to the KDS$PENV
override member of &rhilev.&rte.RKANPARU on the system or LPAR on which the command is being
executed.
• You can allow any RACF user ID defined to z/OS UNIX System Services to issue UNIX
commands, regardless of level of authorization, by adding the variable KOE_ALLOW_ANY_UID=1 to
&rhilev.&rte.RKANPARU(KDSENV) on the LPAR where the command is to be executed.
• You can allow any RACF user ID to issue UNIX commands, whether or not it has been
defined to z/OS UNIX System Services, by adding the variable KOE_ALLOW_UNDEFINED=1 to
&rhilev.&rte.RKANPARU(KDSENV) on the LPAR where the command is to be executed.
If you want any user with a Tivoli Enterprise Portal user ID to be able to issue UNIX commands, add both
KOE_ALLOW_ANY_UID=1 and KOE_ALLOW_UNDEFINED=1 parameters.
Prefixed Take Action commands

OMEGAMON for z/OS provides a set of predefined Take Action commands. These commands, which are
prefixed by M5:, are known as agent commands. A subset of these commands, commands that cannot
also be run as console commands, can be issued using the Take Action feature on the Tivoli Enterprise
Portal. In the OMEGAMON Enhanced 3270 user interface, the complete set of commands is available in
action menus. Security for OMEGAMON for z/OS Take Action commands is based on SAF security classes
and resource profile names. If no resource profiles are created to control Take Action commands, all
commands are denied.
The OMEGAMON Enhanced 3270 user interface validates for the following resource profile to see if users
are authorized to issue the Take Action commands directed at z/OS resources:
KM5.msn.TAKEACTION
At a minimum, you must create a profile using this pattern for the global security class
(RTE_SECURITY_CLASS) and give update access to the profile to all users you want to authorize to issue
OMEGAMON for z/OS Take Action commands. You can also create other profiles for more granular access
control.
For example, to control all OMEGAMON for z/OS Take Action commands on all managed systems, use the
following profile:
KM5.**.TAKEACTION
To restrict authority to issue commands to a specific managed system, specify the managed system
name. For example, to control the ability to issue Take Action commands to an OMEGAMON for z/OS agent
running on Sysplex IBMTEST on Sysplex member TSTA, you would define a profile named
KM5.IBMTEST:TSTA:MVSSYS.TAKEACTION
To control access to individual commands, you must define at least one profile with the following format
in either the global security class or the override security class (KM5_SECURITY_ACTION_CLASS):
KM5.**.TAKEACTION.commandname
This can be either a generic profile, or a command-specific profile. For example, to control access to all
commands, create a profile like the following:
KM5.**.TAKEACTION.*
To control access to the KILL command, create a profile with the following form:
KM5.**.TAKEACTION.KILL
To control access to the KILL command on a specific managed system, create a profile with the following
form:

KM5.msn.TAKEACTION.KILL
where msn is the managed system name of the target system. (For information on managed system
names, see “Authorize users to access OMEGAMON for z/OS managed systems on the enhanced 3270
user interface” on page 38.)
OMEGAMON for z/OS provides the following set of predefined Take Action commands:
CANCEL
CANCELDUMP
CANCELRESTART
CANCELDUMPRESTART
KILL
RESETSC
QUIESCE
RESUME
CHANGETIMELIMIT
SWAPIN
MARKSWAPPABLE
MARKNONSWAPPABLE
The KM5 override security class parameter (KM5_SECURITY_ACTION_CLASS, in PARMGEN) allows you
to specify a separate security class to control individual OMEGAMON for z/OS Take Action commands.
However, you must still create the KM5.**.TAKEACTION resource profile discussed previously for the
global security class.
Users must be given UPDATE access to the profiles. In addition, an SAF Pass Ticket profile must be
defined to allow the OMEGAMON Enhanced 3270 user interface to authenticate between the interface
and the hub monitoring server. For more information, see the Configuring section in the IBM Tivoli
OMEGAMON and Tivoli Management Services on z/OS Shared Documentation.
For information on issuing Take Action commands from the Tivoli Enterprise Portal, see Using Take Action
commands.
Memory list and memory zap

You can display and zap memory by using the OMEGAMON Enhanced 3270 user interface or invoking
them programmatically.
Overview
The memory list and memory zap functions enable you to:
• view the programs that are running in an address space
• change the instructions in a running application to correct a problem
• view and modify data that are being processed by the application.
Security
To enable security for the memory list and memory zap features, specify a security class other than
OMEGDEMO during configuration.
If you use OMEGDEMO, it bypasses security-checking by the interface and by OMEGAMON for z/OS. If you
use a class other than OMEGDEMO, users can not access memory list and memory zap by default. You can
then give selected users access to the features: see “Security for memory list and memory zap” on page
35.
• For more information about configuring security in the OMEGAMON Enhanced 3270 user interface,
see https://www.ibm.com/support/knowledgecenter/SSAUBV/com.ibm.omegamon_share.doc_6.3.0.2/
zcommonconfig/complete_security_e3270_cpcg.htm.
• For more information about authorizing users to issue Take Action commands, see “Prefixed Take Action
commands” on page 32.
Solving problems with memory list and memory zap

1. To access the memory list and memory zap features in the OMEGAMON Enhanced 3270 user interface,
use View > Memory (or type V.M in the input field in the top-left corner). Specify the address space for
which you want to view memory.
The following image displays the TCB Storage and LSQA for a selected address space.
2. Select a row, and then navigate to the TCB Storage by Subpool and Storage Key workspace. Note the
addresses of storage that might be interesting to view.
3. Navigate to the Memory Display/Zap workspace, and then enter the address in which you are
interested.

4. In the Command field, type Z.
The ZAP Memory pop-up appears.
5. Type a replacement string.
6. Press ENTER.
This message appears (unless another process updated the storage first):
MEMORY ZAP SUCCESSFUL
Security for memory list and memory zap

The memory list and memory zap functions in the OMEGAMON Enhanced 3270 user interface require two
separate layers of SAF security to be defined:
• GENERIC resource profiles must defined for the MEMLIST and MEMZAP functions which are
implemented as TAKEACTION commands in the OMEGAMON for z/OS agent’s security class. For more
information, see “GENERIC resource profiles” on page 36.
• PassTicket authentication between the OMEGAMON Enhanced 3270 user interface and the OMEGAMON
for z/OS agent enforces a secure sign-on for all memory list and memory zap functions. For more
information, see “PassTicket” on page 37.
GENERIC resource profiles

Security for OMEGAMON for z/OS Take Action commands is based on SAF security classes and resource
profile names.
1. If you are using RACF as your SAF product, use the following command to activate the SAF security
class and the SETROPTS RACLIST processing.
SETROPTS CLASSACT(class_name) RACLIST(class_name) GENERIC(class_name)
2. After you define the SAF security class, you define resource profiles to control access to the Take
Action commands. (If you do not define any resource profiles, all commands are denied.) To find out
if a user is authorized to issue the Take Action commands directed to the OMEGAMON for z/OS agent,
the OMEGAMON Enhanced 3270 user interface validates the following resource profile:
KM5.msn.TAKEACTION.*
where msn is the managed system name.

At a minimum, you must create a profile by using the pattern shown for the global security class
(RTE_SECURITY_CLASS), and then give update access to the profile to all users who you want to
be able to issue Take Action commands from the OMEGAMON Enhanced 3270 user interface. The
OMEGAMON Enhanced 3270 user interface address space uses SAF validation to find out if a user is
authorized to issue Take Action commands.
3. SAF validation for product-specific commands is performed by the monitoring agent. Create other
profiles for more granular access control.
• To control all OMEGAMON for z/OS Take Action commands on all managed systems, define a profile
named KM5.**.TAKEACTION.*, and then grant access to one or more users or groups.
RDEFINE class_name KM5.**.TAKEACTION.* UACC(NONE)

PERMIT KM5.**.TAKEACTION.* ID(user_id) ACCESS(UPDATE) CLASS(class_name)
• To control the ability to issue all OMEGAMON for z/OS Take Action commands from a monitoring
agent that is running on a system with an SMFID of SYSA and Sysplex name of PLEXA, define a
profile named KM5.PLEXA:SYSA.TAKEACTION.* and then grant access to one or more users or
groups.
RDEFINE class_name KM5.PLEXA:SYSA.TAKEACTION.* UACC(NONE)

PERMIT KM5.PLEXA:SYSA.TAKEACTION.* ID(user_id) ACCESS(UPDATE) CLASS(class_name)
• The memory list/memory zap feature uses these Take Action resource profiles:
– MEMLIST controls the ability to display memory.
– MEMZAP controls the ability to change memory contents.
• To control the ability to display memory from all address spaces running on systems where an
OMEGAMON for z/OS agent is running, define a profile named KM5.**.TAKEACTION.MEMLIST, and
then grant access to one or more users or groups.
RDEFINE class_name KM5.**.TAKEACTION.MEMLIST UACC(NONE)

PERMIT KM5.**.TAKEACTION.MEMLIST ID(user_id) ACCESS(UPDATE) CLASS(class_name)
• To control the ability to modify memory of all address spaces running on the same system as an
OMEGAMON on z/OS monitoring agent that is running on a system with an SMFID of SYSA and
Sysplex name of PLEXA, define a profile named KM5.PLEXA:SYSA.TAKEACTION.MEMZAP, and then
grant access to one or more users or groups.

RDEFINE class_name KM5.PLEXA:SYSA.TAKEACTION.MEMZAP UACC(NONE)
PERMIT KM5.PLEXA:SYSA.TAKEACTION.MEMZAP ID(user_id) ACCESS(UPDATE) CLASS(class_name)
4. When you have added all the GENERIC resource profile definitions to the security class, issue the
following command to refresh the security class and activate the changes:
SETROPTS RACLIST(class_name) REFRESH
PassTicket
Requests to display memory or zap memory require a secured sign-on from the OMEGAMON Enhanced
3270 user interface to the OMEGAMON for z/OS monitoring agent. The interface generates a PassTicket
(that is, a one-time only password), and then sends it to the monitoring agent in the data request. This
enables the monitoring agent to authenticate that the request came from the user who is logged into the
interface.
1. In order for a PassTicket to be generated, the PTKTDATA security class must be activated. To activate
the PTKTDATA class and the SETROPTS RACLIST processing, issue the following command:
SETROPTS CLASSACT(PTKTDATA) RACLIST(PTKTDATA) GENERIC(PTKTDATA)
The PassTicket key class enables the security administrator to associate a RACF secured sign-on
secret key with a particular mainframe application that uses RACF for user authentication. All profiles
that contain PassTicket information are defined in the PTKTDATA class.
2. Define a profile in the PTKTDATA class definition for each OMEGAMON for z/OS monitoring agent which
you want to enable for memory list and/or memory zap functions.
RDEFINE PTKTDATA zOSAgent_STC SSIGNON(KEYMASKED(value))
Replace value with any combination of 16 hex digits, for example:
RDEFINE PTKTDATA zOSAgent_STC SSIGNON(KEYMASKED(0123456789ABCDEF))
3. Grant users and groups access to an OMEGAMON for z/OS profile:
PERMIT zOSAgent_STC CLASS(PTKTDATA) ID(user_id) ACCESS(UPDATE)
Each OMEGAMON for z/OS monitoring agent must also have a resource profile defined to the RACF
application class (APPL). The same users and groups who are permitted to the monitoring agent’s
PTKTDATA profile must also be permitted to the agent's profile defined to the APPL class.
4. To activate the APPL class and the SETROPTS RACLIST processing, issue the following command:
SETROPTS CLASSACT(APPL) RACLIST(APPL)
5. Define a profile in the APPL class for each monitoring agent which you want to enable for memory list
and/or memory zap functions by issuing the following command:
RDEFINE APPL zOSAgent_STC UACC(NONE)
6. Grant the user or group access to the monitoring agent’s APPL profile.
PERMIT zOSAgent_STC CLASS(APPL) ID(user_id) ACCESS(UPDATE)
7. After you have added all the monitoring agent’s resource profile definitions to the PTKTDATA and
APPL security classes, issue the following commands to refresh the security classes and activate the
changes:
SETROPTS RACLIST(PTKTDATA) REFRESH

SETROPTS RACLIST(APPL) REFRESH
Recreate or replace z/OS Management Console situations
If you previously ran z/OS Management Console situations, you can start corresponding situations for
OMEGAMON for z/OS or recreate comparable situations using OMEGAMON for z/OS attributes.
For a list of z/OS Management Console situations and instructions for recreating them with OMEGAMON
for z/OS, or a list of corresponding OMEGAMON for z/OS situations, see Using the predefined situations.
Authorize users to access OMEGAMON for z/OS managed systems on the

enhanced 3270 user interface
On all three 3270 interfaces, logon is controlled through the system authorization facility (SAF) interface.
In addition, the OMEGAMON Enhanced 3270 user interface (enhanced 3270UI) performs SAF checks
on users’ authorization to view data for specific managed systems or managed system types, their
authorization to issue Take Action commands and perform other selected commands and activities.
If no SAF security class is supplied (RTE_SECURITY_CLASS is missing or blank), users can log on to the
enhanced 3270UI, can access data through queries, but cannot issue Take Action commands.
If a SAF security class is supplied, but not defined and active in SAF, no one can log on to the enhanced
3270UI.
If a SAF security class is supplied, and is defined and active in SAF, but no logon profile is defined, no one
can log on to the enhanced 3270UI.
If a user is able to log on, and a different security class than the one used for logon is used for queries
or for Take Action commands (but is not activated or resources are not defined in that security class),
everyone can view data for any managed system and perform other commands and activities, but all Take
Action commands are denied.
If a security class name is configured, resource profiles must be defined to control log on, data access,
and Take Actions, and users must be given access to those profiles.
To define profiles that control access to specific OMEGAMON for z/OS managed systems, you must
specify the managed system names. Sysplex managed system names take the form:
plexname:MVS:SYSPLEX
where plexname is typically the true name of the Sysplex, but might be configured to be an alias for the
Sysplex.
System managed system names take the form:
plexname:smfid:MVSSYS
MVS where plexname is typically the true name of the Sysplex, but can be configured to be an alias.
The smfid component is the true System Management Facility (SMF) ID for the system or LPAR being
monitored.
For instructions on configuring security for the enhanced 3270UI, see the Configuring section in the IBM
Tivoli OMEGAMON and Tivoli Management Services on z/OS Shared Documentation.
For instructions on configuring security for the older 3270 interfaces, see “Securing OMEGAMON” on page
38.
Securing OMEGAMON
Security provides command validation and logon validation.
By default, OMEGAMON command validation is controlled by an internal security table, but can also be
implemented using one of external SAF products. Logon validation for OMEGAMON is provided by one of
the supported external SAF products (see “Securing OMEGAMON for MVS (Realtime collector)” on page
39).

Securing OMEGAMON for MVS (Realtime collector)
Access to OMEGAMON commands is controlled by an internal security table. The security table is
generated from a set of control statements.
The control statements provide the following information:
• If external security is used, the name of the module containing the external security exit routine
(MODULE).
• An authorized screen space library for initialization that bypasses the security check (AUTHLIB).
• If internal security is used, the passwords for each level of security to which commands can be assigned
(PASSWORD).
• The internal security levels of commands, which commands are under control external security, and
whether an audit should be performed (COMMAND).
• The security options for minor commands (MINOR).
The default security module, KOMCM510, is included with LEVEL3 internal security for the following
commands: APFU, CONS, CONU, CSAF, FNDU, KILL, LPAM, MCHN, MDEF, MLST, MSCN, MZAP, OCMD,
RCMD, OSPC, PEEK, QLLA, SCHN, SLST, SSCN, SZAP, XMCH, XMLS, XMSC, XMZP, .DSA, ALIB, ALI, MCTL,
CHAP, MNSW, MSWP, SWPI, TADR, TSNM. All other commands default to a security level of 0.
To change any of the protected commands, secure additional commands, change the passwords assigned
to each level of security, or implement an external security facility, you must edit the control statements in
the &rhilev.&rte.RKANSAMU(KOMSUPDI) member and run the KOMSUPD job to update the security table.
See “Modifying the security table” on page 39 for instructions.
Access to OMEGAMON commands can also be authorized using one of the supported external SAFs, or a
combination of both internal and external security facilities. In addition, an external security facility can
be used to authorize logon to OMEGAMON. If external security is implemented, users can log on to an
OMEGAMON session only if they are allowed access to an “INITIALx” resource name (where x is 0, 1, 2, 3,
or blank) See “Implementing external security for OMEGAMON” on page 40 for instructions.
Modifying the security table

You must edit the security table manually to modify it. You can edit the control statements and run the
job manually. You must repeat this procedure for each runtime environment that requires OMEGAMON
security.
To modify the internal security table, complete the following steps:
1. Edit the control statements in the KOMSUPDI member of &rhilev.&rte.RKANSAMU.
These control statements are described in “OMEGAMON security control statements” on page 46.
Add the LIST=YES statement to create a complete listing of security information.
Note: To switch from external security to internal security, complete the following steps:
a. Add the RESET=MODULE command after your existing MODULE=xxxxxxxx command.
b. Change commands marked EXTERNAL=YES to EXTERNAL=NO.
2. Modify and submit the &rhilev.&rte.RKANSAMU(KOMSUPD) job to update and report on the security
table.
If the update program flags statements as being in error, correct the statements and resubmit job
KOMSUPD.
See “Security update program listing” on page 52 for instructions on interpreting the list of the
control statement modifications. The changes will not affect currently active sessions, but any session
started after KOMSUPD is run uses the new security settings.
3. Move the KOMSUPDI member to a secured data set that only the OMEGAMON for z/OS customizer has
read access to.
4. Modify the RKANSAMU(KOMSUPD) job to point to that new data set.
Note: Any time you run the job to create runtime members, the KOMSUPDI member is regenerated in
RKANSAMU with default values. You can modify the security table in RKANSAMU as described above.
Implementing external security for OMEGAMON

External security authorization facilities (SAF) can be used for both OMEGAMON for MVS (Realtime
collector) log-on authorization and command authorization.
The following external security authorization facilities are supported:
• RACF
• CA-ACF2
• CA-TOP SECRET
If external security is in force, control passes to a user-exit routine at session logon, re-logon, termination,
and when a command is issued (see “Security exit processing logic” on page 53 ). If EXTERNAL=YES
is specified for a command in the CONTROL command statement and no exit routine is available,
OMEGAMON disables the command for the session, if the command has an associated security level
of 0, or defaults to internal security if the command has a security level of 1, 2, or 3. IBM supplies sample
user-exit routines.
To implement security for OMEGAMON using an external authorization facility, complete the following
steps:
1. Set up rules in the external security package to interface with OMEGAMON.
2. Customize, assemble, and link the sample exit routine.
3. Update the security table to specify the use of an external security package and indicate which
commands you want the package to validate.
Table 4 on page 40 shows the name of the sample exit routine for each external security package, and
where to find instructions for implementing each package.
Table 4. Choices of security facilities for implementing OMEGAMON security

Security system Exit name Instructions
RACF KOMRACFX “Securing OMEGAMON with RACF” on page 40
CA-ACF2 KOMACF2X “Securing OMEGAMON with CA-ACF2” on page 42
CA-TOP SECRET KOMRACFX “Securing OMEGAMON with CA-TOP SECRET” on page 44
Securing OMEGAMON with RACF

Implementation of command and logon security using RACF requires three steps.
To implement command and logon security using RACF, complete the following steps:
1. “Set up RACF rules” on page 40
2. “Customize, assemble, and link the KOMRACFX exit routine” on page 41.
3. “Modify the security table for RACF” on page 42
Set up RACF rules

In this step, you set up the RACF rules to interface with OMEGAMON.
Complete the following steps to set up the RACF rules:
1. Update the resource class description table to define a class name (for example, OMCANDLE) using
the ICHERCDE macro call. If you do not use class name OMCANDLE, you must change the security exit
class name to match your new class name (details are provided in the next topic). Code the ICHERCDE
macro as follows:
ICHERCDE CLASS=classname,
ID=nnn,

MAXLNTH=8,
FIRST=ALPHANUM,
OTHER=ANY,
POSIT=nnn,
DFTUACC=NONE
Your configuration determines values for classname and nnn. Your installation may also require
additional operands for this macro.
2. Activate the newly defined resource class.
3. Define an INITIALx resource profile for logging onto OMEGAMON (where x is 0, 1, 2, 3, or blank). For
example:
RDEFINE classnme INITIAL UACC(READ)
The resource name “INITIAL” permits users to change their security level with the /PWD command.
Resource names “INITIAL0” through “INITIAL3” lock users to the highest matching security level
(0, 1, 2, or 3) and prevent the users from changing their level with the /PWD command (this is also
referred to as locking). These security levels are used with OMEGAMON internal security to determine
if a particular command is accessible to a user.
This example shows resource definitions to set a user to security level 2 (first define security level 0, 1,
2, and 3 as inaccessible, and then set USER02 to security level 2):
RDEFINE classnme INITIAL0 UACC(NONE)

PERMIT INITIAL2 CLASS(classnme) ID(USER02) ACC(READ)
4. Define one resource profile for each command you want to protect with RACF (each protected
command will also require the EXTERNAL=YES setting in the security table).
This step is optional. It is required only if you want to add separate external security control for
specific commands. Otherwise, the regular LEVEL=x control is used.
• Use the TSO RDEFINE command and specify the OMEGAMON command as the resource. Be certain
to specify that only specific users may execute the command by setting UACC(NONE).
• Use the PERMIT command to define those users who can access the resource (execute the
command). Give them READ access. The following example shows how to authorize a user to
execute the PEEK command:
RDEFINE classnme PEEK UACC(NONE)

PERMIT PEEK CLASS(classnme) ID(USER01) ACCESS(READ)
• If the command you want to secure begins with a slash (/) or period (.), the RACF rule you define
must start with a dollar sign ($) instead of the slash (/), or an at sign (@) instead of the period (.). For
example, the command /LOGOUT requires a rule for $LOGOUT.
Customize, assemble, and link the KOMRACFX exit routine

In this step, you set up the exit that interfaces with RACF.
Follow these steps to set up the exit:
1. Edit and modify the &rhilev.&rte.RKANSAMU(KOMRACFX) exit.
Be sure that the resource class name in the exit matches the resource class name you defined when
setting up RACF rules. The class name in the exit (default is OMCANDLE) is defined on this instruction
(line 90):
MVC U#CHCLSD,=C’OMCANDLE’ ALTERNATE RESOURCE CLASS NAME
The processing logic for this exit is provided in “Security exit processing logic” on page 53. Many sites
use this exit without modification, but it is documented with comments to facilitate changes.
2. Assemble and link the exit routine. Use the &rhilev.&rte.RKANSAMU(KOMRACFA) job.
Modify the security table for RACF

In this step, you set up the security table to work with RACF.
To set up the security table, complete the following steps.
1. Edit the control statements in the KOMSUPDI member of &rhilev.&rte.RKANSAMU. These control
statements are described in “OMEGAMON security control statements” on page 46.
• Uncomment the MODULE command statement, and enter the name of the exit KOMRACFX on the
MODULE statement as follows:
MODULE=KOMRACFX
• Indicate which commands are to be validated by RACF rules by setting EXTERNAL=YES on the
COMMAND control statements.
• Indicate which commands are to be validated by OMEGAMON internal security levels by setting
LEVEL=n and EXTERNAL=NO on the COMMAND control statements.
Important: To change an existing setting for a parameter, you must specify a new setting, rather than
just blanking out the old setting. For example, to remove a command from external security checking,
change EXTERNAL=YES to EXTERNAL=NO.
2. Modify and submit the KOMSUPD job in &rhilev.&rte.RKANSAMU to update and report on the security
table. If the update program flags statements as being in error, correct the statements and resubmit
the KOMSUPD job.
See “Security update program listing” on page 52 for instructions on interpreting the list of the
control statement modifications.
3. If OMEGAMON (default name IBMM2RC) is currently active, recycle OMEGAMON. Changes made to
the security table are effective only when OMEGAMON has been started after the security update job
completes successfully.
Securing OMEGAMON with CA-ACF2

This section documents the steps required to implement OMEGAMON log-on and command authorization
using CA-ACF2.
To set up OMEGAMON logon and command authorization using CA-ACF2, complete the following steps:
Set up CA-ACF2 rules

In this step, you set up the CA-ACF2 rules to interface with OMEGAMON.
Complete these steps:
1. Define the name of the OMEGAMON started task to ACF2. The name is the started task name
you specified for the realtime collector during configuration (parameter KM2_CLASSIC_STC in the
configuration file).
The started task name must have the MUSASS attribute assigned. This allows ACF2 to check the
individual user’s authorization rather than using the OMEGAMON address space ID.
2. Set up a resource class in CA-ACF2 to allow OMEGAMON to make the security checks. Define a
generalized resource class name, for example OMS. This name will be three characters long for
generalized resources. When you set up the exit, you will need to use this same class name prefixed
with the letter R (for example, the OMS class name needs to be ROMS in the exit).
3. Define a CA-ACF2 rule for resource INITIALx (where x is 0, 1, 2, 3, or blank) to allow users to log on
to OMEGAMON. For example,
ACFNRULE KEY(INITIAL) TYPE(OMS) ADD(UID(*********userid) ALLOW)
where OMS must match the resource class name that you defined, and UID is a user ID or user ID
mask.

The resource name “INITIAL” permits users to change their security level with the /PWD command.
Resource names “INITIAL0” through “INITIAL3” lock users to the highest matching security level (0,
1, 2, or 3) and prevent the users from changing level with the /PWD command (this is also referred
to as locking). These security levels are used with OMEGAMON internal security to determine if a
particular command is accessible to a user.
The following example shows how to set users to specific levels:
ACFNRULE KEY(INITIAL0) TYPE(OMS) ADD(UID(********USER02) ALLOW)

4. Set up a CA-ACF2 rule for each command you want to protect with CA-ACF2 (each protected command
will also require the EXTERNAL=YES setting in the security table: see “Modify security table for
CA-ACF2” on page 43).
The following example shows how to authorize a user to execute the PEEK command (specify the
command name with the KEY operand):
ACFNRULE KEY(PEEK) TYPE(OMS) ADD(UID(********USER01) ALLOW)
If the command you want to secure begins with a slash (/) or period (.), the CA-ACF2 rule you define
must start with a dollar sign ($) instead of the slash (/), or an "at" sign (@) instead of the period (.). For
example, the command /LOGOUT requires a rule for $LOGOUT.
Customize, assemble, and link the KOMACF2X exit routine

In this step, you set up the exit that interfaces with CA-ACF2.
Complete these steps:
1. Edit and modify the exit &rhilev.&rte.RKANSAMU(KOMACF2X).
Be sure that the resource class you set up in the exit has the same name as the ACF2 resource class
you defined, and that it is prefixed with the letter R (for example, OMS class name needs to be ROMS in
the exit).
use this exit without modification.
2. Assemble and link the exit routine. Use sample job &rhilev.&rte.RKANSAMU(KOMACF2A).
Modify security table for CA-ACF2

In this step, you set up the security table to work with CA-ACF2.
Complete the following steps.
1. Edit the control statements in the KOMSUPDI member of &rhilev.&rte.RKANSAMU. These control
statements are described in “OMEGAMON security control statements” on page 46.
a. Uncomment the MODULE command statement, and enter the name of the exit KOMACF2X on the
MODULE=KOMACF2X
b. Indicate which commands are to be validated by CA-ACF2 rules by setting EXTERNAL=YES on the
COMMAND control statements.
c. Indicate which commands are to be validated by OMEGAMON internal security levels by setting
To change an existing setting for a parameter, you must specify a new setting, rather than just blanking
out the old setting. For example, to remove a command from external security checking, change
EXTERNAL=YES to EXTERNAL=NO.
2. Modify and submit job KOMSUPD in &rhilev.&rte.RKANSAMU to update and report on the security
job KOMSUPD. See “Security update program listing” on page 52 for a description of the update
program report.
The changes will not affect currently active sessions, but any session started after KOMSUPD is run will
use the new security settings.
Securing OMEGAMON with CA-TOP SECRET

Implementation of command and logon security using TOP SECRET requires three steps.
Set up CA-TOP SECRET rules

In this step you set up the TOP SECRET rules to interface with OMEGAMON.
Complete the following steps:
1. Define a FACILITY statement for the started task for the realtime collector as a facility in the Facility
Matrix Table. If the name you define in the FACILITY statement is different from the started task name,
see the CA-TOP SECRET documentation for information on setting up the FACILITY statement.
The following example shows FACILITY statements from a CA-TOP SECRET installation (some of these
statements may not be relevant to your system, and others may need modification):
FACILITY(USER3=NAME=task)
FACILITY(task=MODE=FAIL,ACTIVE,SHRPRF)
FACILITY(task=PGM=KOB,NOASUBM,NOABEND,NOXDEF)
FACILITY(task=ID=3,MULTIUSER,RES,WARNPW,SIGN(M))
FACILITY(task=NOINSTDATA,NORNDPW,AUTHINIT,NOPROMPT,NOAUDIT)
FACILITY(task=NOTSOC,LOG(INIT,SMF,MSG,SEC9))
The SIGN parameter on the FACILITY statement must be specified as SIGN(M), or TOP SECRET may
revoke user access. Also, verify that MODE=FAIL is set, and the MULTIUSER parameter has been
included.
2. Add the facility to users, as follows:
TSS ADDTO(useracid) FACILITY(cccccccc)
where cccccccc is the started task name you specified for the realtime collector during configuration
(parameter KM2_CLASSIC_STC in the configuration file).
3. Define a resource class to the RDT (Resource Descriptor Table), as follows:
TSS ADDTO(RDT) RESCLASS(KOMCANDL) RESCODE(nn)
where nn is any hexadecimal code between 01 and 3F.

4. Give ownership to class KOMCANDL, prefixed with INITIAL, as follows:
TSS ADDTO(deptacid) KOMCANDL(INITIAL)
5. Define PERMIT rules for resource INITIALx (where x is 0, 1, 2, 3, or required blank) to allow users to
log on to OMEGAMON, as in the following example:
TSS PERMIT(useracid) KOMCANDL(‘INITIAL ’) (trailing blank is required)
6. The resource name “INITIAL ” (with required blank) permits users to change their security level
with the /PWD command. Resource names “INITIAL0” through “INITIAL3” lock a user to the highest
matching security level (0, 1, 2, or 3) and prevent that user from changing that level with the /PWD
command (this is also referred to as locking). These security levels can be used with OMEGAMON
internal security to determine if a particular command is accessible to a user.
The following example shows how to set users to specific levels:
TSS PERMIT(useracid) KOMCANDL(INITIAL0) (level 0 commands)

7. Set up a rule for each command you want to protect with CA-TOP SECRET (each protected command
will also require the EXTERNAL=YES setting in the security table).
This step is optional. Perform this step only if you want to add separate external security control for
specific commands. Otherwise, the regular LEVEL=x control is used.
This example permits a user to use the PEEK command:
TSS PERMIT(useracid) KOMCANDL(PEEK)
If the command you want to secure begins with a slash (/) or period (.), the CA-TOP SECRET rule you
define must start with a dollar sign ($) instead of the slash (/), or an at sign (@) instead of the period (.).
For example, the command /LOGOUT requires a rule for $LOGOUT.
Customize, assemble, and link the KOMRACFX exit routine

In this step, you set up the exit that interfaces with TOP SECRET.
To set up the exit that interfaces with TOP SECRET, complete the following steps:
1. Edit and modify the exit &rhilev.&rte.RKANSAMU(KOMRACFX) as follows:
a. Remove both APPL=M$APPL parameters where they appear in the RACROUTE macro calls.
b. Replace this line:
MVC U#CHCLSD,=C’OMCANDLE’ ALTERNATE RESOURCE CLASS NAME
with the following instructions:
MVI U#CHCLS,X’08’ MVC U#CHCLSD,=C’KOMCANDL’
use this exit without modification, but it is documented with comments to facilitate changes.
2. Assemble and link the exit routine. Use the &rhilev.&rte.RKANSAMU(KOMRACFA) sample job.
Modify security table for CA-TOP SECRET

In this step, you set up the security table to work with CA-ACF2.
To set up the security table, complete the following steps.
1. Edit the control statements in the KOMSUPDI member of &rhilev.&rte.RKANSAMU. These command
statements are described in “Security exit processing logic” on page 53.
a. Uncomment the MODULE command statement, and enter the name of the exit KOMRACFX on the
MODULE=KOMRACFX
b. Indicate which commands are to be validated by CA-TOP SECRET rules by setting EXTERNAL=YES
on the COMMAND control statements.
c. Indicate which commands are to be validated by OMEGAMON internal security levels by setting
To change an existing setting for a parameter, you must specify a new setting rather than just
blanking out the old setting. For example, to remove a command from external security checking,
change EXTERNAL=YES to EXTERNAL=NO.
2. Modify and submit job KOMSUPD in &rhilev.&rte.RKANSAMU to update and report on the security
job KOMSUPD. See “Security update program listing” on page 52 for a description of the report.
The changes will not affect currently active sessions, but any session started after KOMSUPD is run will
use the new security settings.
OMEGAMON security control statements

An internal security table controls access to OMEGAMON for MVS (realtime collector) commands. The
security table is generated from a set of control statements that specify whether security is internal or
external, determine which commands are protected, set the security level for those commands, and set
the passwords for each level of security.
The sections that follow explain the control statements and associated keywords you use to modify the
security table. The following information is provided for each control statement:
• Purpose of the control statement
• Format of the control statement
• Acceptable keywords
• Restrictions for the control statement (if any)
• Other information that is specific to the control statement (if any)
General format rules for control statements

These general format rules apply to all control statements:
• Control statements can begin anywhere in the input record, but cannot extend beyond column 72.
• Statements can be in any order in the input stream.
The update program processes the statements as it encounters them, with the exception of the LIST
and UPDATE statements, which take effect after the update program processes all other input.
• All information for a particular control statement must fit on a single line.
• All input must be in uppercase letters.
• Statements must be in the format:
CONTROLSTATEMENT=cccccccc,KEYWORD1=cccccccc,KEYWORD2=cccccccc, etc.
There can be no intervening blanks. The update program treats data that follows a blank as a comment.
This data prints on the control statement listing, but is ignored for processing purposes.
• To insert comment lines anywhere in the input stream, place an asterisk (*) in column 1 of the input
record.
• If the update program flags statements as being in error, correct the statements and submit them again.
To change a setting, you must specify a new setting instead of blanking out the old setting. This is
especially important to remember when changing a command from EXTERNAL=YES to EXTERNAL=NO.
• The changes will not affect currently active sessions, but any session started after the KOMSUPD job is
run will use the new security settings.
The control statement listing should indicate successful completion of the update.
COMMAND
The COMMAND control statement specifies the name of an OMEGAMON major, immediate, or INFO-line
command that you want to protect. OMEGAMON protects minor commands at the level of its major
command unless you specify the MINOR control statement.
When you update an INFO-line command, you must use the actual command name and not its alias.
OMEGAMON automatically assigns the same protection attributes to all aliases of the command.
OMEGAMON always processes the last COMMAND statement for the command. OMEGAMON does not
check for multiple COMMAND statements for the same command in the same run.

Syntax
The syntax of COMMAND is
COMMAND=
{cccc|.ccc|/cccccc}
[,LEVEL={0|2|3|DISABLE}]
[,EXTERNAL={YES|NO}]
[,AUDIT={WTO|SMF|BOTH|NONE}]
where cccc, .ccc, or /cccccc is the name of the OMEGAMON command you want to protect.
To have the control statement listing show the current security settings for a command, enter a
COMMAND=cccc,=.ccc, or =/cccccc statement with no additional operands.
Keywords
COMMAND accepts the following keywords:
LEVEL
Specifies the internal security level associated with this command.
• Level 0 allows the command to execute without an internal security check.
• Levels 1, 2, and 3 specify that the command executes only if you have previously entered the
corresponding password for that level (or for a higher level) using the /PWD INFO-line command, or
were locked to that level via external security.
• DISABLE specifies that OMEGAMON is never to execute the command.
You can audit attempts to execute the command for the session, but you cannot specify internal or
external security.
EXTERNAL
Specifies whether an external security package checks this command.
Note: You can configure external security (to control logon to OMEGAMON and to lock users to a
particular command level) without having to specify EXTERNAL=YES on any commands. If you do
specify EXTERNAL=YES, you must define separate rules to control access to that command.
OMEGAMON ignores the EXTERNAL keyword if you specify LEVEL=DISABLE.
If you code EXTERNAL=YES for a command and no exit routine or rule is available, OMEGAMON does
one of the following things:
• Disables the command for the session if it has an associated security level of 0
• Defaults to internal security if the command has a security level of 1, 2, or 3
After you specify EXTERNAL=YES, you can change EXTERNAL only by specifying EXTERNAL=NO and
rerunning the security update program.
AUDIT
Specifies whether OMEGAMON is to audit the command each time a user invokes it. The possible
values are:
WTO
Produces a one-line message on the master console.
SMF
Specifies that OMEGAMON write an SMF record. You must specify the SMF record number in the
SMFNUM control statement.
If OMEGAMON cannot perform the SMF audit, OMEGAMON defaults to a WTO audit. See “The
System Management Facilities audit” on page 55 for details about setting up the SMF audit.
BOTH
Specifies that OMEGAMON issue a WTO message to a console and write an SMF record.
NONE
Specifies no auditing. This is the default setting.
If you specify an audit for a disabled command, OMEGAMON notifies you of attempts to execute the
command.
LIST
The LIST control statement specifies whether the security update program produces a security file listing.
OMEGAMON allows only one LIST statement per run. The default is LIST=NO.
A security file listing is a complete record of the security table that shows the following information:
• The name of the authorized screen library
• Security file volume serial number
• The name of the user exit module
• All command names, along with their corresponding security information
A security file listing does not list the internal security passwords.
If you also specify UPDATE=NO, the listing shows what the control statements and security information
would look like if the update had taken place.
To generate the security file listing independent of edits to the control statements, submit LIST=YES as
the only control statement in the input stream.
Syntax
The format of LIST is LIST={YES|NO}
MINOR
The MINOR control statement specifies the name of an OMEGAMON minor command you want to protect.
OMEGAMON protects the minor commands independently of the majors. Therefore, any changes to minor
commands apply to all minors with the same name and attributes, regardless of their major commands.
Access to a minor command requires access to the appropriate major command. If you do not specify an
EXTERNAL keyword, the associated major command controls access to this minor command.
No check is made for multiple MINOR statements for the same minor command in the same run. The last
MINOR statement for the minor takes effect.
Syntax
The format of MINOR is
MINOR=cccc
[,LEVEL={1|2|3|DISABLE}]
[,EXTERNAL={YES|NO}
[,AUDIT={WTO|SMF|BOTH|NONE}
where cccc is the name of the minor command to be protected.
Keywords
MINOR accepts the following keywords:
LEVEL
Specifies the internal security level you want to associate with this command.
Level 0
Allows the command to execute without an internal security check.
Levels 1, 2, and 3
Specifies that the command execute only if you have previously entered the corresponding
password for that level (or for a higher level), using the /PWD INFO-line command.

DISABLE
Specifies that OMEGAMON is never to execute the command.
If you specify this value, you can audit attempts to execute the command for the session, but you
cannot specify internal or external security.
EXTERNAL
Specifies whether an external security package checks this command.
Note: You can configure external security (to control logon to OMEGAMON, and to lock users to a
particular command level) without having to specify EXTERNAL=YES on any commands. If you do
specify EXTERNAL=YES, you must define separate rules to control access to that command.
OMEGAMON ignores the EXTERNAL keyword if you specify LEVEL=DISABLE.
If you code EXTERNAL=YES for a command and no exit routine or rule is available, OMEGAMON does
one of the following:
• Disables the command for the session if it has an associated security level of 0
• Defaults to internal security if the command has a security level of 1, 2, or 3
Once you specify EXTERNAL=YES, you can change EXTERNAL only by specifying EXTERNAL=NO and
rerunning the security update program.
AUDIT
Specifies whether OMEGAMON is to audit the command each time a user invokes it. The possible
values are:
WTO
Produces a one-line message on the master console.
SMF
Specifies that OMEGAMON write an SMF record. You must specify the SMF record number in the
SMFNUM control statement.
If OMEGAMON cannot perform the SMF audit, OMEGAMON defaults to a WTO audit.
See “The System Management Facilities audit” on page 55 for details about setting up the SMF
audit. This option requires APF-authorization.
BOTH
Specifies that OMEGAMON issue a WTO message to a console and write an SMF record.
NONE
Specifies no auditing. This is the default setting
If you specify an audit for a disabled command, OMEGAMON notifies you of attempts to execute the
command.
MODULE
The MODULE control statement specifies the name of the module that contains the external security exit
routine. You must specify the MODULE parameter for an external security check to take place. There is no
default.
Syntax
The format of MODULE is:
MODULE=cccccccc
where cccccccc is the name of the module that contains the external security exit routine.
Be sure that this name matches the load module name you specified in KOMACF2X or KOMRACFX.
PASSWORD
The PASSWORD control statement specifies the 1- to 8-character password for each internal security
level that you want to use with the /PWD command.
You must use a separate PASSWORD control statement for each security level.
Use unique passwords for each security level. If you assign the same password to more than one level,
OMEGAMON will match it only at the lowest level and deny access to commands protected at higher
levels.
When you enter a valid password for one security level, OMEGAMON allows access to commands secured
at that level and to commands secured at lower levels. OMEGAMON checks the password for a match in
the following order:
1. Level 1
2. Level 2
3. Level 3
Syntax
The format of PASSWORD is
PASSWORD=password,LEVEL={1|2|3}
where password is the unique password for this level.
Keywords
PASSWORD accepts the following keyword:
LEVEL
Specifies the security level you want to associate with this password.
OMEGAMON requires a level for a password.
Levels 1, 2, and 3 specify that the command executes only if you have previously entered the
corresponding password for that level (or for a higher level), using the /PWD INFO-line command.
RESET
The RESET control statement clears the current settings of the other control statements. Reset
commands remain unprotected unless you specify new settings with the appropriate control statements
and rerun the update program.
Only one RESET statement is allowed per run.
Syntax
The format of RESET is
RESET=keyword
where keyword is one of the keywords described in the following section.
Keywords
RESET accepts the following keywords:
ALL
Clears settings for all control statements and all keywords in the OMEGAMON security table.
AUTHLIB
Clears the name and volume serial number of the authorized library.

INFO
Clears settings for all INFO-line commands (on the COMMAND control statement).
For example, if you do not want to use the IBM default security levels for INFO-line commands and
want to start over, enter RESET=INFO. For INFO-line commands, this resets all LEVEL settings to
security level 0 and also clears any existing EXTERNAL and AUDIT settings.
MAJOR
Clears settings for all major and immediate commands (on the COMMAND control statement).
MINOR
Clears settings for all minor commands.
MODULE
Clears the name of the security exit routine module.
PASSWORD
Clears the internal passwords.
SLASH
Clears settings for all INFO-line commands (on the COMMAND control statement).
For example, if you do not want to use the IBM default security levels for INFO-line commands and
want to start over, enter RESET=SLASH. For INFO-line commands, this resets all LEVEL settings to
security level 0 and also clears any existing EXTERNAL and AUDIT settings.
SMFNUM
Clears the record number for SMF audits.
YES
Clears settings for all control statements and all keywords in the OMEGAMON security table.
SMFNUM
The SMFNUM control statement indicates the ID number of the SMF record that OMEGAMON should use
for its audit. The SMF audit is intended for use only with commands that could disrupt the system (for
example, OCMD and MZAP). Use the SMF audit selectively because of its high overhead.
When creating the SMF audit, make sure that the SMF Record Exits (IEFU83 and IEFU84) and the SMF
system parameters specifications (SMFPRMcc) do not suppress the ability for OMEGAMON to journal the
audit activity records. The KOBSMFRP member of the &rhilev.&rte.RKANSAM data set contains a sample
SMF post-processor and report generator in source code format. This is supplied as an example only.
Syntax
The format of SMFNUM is
SMFNUM=nnn
where nnn is the SMF record ID number.

The ID number you assign to OMEGAMON must be between 128 and 255, inclusive, and should be
different from the number that any other application is using. There is no default.
UPDATE
The UPDATE control statement specifies whether OMEGAMON updates the control statements during this
run. OMEGAMON allows only one UPDATE statement per run.
Syntax
The format of UPDATE is UPDATE={YES|NO}
UPDATE=NO specifies that this run of the security update program should be a trial run.
Security update program listing
The security update program produces a listing of control statement modifications. If you specify the
LIST=YES control statement, an additional report is produced that includes all security information.
The security update program listing has four parts.
• Header
• Edited control statements
• Security files
• Update trace
Header
The header contains the following information:
• The name of the data set where the load module is located.
• The name of the module containing the security table (KOMCMnnn).
• The OMEGAMON version number in the format VnnnCOM.
• Messages indicating successful completion of the job or error conditions, such as a failure to open the
SYSLIB data set or read the security table.
Edited control statements

The update report contains a listing of the control statements that have been edited. The listing shows
the previous contents (except for previous passwords), as well as the new contents. If you specified
UPDATE=YES, OMEGAMON reports the date and time of the previous update.
The codes for the PREVIOUS CONTENTS and NEW CONTENTS of commands are positional. There are
three positions:
1. The first position shows the number of the internal security level or an asterisk (*) if the command has
been DISABLED.
2. The second position shows the external security option:
E
Use external security for this command.
b
A blank indicates no external security.
3. The third position shows the auditing option:
W
Audit this command via WTO.
S
Audit this command via SMF.
B
Audit this command via WTO and SMF.
b
A blank indicates no auditing.
Security files
If you specify LIST=YES anywhere in the input stream, the security update program generates a
complete listing of the security information, including the name of the authorized screen library and
its volume serial number, the name of the external security user exit module, the SMF record number, and
all of the commands along with their security information. The listing does not show the internal security
passwords.
TYPE specifies the following kinds of OMEGAMON commands:

C
Major
I
Immediate
S
Slash (INFO-line)
The security level follows the command. An asterisk (*) indicates that a command has been disabled.
Minor commands are listed following their corresponding majors.
Update trace
The last part of the listing indicates whether an update has successfully completed.
Accessing authorized commands

You can access authorized commands using the /PWD command.
To gain access to the authorized commands, use the /PWD command in the following manner:
1. Type /PWD on the INFO-line.
When you press Enter, OMEGAMON responds with the password prompt.
2. Type your password on the INFO-line.
The password does not display as you type it.
3. Press Enter.
The PASSWORD ACCEPTED message displays.
4. Press Enter.
OMEGAMON provides access to all authorized commands associated with that password, as well as
lower command levels.
If you are using OMEGAMON with an external security package to authorize commands, you can prevent
the use of the /PWD command. The resource name “INITIAL” permits users to change their security level
with the /PWD command. Resource names “INITIAL0” through “INITIAL3” lock a user to the highest
matching security level (0, 1, 2, or 3) and prevent that user from changing their level with the /PWD
command (this is also referred to as locking). These security levels are used with OMEGAMON internal
security to determine if a particular command is accessible to a user.
The /PWD command also controls the relogon function. The relogon feature is a function of the /PWD
command that allows you to enter a user ID and password to the external security package from an
active OMEGAMON session. This allows you to alter the security level of your session without stopping
your session. (See the IBM OMEGAMON for z/OS: OMEGAMON for MVS Command Reference for details on
the /PWD command).
Changing your security level to issue authorized commands

To issue an authorized command, your session security level must be equal to (or greater than) the level
defined in the security table for that command. You can change your security level if necessary.
To change your session security level:
• From an OMEGAMON session, enter the /PWD command.
Security exit processing logic

If you are using an external security product (RACF, CA-ACF2, or CA-TOP SECRET) for OMEGAMON
security, you need to use a security exit routine.
Table 5 on page 54 gives the name of the exit for each of the support external security programs. The
following sections describe the processing logic for the exit routines.
Table 5. Security exit routines for external command-level security
Product Exit routine
RACF &rhilev.&rte.RKANSAMU(KOMRACFX)
CA-TOP SECRET &rhilev.&rte.RKANSAMU(KOMRACFX)
CA-ACF2 &rhilev.&rte.RKANSAMU(KOMACF2X)
$UCHECK
Communication between OMEGAMON for MVS (Realtime collector) and the exit routine is done through
the control block $UCHECK and exit return codes. The control block $UCHECK is mapped by the
&rhilev.&rte.TKANMAC(KOBGMAC) macro. OMEGAMON maintains the $UCHECK control block for the
entire life of the session.
At the end of $UCHECK is a 512-byte work area set up for your installation’s own use. If you require
a work area larger than 512 bytes, GETMAIN additional storage and place a pointer to this storage in
$UCHECK. If you modify the RACF RACROUTE macro, you must GETMAIN at least 512 bytes for use as
the WORKA parameter.
Initialization exit call sequence

A series of exit calls is done at OMEGAMON initialization:
1. At initialization, when OMEGAMON passes control to the exit routine, the initialization call is indicated
by an I in the U#CHTYP field. This indicates a logon validation request. 2
2. If the user ID field length is nonzero, the user ID and password information are available.
3. If additional information or some form of retry is required, the routine can request a reshow of the
screen, and reset any field lengths to indicate that no data is present (user ID, password, group, or new
password).
4. To perform a reshow in VTAM mode, set a message into the U#CHMSG field (120 bytes maximum
length), set the U@CHRSHO bit in U#CHRESP, and return to the caller. The message appears after the
panel. Appropriate fields are filled in (original user ID and password), unless overridden (length = 0).
5. When validation is complete, a return code of 0 from the user exit indicates that the user should be
allowed to log on. Any other return code will cause the session to be aborted.
6. Upon successful logon acceptance, the exit may perform resource validation and optionally assign a
command security level (0, 1, 2, or 3) to the user (default is 0). Place the appropriate number into
U#CHAUT4. To lock the user to this level, also set the U@CH1LOK bit in U#CHAUT1.
Command verification exit call sequence

The following sequence of exit calls is done at command verification:
1. During command verification, OMEGAMON places a C in the U#CHTYP field.
2. The user’s authorization can be checked.
3. The decision to allow or disallow a command on the first encounter cannot be changed on subsequent
tries by the same user, unless security is reset with the /PWD command. However, on each try, the user
exit is notified; an audit record may be written, and a customized error message may be issued.
Return codes from the exit routine may be one of the following:
0
Indicates that the command is allowed.
4
RACF only: Indicates that the command is unknown to RACF. OMEGAMON will allow the command
to execute.

8
Indicates that the command is known to the external security package, and access is denied.
4. When you authorize commands, OMEGAMON modifies the command name by replacing the slash of
INFO-line commands with a dollar sign (/cccccc becomes $cccccc), and the period of immediate
commands with @ (.ccc becomes @ccc).
Re-logon exit call sequence

The following sequence of exit calls is done at re-logon:
1. At re-logon, OMEGAMON places an R in the U#CHTYP field to indicate a logon validation.
2. The processing is the same as at initialization, except that users may not enter a new password or
group because OMEGAMON does not display a logon panel.
Termination exit call sequence

At termination, OMEGAMON passes a T to the user’s exit routine. You can then do any termination
cleanup required, such as freeing user control blocks and FREEMAINing any GETMAINed areas.
The System Management Facilities audit

You can generate a System Management Facilities (SMF) audit report that logs OMEGAMON logon activity
and command authorization.
The SMF record contains:
• IBM header (IFASMFR maps)
• OMEGAMON Common Header ($CANHDR maps)
You define these maps in member KOBGMAC of &thilev.TKANMAC.
• Security audit record ($AUDIT maps)
You define these maps in member KOBGMAC of &thilev.TKANMAC.
The audit record contains:
• Date/time/system stamp
• User ID/job name associated with the session
• Actual command text as you entered it on the screen
Records of minor commands also reference their associated major commands.
CAUTION: The SMF audit has a high overhead, so use it sparingly. Because the overhead for
producing SMF records is high, you should use the audit only with sensitive commands, such as
those that could disrupt the system (for example, ICMD and IZAP).
To generate the SMF report, follow these steps:
1. Copy the &thilev.TKANSAM(KOISMFEX) member to &rhilev.&rte.RKANSAMU(KOISMFEX).
Modify KOISMFEX, following the instructions in the member.
2. Copy the &thilev.TKANSAM(KOISMFRP) member to &rhilev.&rte.RKANSAMU(KOISMFRP).
Modify KOISMFRP to meet your site’s needs.
3. Copy the &thilev.TKANSAM(KOISMFA) member to &rhilev.&rte.RKANSAMU(KOISMFA). Modify
KOISMFA, following the instructions in the member.
4. Use the &rhilev.&rte.RKANSAMU(KOISMFA) member to assemble and link your program.
5. Submit the job for execution.
If you generate a SMF audit report, make sure that both of the following actions occur:
• SMF record exits (IEFU83 and IEFU84)
• The SMF system parameters specifications (SMFPRMcc) do not suppress the ability of OMEGAMON
realtime collector to log the audit activity records.
Verifying the configuration

After you have completed any required configuration, verify the configuration to ensure that you have
correctly configured the product and its components.
Before you can verify your configuration of OMEGAMON for z/OS, the following tasks must be completed:
• The Tivoli Enterprise Portal must be installed and configured, and application support for OMEGAMON
for z/OS must be installed on the portal server and any desktop clients installed from the media rather
than downloaded using WebStart.
• The hub Tivoli Enterprise Monitoring Server must be installed and configured, and application support
for OMEGAMON for z/OS must be installed on it.
• The remote monitoring server to which an OMEGAMON for z/OS agent reports must be installed and
configured.
If use of RMF data collection is configured, the RMF Distributed Data Server (DDS) must be started and
RMF Monitor III tasks must be started in all LPARs in this Sysplex. OMEGAMON for z/OS must be enabled
to connect to the DDS using the RACF PassTicket service. If near-term history data collection is enabled,
one or more OMEGAMON subsystem address spaces per Sysplex must be started and enabled to connect
to the DDS using the RACF PassTicket service.
To verify the configuration, complete the following steps. (See “Copy started task procedures to your
procedure library” on page 23 for the names of the started tasks.)
1. If the Tivoli Enterprise Monitoring Server in this runtime environment is not already running, vary the
monitoring server VTAM major node active and start the monitoring server started task. The monitoring
agent starts when the monitoring server starts
2. If the hub Tivoli Enterprise Monitoring Server is not already running, start it.
3. If the OMEGAMON subsystem is not already running, start it.
4. Use a Tivoli Enterprise Portal client to log on to the hub.
When Tivoli Enterprise Portal launches, you see the managed system name of any Sysplexes you have
configured listed under the z/OS Systems entry in the Navigator. Sysplex managed system names take
the form plexname:MVS:SYSPLEX where plexname is either the true name of the Sysplex or an alias for
the Sysplex, depending upon how you configured it.
5. Click a Sysplex.
The Sysplex Enterprise Overview workspace appears.
6. Verify that data for the system or systems you configured is being displayed.
Tip
OMEGAMON for z/OS started tasks can be started with the z/OS START command REUSASID=YES
parameter. Use this parameter with the components that are likely to leave address spaces with unusable
ASIDS: that is, the OMEGAMON Subsystem and the CSA Analyzer.

Support information
If you have a problem with your IBM software, you want to resolve it quickly. IBM provides the following
ways for you to obtain the support you need:
Online
Go to the IBM Software Support site at http://www.ibm.com/software/support/probsub.html and
follow the instructions.
Troubleshooting Guide
For more information about resolving problems, see Introduction to troubleshooting.

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.
For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property
Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation

Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
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 might 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.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the
exchange of information between independently created programs and other programs (including this
one) and (ii) the mutual use of the information which has been exchanged, should contact:
IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758 U.S.A.

Such information may be available, subject to appropriate terms and conditions, including in some cases
payment of a fee.
The licensed program described in this document and all licensed material available for it are provided by
IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any
equivalent agreement between us.
If you are viewing this information in softcopy form, the photographs and color illustrations might not be
displayed.
Trademarks
IBM, the IBM logo, and ibm.com® are trademarks or registered trademarks of International Business
Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked
terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these
symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information
was published. Such trademarks may also be registered or common law trademarks in other countries.
A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at
http://www.ibm.com/legal/copytrade.shtml.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon,
Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or
its subsidiaries in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, and service names may be trademarks or service marks of others.
Privacy policy considerations

IBM Software products, including software as a service solutions, (“Software Offerings”) may use cookies
or other technologies to collect product usage information, to help improve the end user experience,
to tailor interactions with the end user or for other purposes. In many cases no personally identifiable
information is collected by the Software Offerings. Some of our Software Offerings can help enable you
to collect personally identifiable information. If this Software Offering uses cookies to collect personally
identifiable information, specific information about this offering’s use of cookies is set forth below.
Depending upon the configurations deployed, this Software Offering may use session cookies that
collect each user’s user name for purposes of session management, authentication, and single sign-on
configuration. These cookies cannot be disabled.
If the configurations deployed for this Software Offering provide you as customer the ability to collect
personally identifiable information from end users via cookies and other technologies, you should seek
your own legal advice about any laws applicable to such data collection, including any requirements for
notice and consent.
For more information about the use of various technologies, including cookies, for these purposes,
See IBM’s Privacy Policy at http://www.ibm.com/privacy and IBM’s Online Privacy Statement at http://
www.ibm.com/privacy/details the section entitled “Cookies, Web Beacons and Other Technologies”
and the “IBM Software Products and Software-as-a-Service Privacy Statement” at http://www.ibm.com/
software/info/product-privacy.

IBM®
Product Number: 5698-T01
SC27-4028-02

Omxezos551 Planandconfig

Uploaded by

Copyright:

Available Formats

Omxezos551 Planandconfig

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Omxezos551 Planandconfig

Uploaded by

Copyright:

Available Formats

IBM OMEGAMON for z/OS

Planning, Upgrading, and Configuration

1. Deployment of OMEGAMON for z/OS in a multiplex environment...............................................................8

3. Tasks to complete before configuring OMEGAMON for z/OS.....................................................................17

4. Choices of security facilities for implementing OMEGAMON security.......................................................40

5. Security exit routines for external command-level security...................................................................... 54

Software and hardware requirements

Supported operating systems

© Copyright IBM Corp. 2004, 2022 1

Prerequisites for data collection and display

Table 1. Data prerequisites

2 IBM OMEGAMON for z/OS: Planning, Upgrading, and Configuration

Cryptographic attributes At least one IBM® cryptographic coprocessor is installed and

DASD MVS™ workspace and DASD RMF has been started.

Using RMF data collection

4 IBM OMEGAMON for z/OS: Planning, Upgrading, and Configuration

Near-term historical RMF data in Fix Pack 6 and later

Near-term historical RMF data before Fix Pack 6

Management of near-term history data collection

6 IBM OMEGAMON for z/OS: Planning, Upgrading, and Configuration

where stcname is the OMEGAMON subsystem started task name

Planning configuration of OMEGAMON for z/OS

Designating the Sysplex and Plexview proxy

Figure 1. Deployment of OMEGAMON for z/OS in a multiplex environment

8 IBM OMEGAMON for z/OS: Planning, Upgrading, and Configuration

Planning historical data collection

Configuring the historical data stores for OMEGAMON for z/OS

Persistent data store version 1

Persistent data store version 2

Determining DASD requirements for storing historical data

Historical data collection and reporting

10 IBM OMEGAMON for z/OS: Planning, Upgrading, and Configuration

Viewing and exporting historical data

Attribute groups for RMF Near Term History

Before you begin configuration

Table 2. Preconfiguration tasks

Complete any preinstallation requirements. Preinstallation Requirements and Instructions

Verify that no user-defined ICSF service call See note.

12 IBM OMEGAMON for z/OS: Planning, Upgrading, and Configuration

Upgrading to the new release

Configuring a high availability hub and converting a static hub to a

Enabling new features

© Copyright IBM Corp. 2004, 2022 13

Performing a staged upgrade

14 IBM OMEGAMON for z/OS: Planning, Upgrading, and Configuration

Configuring OMEGAMON for z/OS

Table 3. Tasks to complete before configuring OMEGAMON for z/OS

© Copyright IBM Corp. 2004, 2022 17

Configure an OMEGAMON Subsystem Configuring section in the IBM Tivoli OMEGAMON

18 IBM OMEGAMON for z/OS: Planning, Upgrading, and Configuration

Configuring security for Take Action commands

Configuring the OMEGAMON for z/OS agent to use RMF data

RMF for near-term history data collection in earlier versions

Turning off zIIP offload

Sending messages for proxy switch to the console

Specifying MIM names

20 IBM OMEGAMON for z/OS: Planning, Upgrading, and Configuration

Update the IEFSSNxx member of SYS1.PARMLIB

Update the LINKLIST