Beruflich Dokumente
Kultur Dokumente
Environment
SG24-5500-00
SG24-5500-00
Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix E, Special notices on page 389.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Information Technology environment . . . . . . . . . . . . . . .
1.2 Evolution of ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 ERP - The backbone of e-business . . . . . . . . . . . . . . . .
1.4 SAP - The leading ERP vendor . . . . . . . . . . . . . . . . . . .
1.5 What is SAP R/3?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6 A brief history of Tivoli . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7 SAP management challenges. . . . . . . . . . . . . . . . . . . . .
1.8 The Tivoli Management Environment . . . . . . . . . . . . . . .
1.9 Tivolis management solution for SAP R/3 . . . . . . . . . . .
1.10 Tivoli Product Architecture . . . . . . . . . . . . . . . . . . . . . .
1.11 Summary of Tivolis management solutions . . . . . . . . .
1.11.1 Tivoli Management Framework . . . . . . . . . . . . . . .
1.11.2 Tivoli Distributed Monitoring . . . . . . . . . . . . . . . . .
1.11.3 Tivoli Enterprise Console . . . . . . . . . . . . . . . . . . .
1.11.4 Tivoli Software Distribution . . . . . . . . . . . . . . . . . .
1.11.5 Tivoli Manager for SAP R/3 . . . . . . . . . . . . . . . . .
1.11.6 Tivoli Decision Support . . . . . . . . . . . . . . . . . . . . .
1.11.7 Tivoli Global Enterprise Manager . . . . . . . . . . . . .
1.11.8 Tivoli Application Performance Manager. . . . . . . .
1.11.9 Tivoli Database Management Products. . . . . . . . .
1.11.10 Tivoli Manager for MQSeries . . . . . . . . . . . . . . .
1.11.11 Tivoli Workload Scheduler . . . . . . . . . . . . . . . . .
1.11.12 Tivoli User Administration . . . . . . . . . . . . . . . . . .
1.11.13 Tivoli Global Sign-On . . . . . . . . . . . . . . . . . . . . .
1.11.14 Tivoli Security Management (Lockdown Module)
1.11.15 Tivoli Storage Manager (Tivoli ADSM) . . . . . . . .
1.11.16 Tivoli Output Manager . . . . . . . . . . . . . . . . . . . .
1.11.17 Tivoli NetView. . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .1
. .1
. .2
. .2
. .3
. .3
. .7
. .8
. .8
. .9
. 10
. 11
. 15
. 15
. 15
. 16
. 16
. 19
. 21
. 25
. 31
. 33
. 35
. 36
. 37
. 40
. 42
. 43
. 46
iii
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . 52
. . 54
. . 54
. . 62
. . 64
. . 66
. . 69
. . 70
. . 71
. . 78
. . 83
. . 84
. . 84
. . 85
. . 85
. . 88
. . 89
. . 90
. . 90
. . 99
. 103
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 119
. 119
. 120
. 120
. 121
. 122
. 128
. 128
. 140
. 151
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 163
. 163
. 163
. 168
. 183
. 184
. 186
....
....
jobs
....
....
....
....
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
. 188
. 189
. 194
. 199
. 219
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 227
. 227
. 230
. 230
. 230
. 231
. 236
. 237
. 240
. 240
. 240
. 241
. 241
. 242
. 259
. 260
. 260
. 261
. 264
. 264
. 268
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 271
. 271
. 273
. 274
. 293
. 293
. 294
. 295
. 296
. 297
. 298
. 299
. 304
. 305
. 306
......
......
......
......
......
......
......
.
.
.
.
.
.
.
347
347
349
353
357
358
358
vi
vii
viii
Figures
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
ix
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
xi
xii
xiii
xiv
Tables
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
xv
xvi
Preface
Effective management of a large-scale SAP R/3 environment requires that
each layer of the underlying IT infrastructure - networks, systems, databases,
middleware, and applications - be addressed under a single, integrated, and
centralized monitoring and reporting environment. Using this
multidisciplinary, "big picture" approach, companies can remain proactive in
deploying and monitoring SAP applications and the associated infrastructure
components that may impact access to business critical data.
Tivolis management products for SAP R/3 build on core Tivoli management
applications and support the Tivoli approach to unified, comprehensive
enterprise management. This approach allows R/3 to be managed as part of
the enterprise and with the same tools that are used to manage the entire
enterprise. Tivoli Enterprise software allows organizations to simplify the
management of complex environments with offering like the Tivoli
management solution for R/3, enabling continual operation of systems that
drive customers' businesses.
In this redbook, we describe the intricacies of managing a large-scale SAP
R/3 environment using the Tivoli Enterprise Software products. Special
attention is given to the cornerstone of Tivolis solution for R/3 management The Tivoli Manager for R/3. This redbook details the setup and use of the
latest version (2.0) of the Tivoli Manager for R/3. In addition, we also focus on
the other components of Tivolis comprehensive solution for SAP
management. These products include Tivoli Database Manager Product that
enables management of SAPs underlying database, Tivoli Decision Support
for SAP R/3 that enables an analysis of SAP R/3 system activities, Tivoli
Application Performance Management that allow you to measure SAP R/3
performance, as well as Tivoli Global Enterprise Manager that enables a
business systems topology view of the SAP environment.
Detailed scenarios are documented for use by customers or service providers
in client engagements.
xvii
xviii
Poonam Dhawan
Tivoli Systems
Bill Meloling
Tivoli Systems
Ellen Dickson
Tivoli Systems
Ron Cherveny
Tivoli Systems
Stefan Uelpenich
Tivoli Systems
Angela Pitts
Tivoli Systems
Jay Kruemcke
Tivoli Systems
Monte Copeland
Tivoli Systems
Tom Haywood
Tivoli Systems
Charles Brown
IBM UK
Carsten Siegler
IBM Germany
David A White
IBM Global Service
Delmos Gaier
IBM Gloval Service
Gene Capano
IBM Gloval Service
Greg Greth
IBM Gloval Service
xix
Cyndi Chapman
IBM Gloval Service
John Owczarzak
International Technical Support Organization, Austin Center
Comments welcome
Your comments are important to us!
We want our redbooks to be as helpful as possible. Please send us your
comments about this or other redbooks in one of the following ways:
Fax the evaluation form found in IBM Redbooks evaluation on page 409
to the fax number shown on the form.
Use the online evaluation form found at http://www.redbooks.ibm.com/
Send your comments in an internet note to redbook@us.ibm.com
xx
Chapter 1. Introduction
In this chapter, we introduce the SAP R/3 application system and the Tivoli
management strategy for applications in general and for SAP R/3 specifically.
We give a brief overview of the current business data processing situation
and provide an explanation of enterprise resource planning. Also included is
an overview of any additional modules to the Tivoli Enterprise Solution that
were implemented during the course of this project. This includes a
description of the new features in the Tivoli Solutions.
resources, high performance, and expansive scalability. The limit of the ability
to develop such systems is reached only when reliable system management
and stable operation of the system as a whole can no longer be guaranteed.
Introduction
Database
Server
Application
Servers
Presentation Clients
Figure 1. SAP R/3 three tier architecture
R/3 is platform independent. The three components listed previously can all
run on different operating systems including Windows NT and all major UNIX
platforms.
Database System
Operating System
DB2
Oracle
Windows NT
All Major UNIX Platforms
Informix
Windows NT
All Major UNIX Platforms
Windows NT
Access to the R/3 system is achieved by a presentation client, often called the
SAPGUI, which is available on all major operating system platforms and is a
stand-alone package. Users log in from presentation clients to the R/3
application servers via the SAPGUI. The application servers, in turn,
communicate with the database server. Application servers can also run on
Windows NT and all major UNIX platforms.
SAPGUI is available for the platforms listed previously and additionally for
Windows 95, Windows 98 and OS/2. The following figure shows an example
of the initial login screen of the SAPGUI on Windows 95 or Windows 98:
Introduction
R/3 has many additional components that have not even been mentioned
here, such as SAPGUI servers and ITS.
Introduction
Problem Management
Centralized correlation of
network, system, database,
and application events
Performance management
Operations Management
Workload scheduling
Output management
Service Management
Service level agreements
Escalations/notifications
Knowledge content
Decision Support
Service level management
Business relevant analysis to
drive policies, budgets, resource
allocations
Security Management
Centralized user
administration
Access control
Global sign-on
ERP
Storage Management
Fast, reliable restore / backup
Disaster recovery management
Change Management
Planned IT rollouts
Impact analysis to avoid
potential problems
Automated software
distribution
Introduction
solution combines specialized products such as Tivoli Manager for R/3, Tivoli
Workload Scheduler Extended Agent for SAP R/3, and Tivoli Service Desk for
R/3 with Tivolis standard management products. These products include
Tivoli Enterprise Products; Tivoli Distributed Monitoring for event
management and Software Distribution; Tivoli Database Manager Product;
Tivoli Manager for MQSeries; Tivoli Service Desk to manage problems,
changes, and assets; Tivoli Global Enterprise Manager (GEM) for managing
enterprise applications; Tivoli Security Management and Tivoli Global
Sign-On for enhanced security, plus Tivoli Workload Scheduler for job
scheduling; Tivoli Output Manager; and Tivoli Data Protection for SAP R/3 for
backup and recovery R/3 data (refer to Figure 4).
Workload
Scheduling
Output
Management
Service Desk
ies
Se r
Q
M
Middleware
Management
Desktop
Management
Oracle
\60
5
3
30
Database
Management
5
\6
10
Service Levels
ERP
Management
15
25
Security
Management
20
User
Administration
Legacy system
DB2
Figure 4. Tivolis integrated solution - SAP R/3 management
10
Tiv o li
S oftw a re D is tribu tio n
Tiv o li
E n te rp rise C o n s o le
Tiv o li
M a e s tro
Tiv o li
D e c is io n
S u p p o rt
P o lic ie s
S e c u rity
Tiv o li
Inv e n to ry
Tiv o li
F ra m e w o rk
Tiv o li
A p p lic a tio n
P e rfo rm a n c e
M an ager
D a ta
M e s s a g in g
Tiv o li
G lo b a l
E n te rp ris e
M ana ger
T iv o li
S e c u rity
M an age m ent
Tiv o li
O u tp u t
M an age r
Tiv o li
ADSM
Tivo li
D is trib u te d M o n ito rin g
Tiv o li
U se r A d m in is tra tio n
Tivoli
Solution
Tivoli
Manager for
R/3
Description
Prerequisite
Key Strengths
Specialized SAP
monitors, software
distribution file-packs,
CCMS event mapping,
automation rules, tasks,
and classes.
Tivoli Framework
Tivoli Software
Distribution
Tivoli Enterprise
Console
Tivoli Distributed
Monitoring
Breadth of R/3
management
functions. Integration
with application,
system, and network
management. Secure
interface to R/3.
Introduction
11
Tivoli
Solution
12
Description
Prerequisite
Key Strengths
Tivoli
Distributed
Monitoring
Event correlation,
management, and
automated response,
which apply policy
across the enterprise.
Tivoli Framework
Breadth of platforms.
Scalability. Flexibility
for defining events and
filtering views.
Tivoli
Enterprise
Console
Presents event
information and is the
launching pad for
management tasks.
Tivoli Framework
Tivoli Global
Enterprise
Manager
Provides a business
system view that allows
management and
control of multiple
integrated software
components required to
deliver a specific
business service.
Tivoli Framework
and core
applications
Tivoli Global
Sign-On
Tivoli Framework
Tivoli User
Administration
Tivoli Software
Distribution
Tivoli
Workload
Scheduler
n/a
Tivoli
Solution
Description
Prerequisite
Key Strengths
Tivoli
Decision
Support
Tivoli Framework
Tivoli Enterprise
Console
Integrates disparate
data from multiple
sources to examine
key indicators from a
variety of angles.
Tivoli
Database
Manageme
nt
Products
Tivoli Framework
Tivoli Software
Distribution
Tivoli Enterprise
Console
Tivoli Distributed
Monitoring
Database breadth
including DB2,
Microsoft SQL Server,
Oracle, Sybase, and
Informix.
Tivoli
Manager for
MQSeries
Centralized
management of IBM
MQSeries. Provides
software distribution,
administration, and
configuration of
MQSeries
n/a
Business system
perspective.
Out-of-band
MQSeries health
monitoring.
Multidomain, cross
platform
administration.
Correlates events
outside MQSeries.
Tivoli
Software
Distribution
Tivoli Framework
Breadth of Platforms
covered. Scalability.
Tivoli Output
Manager
n/a
Introduction
13
Tivoli
Solution
14
Description
Prerequisite
Key Strengths
Tivoli ADSM
Provides centrally
managed and scheduled
storage management
and disaster recovery
backup for R/3 and any
other enterprise data.
n/a
Tivoli
Application
Performanc
e Manager
Uses Application
instrumentation,
Transaction simulation,
and Client capture in
conjunction with a
back-end process for
managing the measured
data.
Tivoli Framework
Tivoli
Netview
Tivoli Framework
Tivoli User
Administrati
on
Tivoli Framework
Centralized
GUI-based control of
administration tasks.
Consistent
administrative policy
definition. Automation
of repetitive
administration tasks.
Tivoli
Security
Manageme
nt
(Lockdown
Modules)
A system or application
specific Tivoli Security
Profile that can be
modified to match an
environment, applied
on an endpoint, and
then tested to lockdown
a specific system or
application.
Tivoli Framework
Tivoli Security
Management
Introduction
15
16
Note
The Tivoli Manager for R/3 used during the course of this redbook was a
beta code version. The versions of SAP R/3 that are supported by this
product are subject to change at any time before or after release of the
module.
The R3System name used in this redbook has dbhostname_SID, while the
actual product has SID_dbhostname.
1.11.5.1 Availability and Performance
The ability to productively use the R/3 system depends on many resources
including databases, application servers, networks, and even the R/3 client
software on workstations. Tivoli Manager for R/3 provides more than 250
monitors for R/3, in addition to thousands of monitors provided by Tivoli
Enterprise.
The monitors provide capability for automated monitoring of the R/3 systems.
For example, one of the monitors periodically checks for processes that have
been running too long - a common indication of a more serious problem.
Tivoli Manager for R/3 automatically detects this potentially serious situation
24 hours a day, 7 days a week.
Monitors are only one source of information about the R/3 systems. SAP
maintains a system log (syslog) that contains detailed information about the
workload and events within the R/3 system. Via the R/3 Syslog Event
Adapter, Tivoli provides automated access to information in the SAP syslog.
You can define which syslog messages, including severity, should be sent to
Tivoli Enterprise Console. Because Syslog Event Adapter filtering and event
severity are conducted outside of R/3, you can employ common syslog event
standards for multiple R/3 systems without having to configure each R/3
system. The Syslog Event Adapter can process every syslog event, even
when several events occur simultaneously.
1.11.5.2 Proactive Problem Detection
Tivoli Manager for R/3 proactively identifies potential problems before they
affect R/3 users using a comprehensive collection of monitors and events.
The information is collected from several sources including R/3's
SAPOSCOL, Tivoli Distributed Monitoring, and information available through
the R/3 Computing Center Management System (CCMS). The important
information from across the R/3 landscape and supporting components is
correlated by the Tivoli Enterprise Console if you have configured properly.
This means that it is possible to prevent many R/3 alert situations from
Introduction
17
happening and automate actions for specified problems using the rules
mechanism.
Monitors included with Tivoli Manager for R/3 provide information about CPU
utilization, CPU load average, available physical memory, paging, swap
space, disk utilization and response time, and all other values displayed by
the R/3 transaction ST06. Tivoli Manager for R/3 also displays information
concerning the R/3 memory subsystem including roll and page area statistics.
Other monitors provide information on buffer utilization, allocated memory,
database accesses, directory entry information, hit ratio, and all other values
displayed by R/3 transaction ST02. For the DB2 database on OS/390, Tivoli
tracks additional values including buffer pool-hit ratios, shortages and page
information, and deadlock and lock time outs.
1.11.5.3 Efficient Operations
With Tivoli's unique policy-based management approach, you can securely
delegate routine activities to junior personnel. Tivoli's single action
management and automation saves your time by simplifying operational
tasks. Tivoli Manager for R/3 provides a variety of operational tasks as well
the ability to easily add additional tasks to further increase administrator and
operator efficiency.
Automation
Tivoli enables easy automation of routine tasks such as shutting down the
system for backups, clearing old logs, and restarting stopped printers. It
simplifies IT administrators operations and reduces workload.
Speeding R/3 deployment and accommodating change
Tivoli provides the software distribution capabilities to deploy new versions of
the SAP client code (SAPGUI) quickly and efficiently to thousands of
end-user workstations. Companies can also save time and accelerate the roll
out of the SAPGUI to hundreds or thousands of end-user workstations by
utilizing Tivoli Manger for R/3.
Tivoli Manager for R/3 also provides facilities to manage changes in the R/3
server environment. Capabilities include autodiscovery of new R/3 systems
and servers, generic monitors and tasks that apply to multiple R/3 systems,
and an architecture that is scalable to meet the growing/changing SAP
environment.
Tivoli Manager for R/3 builds on core Tivoli management applications and
supports the Tivoli approach to unified, comprehensive enterprise
management. This approach allows R/3 to be managed as part of the
18
enterprise and with the same tools that are used to manage the entire
enterprise. Operators can easily manage R/3 and other enterprise
components from one point and without the need for R/3 expertise.
For more detailed information about the features and functions of the Tivoli
Manager for SAP R/3, see Chapter 2, What is new: Tivoli Manager for R/3
Version 2.0 on page 49, Chapter 4, Planning and implementation on page
119 and Chapter 5, Managing SAP R/3 environment on page 163.
Introduction
19
The following list provides sample questions found in the Decisions Support
Guide for application performance:
What is an acceptable response?
Which users and locations are impacted?
Which component of the end-to-end of the application environment is
affected?
Which application server or application modules are affected?
20
Introduction
21
22
Scenario:
Sales Force
Automation
Server
CICS
System
Introduction
23
impact2:
understood in real time
Business
Scenario
R&D System
Manufacturing
System
MQ Series
Link for R/3
Queue
Manager
HQ System
Human Resources
System
Sales System
24
Introduction
25
endpoint, usually the users PC that has replaced the old terminals, has
become an important factor.
The factors listed previously have all made the task of managing performance
increasingly difficult. However, because of the relatively low cost to add more
servers or new LAN segments, organizations have managed the problem in
the past by simply adding more resources to overcome performance drops.
As the underlying infrastructure becomes more robust, application
architectures are evolving to become more complex. In current times, three,
and even four-tier, architectures are not unusual. Users are accustomed to
being able to move large blocks of data without actually being aware of
exactly how much data is involved. The number of servers organizations have
is steadily increasing from dozens to hundreds and even to thousands. The
number of clients is often many times greater than the number of servers an
organization has. Organizations are finding it more difficult to know where to
deploy resources and what effect that will have on the performance of each
application. The gradual degradation of infrastructure performance is one of
the biggest problems that organizations face.
The traditional areas of performance measurement are as follows:
Application instrumentation
This involves modifying applications so that they make calls to the Application
Response Measurement (ARM) API. The ARM can be implemented in a
measurement agent, which clocks the elapsed time from the start to the end
of a transaction. This enables the measurement of actual business
transactions without any excess overhead. This also means that the
application instrumentation can be controlled by the developers.
26
Client capture does not require modifications to the source code, and it does
not create artificial loads. Therefore, it is often described as non-invasive.
However, closer inspection of how it is implemented shows that this is not the
case. It is actually quite invasive. This comes from a requirement for
deploying sensors across the environment as well as overhead associated
with capturing and processing events.
The challenge of providing a robust client capture solution is a large one. The
event patterns that are the signature for a transaction can change from
release to release. It is possible that there may be many different patterns
that all indicate the same transaction. Unless client capture is implemented
very carefully, it can overlook subtle changes in the event patterns and
provide inaccurate results.
Network X-Ray
This method uses probes that attach to the network and sniff packets. This
means that they are able to look inside data streams and find clues to the
type of transaction that is executing. The time between the start and the end
of the transaction is measured.
Introduction
27
Start
Application
Using ARM
Stop
Measurement
Agent
Start
Transactions
Simulating
Applications
Stop
Client Capture
Sensor
Application
Sensor
Event
Filter
Event
Transactions
Analyzer
Sensor
28
Introduction
29
decisions. This approach maximizes the value of the limited staff available to
analyze performance and capacity.
Tivoli Application Performance Manager achieves the following:
Seamlessly integrates with the best-of-breed tools for benchmarking
performance in prototypes and pilot deployments. The pilots use stress
testing to assess the network and server capacity prior to deployment in a
production environment. For example, these tools show how long
transactions take and how long the sub-transaction calls to other servers
take. Tivoli Application Performance Manager uses the transactions
employed in the stress test phase to simulate transactions for ongoing
monitoring. This avoids the creation of a new set of transactions for
monitoring purposes and allows comparisons between expected
performance and actual performance.
Reports on Service Level Agreements (SLAs). SLAs are a fundamental
building blocks of a good process. They provide a way to measure the
process, and they are important tools for executives looking at the value
chain from a business perspective.
Provides online monitoring and status reporting versus thresholds.
Automation routines can be established so that, in the event of a threshold
being exceeded, corrective action can be performed. The correlation of
events related to application performance along with those events related
to applications, databases, systems and networks, enable the quick
identification of the cause of a failure or shutdown.
Provides an at-a-glance view of service levels for one or all of the
applications in an enterprise. This is done in conjunction with the GEM
Console, thus providing a business-system perspective.
Provides ready-to-use solutions for popular applications. These solutions
do not need to be configured; however, they can be customized and
extended. Solutions are initially focused on the simulation of transactions,
followed by the use of client capture on the same or similar transactions.
Includes an extensible solution for custom applications and unique
environments. Service providers, consultants, and other skilled users can
add value by building or customizing solutions for specific customer
environments, such as developing instrumentation for specific applications
and developing reports tailored to an application or an installation.
Integrates with other Tivoli products. To manage the performance of
distributed applications effectively requires integration of other data, such
as network topology, system inventory, events, and problem reports.
30
The Tivoli Manager for DB2 is the strategic follow-on to the two IBM DataHub
products, DataHub for OS/2 and DataHub for UNIX OS, and the IBM DB2
Enterprise Control Center for Tivoli (DB2 ECC) product. The functions
provided by the two DataHub products on UNIX, OS/2, and Windows NT have
been incorporated and enhanced in DB2 UDB.
1.11.9.2 Tivoli Manager for Oracle
The Tivoli Manager for Oracle is designed for organizations with large,
heterogeneous database installations. It is primarily designed to aid two
groups of people inside the enterprise:
1. The IT Operations staff who are charged with maximizing the availability of
database resources.
2. The DBAs responsible for managing the efficiencies of, access to, and the
content of database resources.
Commercial database products, such as Oracle, play a business-critical role
in practically all computing environments. For the operations staff, the Tivoli
Manager for Oracle greatly reduces the overhead of ensuring that database
Introduction
31
For example, the following figure (Figure 10) shows an example of database
management in most customer environments.
Scenario:
Databases play a vital role in ERP application systems. If the database has
some trouble, it immediately affects the response time of the ERP
applications that are using the database. As a result, end-users call the
32
operator; however, the operator cannot detect and resolve the problem.
Finally, an IT administrator is called and has to detect and correct the
problem. This inefficient process will be repeated each time the database has
a problem. Normally, it takes a long time to recover, and the cost of the IT
administrator is very expensive. Tivoli Database Manager Products can be a
powerful solution for this problem.
Management
Proactive
Scenario
1:
Tivoli
Distributed
Monitoring /
DB Managers
Tivoli
Enterprise
Console
Introduction
33
Management
Service
34
Function
Benefits
Automated
Software
Distribution
Provides pre-distribution
checks for system resources
and dependencies, disk space,
memory, OS level and network
configuration, automated
distribution and installation of
MQSeries software to remote
MQSeries nodes, and
post-distribution validation.
MQSeries
Configuration
Comprehensive
Monitoring
Comprehensive monitoring
ensuring the availability of
MQSeries networks upon which
your business-critical
applications depend.
Management
Service
Function
Benefits
Centralized
MQSeries
Management
Allows administrators to
manage multi-domain,
cross-platform, and
enterprise-scale MQSeries
networks from one centralized
point.
Rules-Based
Event
Correlation
Automated
Operations
Provides lights-out
management.
End-to-end
MQSeries
Management
Tivoli Global
Enterprise
Manager
Integration
Allows MQSeries to be
managed as a component of
larger business systems.
Introduction
35
The following table lists some of the features available in Tivoli Workload
Scheduler and their advantages to the R/3 user.
Table 4. Some advantages of Tivoli Workload Scheduler for R/3
Selected Feature
Function
Advantage
Central console
Cross-application
support
Allows scheduling
dependencies between
disparate system.
Fault tolerance
Rule-based
processing
Introduces advanced
scheduling features into the
SAP R/3 environment through
Tivoli Workload Scheduler.
36
Introduction
37
A Global Sign-On server uses the services of the Kerberos Security Registry
to securely manage the user information. This includes user definition and
identification and the extended registry attributes capabilities for storage of
user information.
It is possible to have more than one Global Sign-On server; however, only
one server will service the clients. This server is known as the Master server;
all other servers are know as Replica servers. If the Master server fails, then
clients can connect to a Replica server, which will have assumed the role of
the master server and retrieve the information they require. This is the
concept of a replicated environment and clustering similar in operation to
Lotus Notes.
Tivoli Global Sign-On Client
The Global Sign-On Client runs on the users workstation and interacts with
the Global Sign-On server. These workstations then also become known as
Global Sign-On Clients. These can be either PC Managed Nodes or Managed
Nodes.
Introduction
39
profile. Additionally, the user account information can be populated from, and
distributed to, the Global Sign-On server.
Tivoli Global Sign-On Target
A Global Sign-On target is an application or system that a user wishes to
access. Targets are classified into different target types. These types identify
the target by application name, such as MVS, AIX, DB, and so forth.
Tivoli Global Sign-On Supported Platforms
The Global Sign-On User Administration, Plus Module, Server, and Database
Server can be installed on any of the following operation systems:
40
Facility (RACF). Once all the resources that are required to complete the task
have been identified, they can all be listed in a role and the relevant access
rights given. Tivoli security groups can then be formed based around a job
title, and those groups can then be given all the roles they need in that
position.
Once it is configured, an administrator does not have to be concerned with
granting access to a user to resources of many different types on many
different systems. Instead, an administrator adds the user to the Tivoli
security group, and all the access rights are granted during the next security
profile distribution through the role relationships. The time saved in
administration once Tivoli Security Management is in place can be significant.
1.11.14.1 Lockdown Modules
A Lockdown Module is a way of defining a security profile that can be easily
altered, expanded, and, most importantly, be reused in another location.
Some Lockdown Modules can be ready made for products, such as Windows
NT, the Oracle RDBMS, Lotus Domino, and SAP R/3. A Lockdown Module will
include the definition of roles that provide the required level of access to
perform different tasks with the subject application or operating system. An
ideal Tivoli Security Management implementation places users in as few
groups as possible.
Groups
Romsey_IT_Manager
Romsey_Server_Admin
Roles
Soton_Server_Admin
AIX_Admin
Webserver_Admin
Payroll_DB_View
Company_Employee
Customer_DB_View
Customer_DB_Update
The example in Figure 12 shows how groups can be used to represent job
titles in an organization and how the tasks people perform define access
rights through roles. The Soton server administrator has access to resources
similar to the Romsey server administrator, with the additional role of
managing the Web server. The Romsey IT manager has access to additional
Introduction
41
information, for example, the payroll database, as well as higher than average
access for the customer database.
A Lockdown Module is a system or application specific Tivoli Security Profile
that can be modified to match an environment, applied on an endpoint, and
then tested to lockdown a specific system or application.
Building Lockdown Modules breaks down the security management task into
each application or operating system that requires protection. Each module
defines Tivoli security roles that can be given to groups to enable them to
perform tasks that would otherwise be restricted. Tivoli security groups and
roles are one area of the module that is likely to require some customizing to
integrate into your security model.
Note
42
The Tivoli Storage Manager connection to SAP R/3 allows the customer to
back up their SAP R/3 database and archive their SAP R/3 application data
with one utility.
1.11.15.1 Tivoli Data Protection for SAP R/3
Tivoli Data Protection for SAP R/3, (formerly called BACKINT/ADSM), is the
leading solution for high performance data backup and recovery within the
SAP R/3 area. It is seamlessly integrated with Tivoli Storage Manager and
SAP R/3 and is part of the Tivoli Storage Management Product Family.
Tivoli Data Protection for SAP R/3 protects vital system data as a reliable,
high performance, automated backup and recovery solution. It enables
system administrators to more efficiently manage the large volumes of data
involved in system operations and it facilitates the most efficient use of
resources. System administrators can follow SAP procedures and use the
integrated SAP utilities (SAP DBA: BRBACKUP, BRARCHIVE, and
BRRESTORE) for backup and restore.
Introduction
43
Fax
Engineering
Web
Manufacturing
Executive
Product
Requirements
Web
Revenue
Forecast
Marketing
Mix
Marketing
Sales
Figure 13. Typical output environment
44
Domain component of Tivoli Output Manager, and can cause LAN network
traffic.
The consoles will show all the alerts of the defined resources in the output
network. The consoles are also used to monitor output activity and track it
closely and pro-actively.
1.11.16.2 Controlled Access of Output Resources
Administrators and users are defined across all the output resources for
global policy adherence and consistency. These definitions are distributed
and activated throughout the output network and are done by administrators
with the needed security profile.
The rule engine can also respool and extract archive documents to output
resources if duplicates are detected. This is very useful for streamlining the
output environment and prevents large reports from duplicating over slow
network links between distribution centers.
1.11.16.4 Reliable and Secure Output Channels
The delivery path for the users workstation to the output resource is always in
an encrypted form. The packets flowing between the users workstation and
the output destination are not visible for LAN sniffers and packet analyzers.
This provides a good way to deliver documents over the Internet safely and
securely.
Tivoli Output Manger provides definitions for secure output resources. This
allows the users to rely on the output network for delivery to all the secure
devices if their favorite device is off-line.
The secure output channels are defined by the administrator and allow
specific users or groups, like the executive team, to use these printers.
Introduction
45
46
Introduction
47
48
All examples in this book regarding Version 2.0 of Tivoli Manager for R/3
are performed with the pre-GA version of the product. Therefore, some
detailed feature may be changed without notice. Please check with your
IBM or Tivoli representative for further information.
The R3System name used in this redbook has dbhostname_SID, while the
actual product has SID_dbhostname.
49
File Package
TEC Rule Base
GEM Instrumentation
R/3 Object
The following figure (Figure 15) shows the relationship between R/3 Manager
and each of the components.
GEM
Instrumentation
Sentry Monitor
Indicator
Task
File Package
Profile Manager
Policy Region
TEC Rule Base
As you can see, each component is based on Tivoli core applications, such
as TEC Rules or Distributed Monitoring monitors. To perform R/3
management operations, R/3 Manager uses these Tivoli core application
functions efficiently. This is the reason why R/3 Manager requires these Tivoli
core applications as its prerequisite. The following figure (Figure 16) shows
the relationship between Tivoli core applications and R/3 Manager.
50
Application Proxy
Software Distribution
Distributed Monitoring
Other Products
As you can see, to install, configure, and customize R/3 Manager properly,
the knowledge and experiences of Tivoli core applications are mandatory.
In this redbook, we will not explain basic concepts of Tivoli or Tivoli core
applications. If you need more detailed information on Tivoli or Tivoli core
applications, you can refer to the following redbooks:
All About Tivoli Management Agents, SG24-5134
51
picture of how the R/3 environment is performing and helps operators quickly
identify and resolve the cause of any availability problems.
52
These new tasks make the management and control of R/3 systems via Tivoli
much easier and quicker.
2.2.1.5 New Monitors for Work Processes and Cancelled Batch Jobs
It is now possible with this new version of the Tivoli Manager for R/3 to
monitor work processes. This includes the ability to monitor the process
count, watch for queued work processes, and monitor long running
processes. It also includes a monitor for cancelled batch jobs.
2.2.1.6 User-Configurable Syslog Event Adapter
The Syslog Event Adapter processes the R/3 syslog file and converts new
entries into TEC events; so, it is possible to configure the types of events to
watch for. These can then be converted into Tivoli Enterprise Console events
for display to operators. The syslog event adapter also allows the ability to get
TEC events based on the R/3 syslog messages. The Syslog Event Adapter
obtains syslog messages through the R/3 RFC interface, therefore, the
Syslog Event Adapter must log on to the R/3 system. The Syslog Event
Adapter uses the same R/3 user ID information as the wr3rfc-based functions
(please refer to 4.3.4.6, Configuring the RFC on page 145 for more
information).
53
54
SID-specific indication
New resource roles of R/3 Manager
2.3.1.1 New Icons and Nesting Level
The changes on Tivoli Desktop are obvious, and you can recognize them
easily when you open the Tivoli Desktop. On the Tivoli Desktop, you will
notice that several new icons are added. We will introduce the changes on the
Tivoli Desktop and the new nesting level perspective.
55
If you open the new R/3 Manager policy region (Manager for R/3), you find
the following objects, which are shown in Figure 18.
R3_Indicators (Indicator Collection)
R3 Configuration (Policy Region)
R3 App Server Monitors (Profile Manager)
R3 DB Server Monitors (Profile Manager)
R3 Managed Node Monitors (Profile Manager)
R3 Transports (Profile Manager)
R3 App Server Tasks (Task Library)
R3 DB Server Tasks (Task Library)
R3 System Tasks (Task Library)
If you open the R3 Configuration policy region and go down to the lower
hierarchy, it contains the following objects:
R3 System List (Profile Manager)
R3 Configuration Tasks (Task Library)
56
If you open the R/3 system icon, you can find either the R/3 application
server icon or R/3 database server icon, or both the R/3 application server
icon and R/3 database server icon. In the following example (Figure 20), the
R/3 application server and database server are configured on the same
system, therefore, both the R/3 application server icon and the database
server icon are displayed.
57
One more new feature is that the application server provides the extra
indicator, which shows the status of the application server graphically. We will
introduce this feature in the Improvement of status report on page 69; so,
please refer to it for more information.
2.3.1.2 Monitors and Tasks without SID-Specific Indication
As we mentioned, Version 2.0 of R/3 Manager simplifies many R/3 system
management operations. In this section, we introduce how the structure
simplifies your management operations and improves maintainability and
scalability.
58
For example, in the prior version of R/3 Manager environment, if you would
like to distribute a monitoring profile or task to the three different R/3 systems
that have different SIDs, you need to configure three different profiles even if
the setting of each profile is the same. The following figure (Figure 21) shows
this situation.
TMR Server
AAA
SID "AAA"
BBB
CCC
SID "BBB"
SID "CCC"
R/3 System
Figure 21. Distributing monitors and tasks in prior Version of R/3 Manager
On the other hand, in Version 2.0 of R/3 Manager environment, you need to
create just one profile and distribute the profile to the three R/3 systems that
have different SIDs (refer to the Figure 22) because you do not need to
specify the SID for each task or monitor anymore.
59
TMR Server
SID "AAA"
SID "BBB"
SID "CCC"
R/3 System
Figure 22. New format of distributing monitor and tasks
Once you complete the installation of Version 2.0 of R/3 Manager, it creates
the following three new resource roles that can be assigned to each Tivoli
administrator.
r3_user
r3_senior
r3_admin
The following figure (Figure 23) shows the new resource roles that are
provided by Version 2.0 of R/3 Manager.
60
R/3
Authorization
Role
Basic Tivoli
Authorization
Role
Authority
r3_user
user
r3_admin
admin
r3_senior
senior
To use the wr3rfc functions and syslog event adapter, you must configure an
SAP R/3 user ID so that you can access the RFC interface. The Configure
Remote Function Call task in the R/3 Configurations Tasks task library
configures the user ID and password to use during accessing the RFC
function. Once the configuration task has been done, the password is stored
in the Tivoli database in encryption form, and it is never shown in text again.
61
62
Note
63
TEC Server
Manager for R/3
Application Proxy
DM/TEC/SD
FW
TMR Server
Manager for R/3
Application Proxy
DM/TEC/SD
FW
TMA
EPGW A
Manager for R/3
Application Proxy
DM/TEC/SD
FW
Application Server
TMA
t
ec
dir
Re
MN
Manager for R/3
DM/TEC/SD
FW
DB Server
TMA
EPGW B
Manager for R/3
Application Proxy
DM/TEC/SD
FW
TMA
Application Server
For example, a task executed against the R/3 server object (which exists
physically on a Managed Node) needs to get redirected down to the actual
TMA hosting the R/3 server. The Application Proxy understands how to
redirect tasks and Distributed Monitoring profiles. Therefore, Application
Proxy redirects the task execution request to the appropriate TMA by referring
the Tivoli object database. As you can see, Application Proxy simplifies R/3
Manager operations. Please refer to the Advanced knowledge of Tivoli
Manager for R/3 on page 90 for more information about Application Proxy.
Note
64
looking at the graphics, they can easily understand the status of each
component or relationships between each managed resource. The Tivoli
GEM server displays your business system information graphically.
Consequently, you can graphically monitor, control, and configure your
business system. The following figure (Figure 25) shows a Tivoli GEM
console screen.
To use Tivoli GEM for your SAP R/3 management, you need to install Version
2.0 of Tivoli Manager for R/3 and Tivoli GEM Instrumentation for Tivoli
Manager for R/3 (Tivoli Manager for R/3 Instrumentation) and configure them.
Please refer to the Chapter 7, Examples of new features in SAP R/3
Management on page 271 for more information about Tivoli GEM.
65
The automatic discovery function is also useful when you move your R/3
application server from one machine to another machine or when the SAP
R/3 configurations or allocations in your environment are changed frequently.
Automatic discovery provides the schedule list that can set the automatic
discovery function to run regularly. The schedule list is useful in keeping
up-to-date configuration information in your SAP R/3 management
environment. The following figure (Figure 26) shows an example of the
schedule list.
66
67
following figure (Figure 27) shows the R/3 system icon that is automatically
created by the automatic discovery function.
Automatic discovery also collects information about your R/3 system, such as
R/3 system SID or R/3 system release. You can see the properties of the R/3
system by displaying the pull down menu at the R/3 system icon. The
following figure (Figure 28) shows an example of the R/3 system properties.
68
The automatic discovery function works only when the application server is
available. Therefore, we recommend that you check the status of the
application server before performing automatic discovery. Then, the
automatic discovery should work fine.
69
Icon Status
Description
Icon without any indicator on the lower right corner.
R/3 application server is up and accepting logons.
As you can see, the mark on the right corner indicates each status of the
application server. Although the previous version of R/3 Manager showed no
state at all, the status icon of Version 2.0 of R/3 Manager can provide detailed
status information. In the previous version of R/3 Manager, the status icon
only showed whether the application server was up or down.
Note
70
In Version 2.0 of R/3 Manager, there are tables that contain multiple columns,
and the columns are of different data types. For example, we now process the
work process table in Version 2.0 of R/3 Manager. This table, in R/3 Manager,
has both character columns and integer columns. Prior to this change, we
would not be able to display this table by using the wr3rfc command. With
Version 2.0 of R/3 Manager, we can map the table into its columns so that
when the wr3rfc writes the data, it formats each column correctly according to
its data type. In Version 2.0 of R/3 Manager, the character columns are
displayed as characters and the integer columns are converted to character
to be displayed.
71
You need to run the appropriate task depending on your application server
platform type. As a result, a discovery schedule is established, and then a
newly discovered R/3 system object is created automatically, and its new icon
is displayed on the Manager for R3 policy region as we mentioned before. In
this case, your application server has to be available; otherwise, it will not be
discovered.
When you would like to stop performing the automatic discovery, run the
Remove Autodiscovery task. In this case, you need to run the task on the
same Endpoint (system) that you ran the Configure Autodiscovery task
before.
2.3.7.2 R/3 Batch Jobs
In Version 2.0 of R/3 Manager, three types of tasks related to R/3 batch jobs
are added as follows:
72
In the following sections, we introduce how to use these tasks and what kind
of information you can get as a result of each task.
Display Batch Jobs
The Display Batch Jobs task displays the batch jobs by using the following
key words:
Date
Job name
Job ID
Scheduled by
Released by
Status
Class
73
The information that can be obtained by running the Display Batch Job task is
similar to the information that is provided by the R/3 transaction code sm37 at
SAPGUI. The following figure (Figure 32) shows the information that is
obtained by running the Display Batch Job task.
The following figure (Figure 33) shows the information that is obtained by the
R/3 transaction code sm37 at SAPGUI.
74
75
The information that can be obtained by running the Display Work Processes
task is similar to the information that is provided by the R/3 transaction code
76
sm50 at SAPGUI. The following figure (Figure 37) shows the information that
is obtained by running the Display Work Processes task.
The following figure (Figure 38) shows the information that is obtained by the
R/3 transaction code sm50 at SAPGUI.
77
78
Work Process
Work Process Dispatch Queue
Tivoli Manager for R/3 provides two monitoring collections for the R/3
environment (the R3 Server Remote Monitors and R3 Server Central
Monitors). The three new monitors belong to the R3 Server Remote Monitors
monitoring collection. The new monitors provide you with the correct number
of running processes and status. You can check these processes if they are
not hanging or if there is no backlog in the work requests. These new
monitors provide better visibility, which helps internal workflow of the
application server.
These new monitoring profiles are not predefined profiles, and you cannot
find them in the R3 Server Remote Monitors profile. You need to create a new
profile and define it yourself for monitoring. When you configure a profile, you
can select the R3 Server Remote Monitors in the monitoring collections
field, and you can find these three new monitors in the monitoring sources
field. This procedure is the same as standard Distributed Monitoring
configurations. In the following sections, we introduce more detailed
information about these three new monitors.
2.3.8.1 Long Running Work Process
The Long Running Work Process monitor will return the number of processes
according to the specified type of work process whose elapsed time is greater
than or equal to the specified threshold. When you configure the profile in the
monitor argument field, you need to select a process type and enter a
threshold in seconds (refer to Figure 40).
79
Figure 40. Add monitor to Sentry profile (long running work process)
In this configuration, you can define several different R/3 work process types:
Dialog
Update
Enqueue
Batch
Spool
Update2
All
2.3.8.2 Work Process Source
The Work Process Source monitor will return the number of processes of the
specified type in the specified state. When you configure the profile, in the
monitor argument field, you need to select a work process type and work
process status (refer to Figure 41).
80
In this configuration, you can define several different types of R/3 work
process types:
Dialog
Update
Enqueue
Batch
Spool
Update2
All
You can also define several different types of R/3 work process states:
Free
Waiting
Running
81
Stopped
Completed
******
All
2.3.8.3 Work Process Dispatch Queue
The Work Process Dispatch Queue monitor will return the number of queued
requests for the specified type. Where, the Nowp type means
non-work-process processes, for instance, the saprouter program. When you
configure the profile in the monitor argument field, you need to select a work
process type (refer to Figure 42).
Figure 42. Add monitor to Sentry profile (work process dispatch queue)
In this configuration, you can define several different R/3 work process types:
Nowp
Dialog
Update
82
Enqueue
Batch
Spool
Update2
All
If you want to collect R/3 Manager events only from Managed Nodes, then
you will need to install the TEC product in every TMR even though the
TEC server will only be active in one TMR. Having the TEC product
installed provides the infrastructure needed by the R/3 Manager for
sending events using Tivoli object calls. In this configuration, resources
must be shared between the TMRs.
If you want to collect R/3 Manager events only from TMAs, then you will
need to have the TEC product installed only in the TMR hosting the TEC
server. Resources must be exchanged between the TMRs, and the
83
EventServer class must be registered in all TMRs not hosting the TEC
server. This configuration enables the R/3 Manager to send events by
using the wpostemsg command from the TMAs. TEC ACF still is needed on
the Endpoint Gateways in the local TMRs.
Note
2.3.12 Migration tool for Version 2.0 of Tivoli Manager for R/3
Version 2.0 of the R/3 Manager provides two installation methods: fresh
installation and migration (by using the migration tool). The migration tool is
available for only Version 1.5 or 1.5.1 of the Tivoli Manager for R/3.
84
Note
There is no upgrade module between Version 1.5.x and 2.0 of the R/3
Manager. Therefore, when you have already implemented Version 1.5.x of
the R/3 Manager and attempt to upgrade R/3 Manager, you need to
perform one of the following installation methods:
Fresh Install
Migration
However, in both cases, you have to perform a de-install operation of the
R/3 Manager.
The following are overviews of the migration processes:
1. Migrate the RFC configuration data.
2. Migrate the TEC Adapter for each Application Server. In order to find the
Application Server, use the Auto Discovery tool that is provided by Version
2.0 of the R/3 Manager.
3. Migrate the R/3 monitor profiles by using the tool.
4. De-install Version 1.5.x of R/3 Manager by using the tool.
Before performing the migration process, we strongly recommend that you
carefully read the readme file provided by the tool.
2.3.13 De-install tool for Version 2.0 of Tivoli Manager for R/3
Version 2.0 of the R/3 Manager provides the de-install tool which, in turn,
removes the entire R/3 Manager. The following two scripts are provided for
the de-installation operations:
R3Mgr_tmr_deinstall.2.0
R3Mgr_mn_deinstall.2.0
The first script (R3Mgr_tmr_deinstall.2.0) needs to be run on the TMR server,
and another script (R3Mgr_mn_deinstall.2.0) needs to be run on all Managed
Nodes and TMA where Version 2.0 of the R/3 Manager has been installed.
The R3Mgr_tmr_deinstall.2.0 script is located in the
$BINDIR/../generic_unix/TME/SAP directory, and the
R3Mgr_mn_deinstall.2.0 script is located in the
$BINDIR/../generic_unix/TME/SAP directory (on the Managed Node) or in the
85
Scripts Name
Description
Location
R3Mgr_tmr_deinstall20
De-installs
Version 2.0 of R/3
Manager on the
TMR server.
$BINDIR/../generic_unix/TME/SAP
R3Mgr_mn_deinstall20
De-installs
Version 2.0 of R/3
Manager on the
Managed Nodes
and TMA
Endpoints.
If Managed Nodes:
$BINDIR/../generic_unix/TME/SAP
If TMA Endpoints:
$LCF_BINDIR/../../generic_unix/TME
/SAP
rootitso@pokibmxtmrb20(/usr/local/Tivoli/bin/generic_unix/TME/SAP)#ls
2.2C
SAP.init
sap_migrate_profile.sh
3.0B
baroc
sappre.init
R3Mgr_mn_deinstall.2.0 dsl
sh
R3Mgr_tmr_deinstall.2.0 icons
win16
SAP.client
rls
win32
86
87
For more information about the de-installation processes, please refer to the
appropriate R3 Manager manuals.
88
J_8C1_DISPLAY_BATCH
J_8C1_MODIFY_JOB
J_8C1_MODIFY_PROCESS
J_8C1_DISPLAY_PROCESS
J_8C1_PROC_MONITORS
J_8C1_SYSLOG_READER
J_8C1_OS_COLLECT
J_8C1_OS390_COLLECT
J_8C1_OS390_DB2
J_8C1_ROLL_PAGE_SIZES
2.3.14.1 Distributing the R/3 ABAP file package
In the R/3 Manager configurations, one of the configuration processes entails
moving the transports to the R/3 application server. In Version 2.0 of the R/3
Manager, to move the transports you can use the one of the following
methods:
89
Note
The detailed information about these new functions that are provided by
Version 2.0 of Tivoli Manager for R/3 will be introduced in later chapters.
Please refer to Chapter 4, Planning and implementation on page 119 and
Chapter 5, Managing SAP R/3 environment on page 163 for more
information.
90
The Endpoint methods that will be used by the Endpoint are stored in the
Endpoint Gateway. When the Endpoint performs an R/3 management
operation, the Endpoint automatically determines what is needed to perform
the given management operation. If that Endpoint method already resides on
the Endpoint, it immediately proceeds with the R/3 management operation. If
not, the Endpoint downloads the appropriate Endpoint method from the
Endpoint Gateway to the Endpoint with no operator intervention. In addition,
the Endpoint downloads newer versions as updates are loaded on the
Endpoint Gateway. You can gain significant productivity advances with these
management features because the R/3 Manager is installed only once on the
Endpoint Manager (TMR server) and Endpoint Gateways, with updates
performed automatically thereafter. The following figure (Figure 44) shows
how Endpoint Gateway and Endpoint handle Endpoint methods.
91
Endpoint Manager
R/3 Manager
Installation
Endpoint Gateway
Method
Downcall
Endpoint
(SAP Server)
92
You also can see the contents of these dependency sets for the R/3 Manager
by using the wdepset command as follows:
wdepset -v 1533820760.1.970
where,
93
94
bin/generic_unix/TME/SAP/2.2C/sh/sap_start_adapter_internal.sh,../../bin/generic_unix/TM
E/SAP/2.2C/sh,8
bin/generic_unix/TME/SAP/2.2C/sh/sap_stop_db.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8
bin/generic_unix/TME/SAP/2.2C/sh/sap_stop_server.sh,../../bin/generic_unix/TME/SAP/2.2C/
sh,8
bin/generic_unix/TME/SAP/2.2C/sh/sap_clean_adapter.sh,../../bin/generic_unix/TME/SAP/2.2
C/sh,8
bin/generic_unix/TME/SAP/2.2C/sh/sap_stop_adapter.sh,../../bin/generic_unix/TME/SAP/2.2C
/sh,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_ALERT_CONTROL.TXT,../../bin/generic_unix/TME/SAP
/2.2C/rfc,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_ALERT_READER.TXT,../../bin/generic_unix/TME/SAP/
2.2C/rfc,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_BUFFER_INFO.TXT,../../bin/generic_unix/TME/SAP/2
.2C/rfc,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_BUFFER_NAMES.TXT,../../bin/generic_unix/TME/SAP/
2.2C/rfc,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_OS390_COLLECT.TXT,../../bin/generic_unix/TME/SAP
/2.2C/rfc,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_OS390_DB2.TXT,../../bin/generic_unix/TME/SAP/2.2
C/rfc,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_OS_COLLECT.TXT,../../bin/generic_unix/TME/SAP/2.
2C/rfc,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_ROLL_PAGE_SIZES.TXT,../../bin/generic_unix/TME/S
AP/2.2C/rfc,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_DISPLAY_BATCH.TXT,../../bin/generic_unix/TME/SAP
/2.2C/rfc,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_DISPLAY_PROCESSES.TXT,../../bin/generic_unix/TME
/SAP/2.2C/rfc,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_PROC_MONITORS.TXT,../../bin/generic_unix/TME/SAP
/2.2C/rfc,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_MODIFY_JOB.TXT,../../bin/generic_unix/TME/SAP/2.
2C/rfc,8
bin/generic_unix/TME/SAP/2.2C/rfc/wr3rfc_cfg.txt,../../bin/generic_unix/TME/SAP/2.2C/rfc
,8
msg_cat/C/R3MgrSyslogMsg.cat,%MSGCAT%/C,8
msg_cat/C/R3MgrRfcMsg.cat,%MSGCAT%/C,8
msg_cat/C/R3MgrMibMsg.cat,%MSGCAT%/C,8
bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_MODIFY_PROCESS.TXT,../../bin/generic_unix/TME/SA
P/2.2C/rfc,8
depset:
1533820760.1.881#Depends::Mgr#
1533820760.1.968#Depends::Mgr#
1533820760.1.969#Depends::Mgr#
As you can see, the wdepset command shows all Endpoint methods for each
support platform that is defined in the specified dependency set. These
Endpoint methods should be located under the /usr/local/Tivoli/bin/lcf_bundle
directory and loaded to the Endpoint method cache in the Endpoint where the
R/3 Manager function is called for the first time (for instance, when we
discover or define an SAP application server on the Endpoint for the first
time).
2.4.1.4 How Endpoint Methods Work on SAP Server
As we mentioned, the R/3 Manager provides the Endpoint methods that will
be invoked on the Endpoint for monitoring or controlling a SAP server running
on an Endpoint machine. This section introduces how these Endpoint
95
methods are loaded to the Endpoint and how they work. The following figure
(Figure 45) shows the relationship between the dependency manager and
Endpoint methods.
DependencyMgr
EP Manager
Dependency Set
sap_dep
1533820760.1.970#Depends::Mgr#
EP Gateway
1
Discover/Define
/usr/local/Tivoli/bin/lcf_bundle
Download
Method Cache
1. The R/3 Configuration Task that discovers and defines an SAP application
server on the Endpoint that SAP server is running is executed on the
Endpoint initially.
2. Then, the Endpoint Gateway checks the Endpoint for the existence of the
appropriate executables that are defined in the dependency set. Since this
is the initial discovery and definition, the Endpoint cannot find the
executable files in the cache on the local disk. Therefore, the Endpoint
Gateway loads these executables into the Endpoint method cache.
96
There are some triggers of downloading Endpoint methods other than the
above. A certain set of dependencies are added to the run_task method,
and those files are downloaded to all Endpoints wherever any task is run.
Another set of dependencies are downloaded when you define
R3AppServer.
2.4.1.5 Dataless Profile Manager and Endpoint
The dataless profile manager is a new profile manager type associated with
the dataless client (TMA). The dataless profile manager can have the
following subscribers:
Endpoints
Managed Nodes
PC Managed Nodes
NIS Domains
NetWare Managed Sites
As you can see in the list above, other profile managers cannot be
subscribers to the dataless profile manager. Therefore, the dataless profile
manager cannot be a branch node in a profile manager hierarchy. A dataless
profile manager can only be a leaf node, that is, only have managed systems
as subscribers.
Note
97
The profile created in the classic profile manager can be locally modified
because the information in the profile is written to the local database of the
full Managed Node. However, the local modification is not a recommended
customization because it makes profile management more complicated, and
it also makes future migration from a full Managed Node to the TMA more
difficult.
Profile
Profile
Local Modification
Object Database
Managed Node
Managed Node
Object Database
Figure 46. The Difference between dataless and classic profile manager
98
R3AppServer
R3AppServerPD
R3AppServerPV
R3DBServer
R3DBServerPD
R3DBServerPV
R3Instance
R3System
R3SystemPD
R3SystemPV
You can check all resource types that are registered by using the wlookup
command as follows:
wlookup -R
Before configuring the R/3 Manager, these objects do not have any object
instances. When you configure your R/3 Manager environment properly, each
object will have the appropriate object instances. You can check the instances
of the specified resource type in the TNR by using the wlookup command. For
example, the following are object instances of the R3System resource type in
our environment.
99
Use the idlattr and idlcall commands with caution. These commands are
not officially supported, and may adversely affect system configuration if
you perform the wrong operation.
The Object Attribute
Each attribute of an object instance has value, and you can refer to the value
by using the idlattr or idlcall command. The following example shows how
100
You also can use the idlcall command to display the system_timeout
attribute value as follows.
101
Note
102
The main design issue for TMA is the decision to create the R/3 application
objects (R3System, R3AppServer, R3DBServer, and so on) on the Managed
Node because it is not possible to create the R/3 application objects on TMA.
The following figure (Figure 47) shows the relationship between the
Application Proxy and the Tivoli object database.
TMR Server
R/3 Objects
APPLPROXY
Object DB
Managed Node
Endpoint Gateway
Endpoint
Figure 47. Application Proxy and Tivoli Object Database
103
or
idlcall <OID> _get_app_context
Note
Use the idlattr and idlcall commands with caution. These commands are
not officially supported, and may adversely affect system configuration if
you perform the wrong operation.
The following example shows the output of the idlcall command execution to
refer to the context variables of the R3System object.
As you can see, this information is the almost same as the information that is
obtained by using Tivoli Desktop (refer to Figure 28 on page 69).
104
Other Tivoli Manager series products will, in the near future, support TMA by
using Application Proxy.
105
106
107
POKIBMTAPM
POKIBMGEM
Windows NT 4
Tivoli Application Performance Manager
Tivoli Decision Support Demo
Windows NT 4
Tivoli Global Enterprise Manager
POKIBMXTECB20
AIX 4.3
Tivoli Enterprise Console
POKIBMXTMRB20
AIX 4.3
TMR Server
POKIBMXEGWB21
AIX 4.3
Gateway Server 1
POKIBMXEGWB22
AIX 4.3
Gateway Server 2
IS1N05
WWDN07
AIX 4.2
SAP R/3 3.0F
AIX 4.2
SAP R/3 4.0B
Our environment consisted of eight machines that were part of the Tivoli
Management Environment, which means that they all had the Tivoli
Framework installed as well as any additional Tivoli products that were
required for this book. The two SAP R/3 systems that complete our
environment were configured as Tivoli Management Agents (TMAs). The
wlsinst command was used on both machines with the -ah option to display
installed Tivoli products by hostname and the -ah option to display installed
patches and service releases, again by hostname. The following list contains
a detailed description and list of all the machines in our Tivoli Management
Environment.
POKIBMXTMRB20
This machine was chosen to be the Tivoli Management Region server for
both SAP R/3 systems. The machine had a connection to each of the two
Endpoint Gateway machines, POKIBMXEGWB22 and POKIBMXEGWB21.
This was to allow the exchange of a number of resources including Profile
108
109
POKIBMXTECB20
This machine ran the Tivoli Enterprise Console in our landscape, and it was
linked directly into the POKIBMXTMRB20 machine. Because the Tivoli
Enterprise Console requires a quite a lot of processing power to run it, this
machine was more powerful than the TMR machine in terms of processor
power. However, it had less memory and hard disk space because these are
not so necessary to a Tivoli Enterprise Console server. The actual hardware
details were as follows:
Multiple processors
512 Mb RAM
9 Gig HD space
The products installed on this machine were:
AIX 4.3.2
Tivoli Framework 3.6
Tivoli GEM Event Enablement 2.2.1
110
POKIBMGEM
This was a machine that we installed with Windows NT 4.0 then configured to
run the Global Enterprise Manager (GEM). In order to give some indication of
what the requirements for Global Enterprise Manager are, here are the
hardware specifications of this machine:
111
POKIBMTAPM
This was installed and configured to run Tivoli Application Performance
Manager (TAPM). The hardware specifications of this machine were exactly
the same as for the POKIBMGEM machine. However, the software
configuration was different in a few ways. The software installed on this
machine was as follows:
112
POKIBMXEGWB21
This machine was one of the two Endpoint Gateways in our environment. This
machine was connected to both of the SAP R/3 systems in our landscape.
The hardware details of this machine were as follows:
Uni processor
320 Mb RAM
22 Gig HD space
The products installed on this machine were:
AIX 4.3.2
Tivoli Framework 3.6
Tivoli Enterprise Console Adapter Configuration Facility 3.6
Tivoli Distributed Monitoring ARM EndPoint version 3.6
Tivoli Distributed Monitoring ARM Monitors version 3.6
Tivoli Distributed Monitoring ARM Agent version 3.6
Tivoli Application Proxy, Version 1.1
Tivoli Software Distribution, Version 3.6
Tivoli Software Distribution Gateway, Version 3.6
Tivoli Distributed Monitoring 3.6
113
POKIBMXEGWB22
This was the second of the two Endpoint Gateway machines. Like
POKIBMXEGWB21, this machine also had a connection to both SAP R/3
systems. The hardware configuration was as follows:
Uni processor
320 Mb RAM
18 Gig HD space
This machine had a hardware configuration almost the same as
POKIBMXEGWB21. The software configuration was as follows:
Tivoli Framework 3.6
Tivoli Enterprise Console Adapter Configuration Facility 3.6
Tivoli Distributed Monitoring ARM EndPoint version 3.6
Tivoli Distributed Monitoring ARM Monitors version 3.6
Tivoli Distributed Monitoring ARM Agent version 3.6
Tivoli Application Proxy, Version 1.1
Tivoli Software Distribution, Version 3.6
Tivoli Software Distribution Gateway, Version 3.6
114
Uni processor
512 Mb RAM
49 Gig HD space
The following list provides the nodes software configuration:
AIX 4.2.1
115
The SAP R/3 and DB2 versions were relatively low on this machine compared
to latest code levels. However, the Tivoli Manager for R/3 still supported these
application code levels on this machine.
116
Note
The Tivoli Manager for R/3 used during the project of this redbook was a
beta code version. The versions of SAP R/3 that are supported by this
product are subject to change at any time before or after release of the
module.
WWDN07
This was the thin node of the pair. The hardware configuration was as follows:
Uni Processor
512 Mb RAM
35 Gig HD space
The software configuration of the machine is shown in the following list:
AIX 4.2.1
SAP 4.0B
DB2 5.2.0
Tivoli Framework 3.6
Tivoli Enterprise Console Adapter Configuration Facility 3.6
Tivoli Distributed Monitoring ARM EndPoint version 3.6
Tivoli Distributed Monitoring ARM Monitors version 3.6
Tivoli Distributed Monitoring ARM Agent version 3.6
Tivoli Application Proxy, Version 1.1
Tivoli Software Distribution, Version 3.6
Tivoli Manager for R/3, Version 2.0
Tivoli Distributed Monitoring 3.6
117
This system had the higher code and version levels of the two systems. It
provided us with a relatively high level system with which to test the
performance of the Manager for R/3.
118
All examples in this book regarding Version 2.0 of Tivoli Manager for R/3
are performed with the pre-GA version of the product. Therefore, some
detailed feature may be changed without notice. Please check with your
IBM or Tivoli representative for further information.
The R3System name used in this redbook has dbhostname_SID, while the
actual product has SID_dbhostname.
119
Actually, many Tivoli patches are released, especially for Tivoli core
applications. Some functions may not work correctly unless the proper Tivoli
patch is applied. You should take care of applying these patches.
Note
Before implementing the SAP R/3 management system, the following steps
should be done:
Physical architecture design
Logical design
Enterprise
Module
TMR
Server
TEC
Server
EPGW1
EPGW2
FW3.6+3.6.1+
Patch
Managed Node
Gateway
Endpoint
120
TMA1
SAP
3.0F
TMA2
SAP4.0
B
Enterprise
Module
TMR
Server
TEC
Server
EPGW1
EPGW2
DM3.6+3.6.1+
Patch
DM TME/TEC
Monitor
DM UNIX
Monitor
DM Universal
Monitor
DM ARM
Monitor
SD3.6+3.6.1+P
atch
SD
GW3.6+3.6.1
TEC
EIF3.6+3.6.1+
Patch
TEC
Console3.6+3.
6.1
TEC
ACF3.6+3.6.1
SIS3.6+3.6.1
R/3 Mgr2.0
V2.0
TMA1
SAP
3.0F
TMA2
SAP4.0
B
121
This patch (Patch 0001) must be installed when you implement Version 2.0
of Tivoli Manager for R/3. This patch fixes many problems.
The installation must be performed as root user. The authorization role
required for user root is the install_product role. The setting of the
authorization role for the root user is made via the Tivoli Desktop.
Before installing the Tivoli Manager for R/3, it is recommended to make a
backup of the Tivoli database.
To install the module, follow these steps:
Log on to the TMR server as user root. Then, launch the Tivoli Desktop by
running the tivoli command.
In the Tivoli Desktop main window, select Desktop from the menu bar and
the Install -> Install Product... from the pull-down menu.
In the Install Product window, click the Select Media button to set the
right path where the code will be installed from and click the Select &
Close button.
Back in the Instal Product window, select the Tivoli Application Proxy,
Version 1.1, entry from the Select Product to Install section as shown in
Figure 49. Also select the clients on which code must be installed.
Remember that clients are the TMR server, the TEC server, each
Managed Node that runs an R/3 application server, and the Endpoint
Gateway if the application server runs on a TMA Endpoint.
122
Once the settings are correct, click the Install & Close button to start the
installation. Dependencies for this product will be checked, and the
directories where the code will be installed are mentioned in the Product
Install window. If the information contained in this window is correct, then
click the Continue Install button.
When the installation is completed successfully, a message is displayed in
the Product Install window. Do not forget to make a new backup of the
Tivoli database after the Tivoli Application Proxy installation.
123
Note
Each time you install some product, we strongly recommend you make a
backup of the Tivoli database. It is the most reliable and easiest way to
recover your environment even if your installation fails.
4.3.1.2 Installing Version 2.0 of Tivoli Manager for R/3
Tivoli Manager for R/3 must be installed on the TMR server, TEC server, the
Managed Node that runs an R/3 application server, and the Endpoint
Gateway if the application server runs on a TMA Endpoint.
124
Once the settings are correct, click the Install & Close button to start the
installation. Dependencies for this product will be checked, and the
directories where the code will be installed are mentioned in the Product
Install window. If the information contained in this window is correct, then
click the Continue Install button.
When the installation is completed successfully, a message is displayed in
the Product Install window. Do not forget to make a new backup of the
Tivoli database after the Tivoli Manager for R/3 installation.
A new policy region named Manager for R/3 is added to the administrators
Tivoli Desktop as shown in Figure 51.
125
This new policy region, Manager for R3, contains one indicator collection, one
policy region, four profile managers, and three task libraries as shown in
Figure 52. The three task libraries are grouped in R3 App Server Tasks, R3
DB Server Tasks, and R3 System Tasks, and they contain tasks related to
their server or system type.
126
127
128
Typically, your R/3 Basis administrator will have IDs already set up that
have the desired authorization. We describe how to set up a user here in
order to provide the complete sequence of steps necessary to configure
Tivoli Manager for R/3.
The following is the procedure for a 4.0B R/3 system:
Via a SAPGUI, log on to the R/3 system as SAP*.
Issue the transaction su01.
In the User field, type SAP* and click the Copy icon.
Enter TIVOLI in the To field of the Copy Users window.
Enter the initial password in the Logon data folder (you will be asked to
change it at the first logon).
Make sure it is a Dialog user in the Logon data folder and that it has
SAP_ALL as an authorization profile in the Profiles folder.
Save your entries and log off.
4.3.3.2 Moving the Transports
To move the transports to the R/3 system, two different ways are provided.
One is copying the transport files, and the other is distributing the R/3 ABAP
file package. We introduce both ways in the following section.
Copying the Transport Files
On the application server that will be used to execute the import, copy the
data and cofiles files from $BINDIR/../generic_unix/TME/SAP/2.2C/abap to
129
The transports only need to be installed in the R/3 system. This is done from
any one application server in that SID. It is not necessary to distribute the
transports to every application server, but only one application server per
SID. You could create a subscription list of all central instances and distribute
the transports to this subscriber list. Also, using Software Distribution to
distribute the profiles, you do not have to worry about getting the right files in
the ../data and ../cofiles directories.
Once you have installed Software Distribution at the TMR server, a profile
manager named R3 Transport is newly created under the Manager for R3
policy region. Inside of the R3 Transport profile manager, you can find the R3
ABAP file package (Figure 54).
130
131
In the Edit Profile Manager window, check the Dataless Endpoint Mode
and click Change & Close (Figure 55). When you refresh the icon, the
icon changes into a dataless profile manager.
132
Complete the File Package Unix Options (Figure 57). The ABAP file
package must be distributed to the /usr/sap/trans directory, and it is the
destination directory for UNIX. The default destination directory for
Windows NT is \sapmnt\trans. You can change the directory as
appropriate.
Enter the appropriate user login name or user ID in the user ownership of
files on subscribers field. Also, enter the appropriate group name or group
ID in the group ownership of file on subscribers field. We recommend that
you change the user ID and group ID at this point since the source files to
distribute have root and system ownership as their user ID and group ID
repetitively. However, in our destination, we need to change the source
files user ID and group ID as sidadm and sapsys, respectively. In our
case, our UID is IG3adm, and GID is 200 (Figure 57). Click the Set and
Close button to complete the setting.
133
Verify that there are no other imports waiting in the transport buffer by
entering tp showbuffer <SID>, with the SID corresponding to your R/3
system.
134
already
already
already
already
already
been
been
been
been
been
imported
imported
imported
imported
imported
completely
completely
completely
completely
completely
TASK
DDIC I ACTIV MAIN I MC ACT ADO I LOG I VERS F XPRA GENERA UMODE TAGS
----------+------+------+------+------+------+------+------+------+------+-----+---PD9K900664|
|
|
1 |
|
|
|
2 |
|
2 |1
|
K10K900261|has already been imported completely
AD1K900218|has already been imported completely
BD1K901366|
|
|
1 |
|
|
|
4 |
1 |
|
|
PD9K900714|has already been imported completely
PD9K900716|has already been imported completely
SAPK001LDE|has already been imported completely
TV1K900057|has already been imported completely
TV1K900095|has already been imported completely
TV1K900096|has already been imported completely
IG3K900105|has already been imported completely
that makes 2 transports to be imported.
tp finished with return code: 0
meaning:
Everything OK
If some imports are waiting, contact the SAP administrator of the system.
If not, add the correction to the buffer by entering the tp addtobuffer
TV1K900187 IG3 command as follows.
Note
135
already
already
already
already
already
been
been
been
been
been
imported
imported
imported
imported
imported
completely
completely
completely
completely
completely
TASK
DDIC I ACTIV MAIN I MC ACT ADO I LOG I VERS F XPRA GENERA UMODE TAGS
----------+------+------+------+------+------+------+------+------+------+-----+---PD9K900664|
|
|
1 |
|
|
|
2 |
|
2 |1
|
K10K900261|has already been imported completely
AD1K900218|has already been imported completely
BD1K901366|
|
|
1 |
|
|
|
4 |
1 |
|
|
PD9K900714|has already been imported completely
PD9K900716|has already been imported completely
SAPK001LDE|has already been imported completely
TV1K900057|has already been imported completely
TV1K900095|has already been imported completely
TV1K900096|has already been imported completely
IG3K900105|has already been imported completely
TV1K900187|
4 |
4 |
1 |
|
|
| 10 |
|
8 |
|
that makes 3 transports to be imported.
tp finished with return code: 0
meaning:
Everything OK
IG3
40B) for DB2commonserver database
40B - 08.05.98 - 13:03:12).
Note
136
After importing, you can also check the SAP system for the development
class being created, and also all objects should be activated. Use transaction
se80 and display the development class J8C1, as shown in Figure 58 on page
137.
You can open each sub-tree by double-clicking it to check that their status
should be saved and activated. For example, we opened the J_8C1_TIV1
structure as shown in Figure 59 on page 138.
137
138
Note
New users are normally required to change their password on the first
login. Therefore, if you make the user a CPIC user, you will never have the
chance to modify the password. As an alternative to the procedure
described previously, you can make the user a dialog user first and then
change the properties to CPIC once you have validated the permissions
and changed the password.
As you can see in Figure 60, we created a new User ID named TME10 and
have given the CPIC User type.
139
4.3.4 Configuring the Tivoli Manager for R/3 to the R/3 System
We need to create Tivoli objects for the R/3 system, application server, and
database server so that we can manage them though the Manager for R/3. To
create the R/3 objects, two different ways are provided: a manual method
from the Tivoli Desktop, or using the automatic discovery function.
We also introduce configuring roles and RFC in this section.
4.3.4.1 Configuring Roles
Once you have finished with your installation of R/3 Manager, three new
resource roles are created: r3_user, r3_admin, and r3_senior (Figure 62).
140
Assign these new roles to your main Tivoli administrator as TMR roles and
then continue working with this administrator instead of using a new one.
Make sure to restart the Tivoli Desktop after assigning the new roles to make
the change effective.
4.3.4.2 Creating R/3 System
To create an R/3 system object, follow these steps:
In the Manager for R3 policy region window, select Create from the menu
bar and R3System... from the pull-down menu.
In the Create R3 System window (Figure 63), enter the SID of the R/3
system in the R/3 System Name (SID) field and select the R/3 release.
Note
In Version 1.5 of Tivoli Manager for R/3 configuration, the R/3 Release field
refers to the level of the SAPGUI that you want distributed by the Tivoli
Manager for R/3. However, in Version 2.0 of Tivoli Manager for R/3
configuration, the R/3 Release field refers to the actual release level of the
R/3 system being managed.
Select the R/3 Database type and enter the R/3 Database hostname the
R/3 database server is running. Enter the R/3 Database release as
optional.
Click the Set and Execute button. This task creates a subregion for the
R/3 system in the Manager for R/3 policy region.
141
In the Manager for R/3 policy region window, double-click the appropriate
R/3 system icon to open the selected R/3 systems policy region.
In the R/3 systems Policy Region window, select Create from the menu
bar and R3AppServer from the pull-down menu.
In the Create R3 application server window (Figure 64), enter the two digit
R/3 application Instance ID.
Enter the R/3 Host name that R/3 communicates to the application server.
If your application server is running on a Managed Node, enter the
Managed Node name in the Managed Node Name field. If your application
server is running on a TMA Endpoint, enter the TMA Endpoint name in the
TMA Endpoint Name field.
Click the Set and Execute button. This task creates a subregion for the
R/3 application server in the R/3 system policy region.
142
In the Manager for R/3 policy region window, double-click the appropriate
R/3 system icon to open the selected R/3 systems policy region.
In the R/3 systems Policy Region window, select Create from the menu
bar and R3DBServer from the pull-down menu.
In the Create R3 database server window (Figure 65), if your database
server is running on a Managed Node, enter the Managed Node name in
the Managed Node Name field. If your database server is running on a
TMA Endpoint, enter the TMA Endpoint name in the TMA Endpoint Name
field.
Click the Set and Execute button. This task creates a subregion for the
R/3 database server in the R/3 system policy region.
143
The Automatic Discovery function finds R/3 application servers that are up.
When a new application server is found, Automatic Discovery creates an
R3AppServer object along with an R3System object. If database server is
running on the same machine where application server is running, Automatic
Discovery also creates the R3DBServer object.
The creation of the R/3 system, application server, and the database server
can be done by Automatic Discovery all at once. Therefore, you can either
create each R/3 object manually or use Automatic Discovery.
To use the Automatic Discovery function, run the Configure Autodiscovery
tasks that are predefined in the R3 Configuration Tasks task library. The tasks
are provided as platform-specific; therefore, you choose the appropriate tasks
depending on your platform type. In the following, we configure the UNIX
case.
In the Manager for R3 policy region, double-click the R3 Configuration
policy region.
Open the R3 Configuration Tasks task library.
Double-click the Configure Autodiscovery for UNIX task.
In the Execute Task window, increase the timeout to 500 and select the
Display on Desktop check box.
144
In the Available Task Endpoints list, select the Managed Nodes that are
application servers of the R/3 system and move them to the Selected Task
Endpoints list.
Click the Execute & Dismiss button.
In the resulting window (Figure 66), enter the appropriate schedule in the
fields. If you want to run Automatic Discovery immediately, leave all fields
blank.
Note
If you run Automatic Discovery, you always must distribute the R3 Server
Autodiscovery Monitor profile manually.
145
To configure RFC for each R/3 system, run the Configure Remote Function
Call task in the R3 Configuration Tasks task library and follow these steps:
Open the R3 Configuration Tasks task library (Figure 67).
Double-click the Configure Remote Function Call task.
In the resulting window, enter the 3-digit client number associated with the
RFC user ID, enter the RFC user name (for example, TME10), its
password, and the language used (Figure 68).
146
147
We recommend that you test that the RFC is correctly configured. This can be
done from different hosts:
On the TMR server (or any Managed Node where the module is installed),
copy the wr3rfc program from $BINDIR/TME/SAP/2.2c to
$BINDIR/../generic_unix/TME/SAP/rfc. You can also find the wr3rfc
program in the $LCF_BINDIR/../TME/SAP/2.2c directory if it is on the TMA
Endpoint.
For each Managed Node running an application server, and on each
Endpoint Gateway that manages a TMA Endpoint that runs an R/3
application server, execute the following command:
wr3rfc -u userid -c client -p password -l language -d SID -h ManagedNode
-s InstanceNumber J_8C1_BUFFER_NAMES
148
rootitso@pokibmxtmrb20(/usr/local/Tivoli/bin/generic_unix/TME/SAP/2.2C/rfc)#$BINDIR
/TME/SAP/2.2C/wr3rfc -u tme10 -c 100 -p tivoli -l E -d IG3 -h wwdn07.pok.ibm.com -s 00
J_8C1_BUFFER_NAMES.TXT
Initializing data structures.
Installing the error handler.
=
=
=
=
=
=
IG3
2003e970
100
tme10
E
0
= RFC_MODE_R3ONLY
= 2003e970
= wwdn07.pok.ibm.com
= 0
SAP.
opened.
149
scripts containing the specific database commands that will start and stop the
database. These two scripts, named sap_start_db.exit.sh and
sap_stop_db_exit.sh, must reside on the Windows NT database server of the
%BINDIR%\..\generic_unix\TME\SAP directory if it is a Managed Node and
the %LCF_BINDIR%\..\generic_unix\TME\SAP directory if it is a TMA
Endpoint. When called though the start/stop task, two parameters will be
provided to them. The first one is the database type, and the second one is
the SID. The scripts must return an exit code of zero for a successful
completion and a non-zero exit code for an unsuccessful completion.
Example of a Start Exit Routine for an Oracle Database
The following is an example of a start exit routine for an Oracle database.
#!/bin/sh
echo 'Starting Service'
E:/orant/Bin/oradim80.exe -STARTUP -SID $2 -STARTTYPE srvc
echo 'Sleeping'
sleep 10
echo 'Starting Instance'
E:/orant/Bin/oradim80 -STARTUP -SID $2 -STARTTYPE inst -USRPWD \
-PFILE E:\\orant\\Database\\init"$2".ora
exit 0
#!/bin/sh
echo 'Stopping Instance'
E:/orant/Bin/oradim80.exe -SHUTDOWN -SID $2 -USRPWD -SHUTTYPE \
inst -SHUTMODE n &
echo 'Sleeping'
sleep 10
echo 'Stopping Service'
E:/orant/Bin/oradim80.exe -SHUTDOWN -SID $2 -SHUTTYPE srvc
exit 0
Figure 70 shows the main created objects on the Tivoli Desktop after all these
Tivoli Manager for R3 configuration steps.
150
Manager for R3
Note
In Figure 70, there are two Sentry profiles under the R/3 application server
(wwdn07_IG3_00). These profiles are not there automatically. They only
show up after you distribute them.
151
Note
The Configure Event Server for R/3 task updates your existing rule base if
you specify no rule base to clone or creates a new rule base from an
existing rule base.
To configure the event server, run the Configure Event Server job in the R3
Configuration Tasks task library (Figure 71) and follow these steps:
Open the R3 Configuration Tasks task library.
Double-click the Configure Event Server job.
152
In the resulting window (Figure 72), enter the name of the new rule base
you want to create or the name of the already existing one that you want to
modify (in the second case, enter the name of the rule base you want to
clone and the path to its directory; in the first case, erase these entries).
153
For rule base name, you can enter the new one or existing one. If you want
to create a new rule base, enter the name, rule base to clone, and the path
for the new rule base. If you do not create a new rule base, enter the
existing rule base name and leave the other two fields (rule base to clone
and path for new rule base) blank.
If you want the TEC server to forward events directly to another TEC
server, enter the name of this other event server in the Managed Node
Name to forward Events field.
Click the Set and Execute button.
Verify the task status window that you received no errors.
Note
In our case, since we have not created a new rule base before, we use the
default value SAP for Rule Base name, Default for Rule Base to clone,
and /usr/tec_rules/SAP for Path for new Rule Base.
This setting means that it will clone the Default rule base and add some
SAP R/3 specific rules into it and create a new rule base name called SAP
and place it in the /usr/tec_rules/SAP directory. If you have not created a
rule base previously, use Default as the rule base to clone.
154
The following steps must be repeated for each R/3 system that is to be
managed.
To configure the event console, run the Configure Event Console job in the
R3 Configuration task library (Figure 73) and follow these steps:
Open the R3 Configure Tasks task library.
Double-click the Configure Event Console job.
155
In the resulting window (Figure 74), enter the name of event group that you
want to create in the group name field. Select the Name of Event
Console that you want to configure. In the sources field, select at least
one source that you want to receive the events. In the group filter for R/3
systems field, select at least one R/3 system that you want to receive.
When you select, be sure to check it is highlighted.
156
Figure 76 and Figure 77 show you the created objects in the event console.
As you can see in Figure 76, the R/3 specific Event Group called ITSO_SAP
is created in the Enterprise Console Event Groups window.
157
Also, as shown in Figure 77, you can find two R/3 specific event sources
called WR3MIB and WR3SLOG. To view the events generated from the alert
event adapter, open the WR3MIB event source icon. To view the events
generated from the syslog adapter, open the WR3SLOG event source icon.
158
159
To configure the event adapter, run the Configure Event Adapter task in the
R3 Configuration task library (Figure 78) and follow these steps:
Open the R3 Configuration Tasks task library.
Double-click the Configure Event Adapter task.
In the Execute Task window, increase the timeout to 600 and select the
Display on Desktop check box.
In the Available Task Endpoints list, select the Managed Nodes that are
application servers of the R/3 system and move them to the Selected Task
Endpoint list.
Click the Execute & Dismiss button.
In the resulting window (Figure 79), select either Alert Adapter or Syslog
Adapter for the adapter type. You can choose one of them at a time, but
you need to configure both so that you get events from both adapters.
Enter the Hostname of the Event server.
160
Verify in the task status window that you received no errors (refer to Figure
80).
161
Note
In most cases, you must manually start the Event Adapter using the Start
Event Adapter task. The exception is that the first time distribution of an
Event Adapter to Windows NT is started automatically. You must manually
restart Event Adapter on UNIX systems after a reboot. They are
automatically restarted after a reboot on Windows NT.
162
All examples in this redbook regarding Version 2.0 of Tivoli Manager for
R/3 are performed with the pre-GA version of the product. Therefore, some
detailed features may be changed without notice. Please check with your
IBM or Tivoli representative for further information.
The R3System name used in this redbook has dbhostname_SID, while the
actual product has SID_dbhostname.
163
system-level view (you can see all defined R/3 systems here besides the R3
Configuration policy region). Here, you will see three task libraries: R3 App
Server Tasks, R3 DB Server Tasks, and R3 System Tasks. Open R3 App
Server Tasks, and you will see 14 predefined tasks in this window as shown in
Figure 81.
These tasks let you handle your R/3 application servers, varying from the task
of starting/stopping the server or starting/stopping the event adapter to tasks
that display some information, such as roll area, page area, operating system
(OS) collector, batch job, and work process. For the work process and batch
jobs, there is a task to cancel them, and for batch jobs, there is even a task
available to release them.
To run a task, open the task you are choosing (for example, Display Batch
Jobs), and you will get an Execute Task window as shown in Figure 82.
164
Choose an application server as the Task Endpoint to run this task. After
completing, click Execute & Dismiss to start the task.
165
In some cases (in this case, as shown in Figure 83), if the task requires
arguments, a window is displayed, and after you provide the required
information, click Set & Execute. The output of this task is shown in Figure
84.
166
To control your R/3 database servers using Tivoli tasks, open the Manager
for R3 policy region from the Tivoli Desktop and then open task library: R3
DB Server Tasks. You will see a window as shown in Figure 85. If you
execute the task Start/Stop Database, you will get a pop-up window as a
confirmation before stopping the database server. When stopping a UNIX
database server, the stop processing also stops all application servers on
that server, thus, having the same SID. But stopping/starting a database
server running on Windows NT requires customer exit routines as described
in 4.3.4.7, Configuring the environment on page 149.
Besides tasks for stopping and starting your database server, there is also a
task to start dbaccess on the specified database server. The status of the
start dbaccess job will be displayed in the Start dbaccess Output window, and
the dbaccess xterm window will also be displayed. You can use structured
query language (SQL) commands to access your R/3 database. Press Ctrl-W
167
for help. Note that this function is now only supported with a Motif windows
manager and an Informix database.
There is also a task library: R3 System Tasks available that has two tasks on
it, Stopping and Starting R/3 System. You can run one of these tasks against
a selected Task Endpoint, which could be one of your R/3 Systems, to start or
stop the whole R/3 system.
168
when you create the file package. This section also describes how to
distribute the client software file packages. The distribution of the file package
is done via Tivoli Software Distribution, whatever the configuration method
used.
Note
The configuration tasks to build the file package create profile managers
and profiles as a result of their processing. For these actions to succeed,
the administrator running these tasks must also have Tivoli super role.
5.1.2.1 Configuring a R/3 Client using a Reference Installation
This method proposes that you first install and configure a SAPGUI locally on
a node, using the R/3 CD-ROM, to create a reference client machine for the
distribution of the code to other future clients. We performed this installation
on a Windows NT running as a Managed Node.
Once the local installation is completed, you have to transfer the R/3 client
directories and files from the PC client to the TMR server to a specific
directory. For example, we have created a directory named /Ref/NT/ on our
AIX TMR server as a repository for the R/3 client code for Windows NT. This
transfer can be made using ftp. Using this method for the transfer can be
applied either between a UNIX TMR server and a Windows PC TMA or
Managed Node, or between a Windows NT TMR server and a UNIX TMA or
Managed Node. If your TMR server and your future SAPGUI clients are
running on the same platform, you have to install the SAPGUI on the TMR
server instead of using ftp to transfer the code.
After creating the SAPGUIs code repository, you can now configure the task
that will put the code into a Tivoli Software Distribution file package ready to
be distributed to other machines. Use the following procedure to create the
client software file packages for distribution of SAPGUI:
From the Tivoli Desktop, open the Manager for R3 policy region to display
the Policy Region: Manager for R3 window.
Open the R3 Configuration policy region to display the Policy Region: R3
Configuration window.
Open the R3 Configuration Tasks task library to display the configuration
tasks.
Edit the appropriate job for a reference installation by right-clicking on the
job icon. The jobs name is: Configure Client Install.
169
By default, the name of the task executed by the job is highlighted in the Task
Name scrolling menu: Configure Client Install. The other default settings are
correct, except for the Output Format. We recommend you also check the
Return Code. Also check that the TMR server is selected as task endpoint,
because the task must be executed on it. Once all settings are correct, click
on the Change & Close button.
Then double-click on the job icon. A dialog box is displayed that allows you to
set some parameters to perform the execution as shown in Figure 87.
170
The Configuration Name you will specify will be an identifier of the current
configuration. It will be, for example, the name of the profile manager created
by the jobs execution. The Source Information field must be filled with the
path where the client code is stored. For us, this is /Ref/NT/, on the TMR
server, as explained before. In the Destination Information section, you have
to specify the platform your target clients have, the directory where to
distribute the code (we recommend also that you install the code in an SAPpc
directory), and the required disk space (20 MB is the recommended size).
Some information about the R/3 server for which the clients will be configured
is required. This information contains the Primary Application Server name
and the Instance Number. Then, click on Set & Execute to run the job. A
formatted output window will open, and when the task has run successfully,
you should see a message "Task Complete!" in the standard output section.
Then select Close. The job has executed a task running a script that creates
a Tivoli Software Distribution file package. In our example, this file package
contains the SAPGUI code for a Windows NT R/3 client. This file package is
included in a profile, itself added in a profile manager as shown in Figure 88
on page 172. Both are created during the jobs execution.The name of the
profile manager is the one you associated with the file package when you run
the configuration task.
171
You can edit the Tivoli Software Distribution profile to see the content of the
file package by double-clicking on it (see Figure 89).
Verify that the package contains the R/3 client code for Windows NT, located
in the /Ref/NT directory on the node pokibmxtmrb20, which is the TMR
server.
Distributing this file package to the target machine will create on it an
SAPGUI icon in the Start Menu to access the R/3 system specified during the
configuration of the job.
172
Figure 89. Edit the Profile: Configuring the R/3 SAPGUI Client File Package
173
for R/3 provides tasks for UNIX, Windows NT, and Windows 9x clients. To
configure the task, use the following steps:
From the Tivoli desktop, open the Manager for R3 policy region to display
the policy region: Manager for R3 window.
Open the R3 Configuration policy region to display the policy region: R3
Configuration window.
Open the R3 Configuration Tasks task library to display the configuration
tasks.
Then, edit the appropriate job for a native installation by right-clicking on
the job icon. The jobs name is: Configure Windows NT Client Install.
174
By default, the name of the task executed by the job is highlighted in the Task
Name scrolling menu: Configure Windows NT Client Install. The other default
settings are correct except for the Output Format. We recommend you also
check the Return Code. Also check that the TMR server is selected as task
endpoint because the task must be executed on it. Once all settings are
correct, click on the Change & Close button.
Then double-click on the job icon. A dialog box is displayed that allows you to
set some parameters to perform the execution as shown in Figure 91.
175
Language: Enter the language you want to use chosen from the
R/3supported languages list.
Destination Information: Fill in the fields for the destination directory on the
target machine where the code is going to be copied (we recommend that
you install it into a SAPpc directory). This is the source directory where the
image is stored. It is either the CD-ROM drive itself, or a mount point if the
CD-ROM is shared with other target machines. In both cases, the source
path must end with WINDOWS, for example, E:\GUI\WINDOWS. Do not
specify the subdirectory WIN32, for instance, because only a part of the
code will be installed. The third attribute you have to set in this section is
the path where the documentation will be copied.
R/3 Server Information: Enter the hostname of the server name and its
Instance Number.
Installation Options (Optional): This is for entering direct commands.
These fields are useful for network mounting of the SAPGUI CD-ROM (for
example: net use, sleep, and so on).
4.0B Components: By default, the 32-bit option is set. For the other
parameters, refer to the R/3 manuals for details.
Click on Set & Execute to run the job. A formatted output window will open,
and when the task has run successfully, you should see a message "Task
Complete!" in the standard output section. Then select Close. The job has
executed a task running a script that creates a Tivoli Software Distribution file
package. This file package contains a set of R/3 installation tools and
commands to install the SAPGUI for Windows NT on the Windows NT targets
from the SAPGUI CD-ROM image. This set of R/3 tools and commands has
been copied from the Tivoli Manager for R/3 directories on the TMR server.
This file package is included in a profile, itself added in a profile manager, as
shown in Figure 92. Both have been created during the jobs execution. The
name of the profile manager is the one you associated with the file package
when you ran the configuration task.
176
You can edit the Tivoli Software Distribution profile to see the content of the
file package by double-clicking on it (refer to Figure 93).
Verify that the package contains the set of R/3 tools and commands to install
the SAPGUI code on the Windows NT target. You can also see that this set is
located in the Tivoli Manager for R/3 directories on the node pokibmxtmrb20,
which is the TMR server.
Distributing this file package to the target machine will create on it an
SAPGUI icon in the Start Menu to access the R/3 system specified during the
configuration of the job.
177
Figure 93. Edit the Profile: Configuring the R/3 SAPGUI Client Native Installation
178
profile manager you wish to use and check the Dataless Endpoint Mode as
shown in Figure 94.
Indeed, the client install and configuration jobs execution creates, by default,
a standard profile manager. Only Managed Nodes and PC Managed Nodes
can be subscribed to such a profile manager, but TMAs cannot be subscribed
to it as they are dataless endpoints. A TMA can only be subscribed to a
dataless profile manager and not to a standard profile manager.
In case you need to distribute the file package profile for both the TMA and
Managed Node, you can perform some customization that will be described
hereafter. The first step is to create a new profile manager with the dataless
endpoint mode option. You must give it a different name from the one of the
standard profile manager, because Tivoli does not support two objects with
the same name. Then, from the default standard profile manager, clone the
profile to the new dataless profile manager. To do this, go into the standard
profile manager and select the profile. Then, in the profile manager window,
select Edit from the menu bar and Profiles->Clone... from the pull-down
menu. In the window that appears, you will be asked to change the name of
the cloned profile because of the Tivoli rule described above. Also select the
dataless profile manager you have created as the target for the cloned profile
and click the Clone & Close button. This window is shown in Figure 95.
179
Now, you can subscribe your TMA to the dataless profile manager. Note that
a dataless profile manager can have TMAs, Managed Nodes, or PC Managed
Nodes as subscribers, but not a subscription list. So, you may not delete the
standard profile manager, because you may need to subscribe a subscription
list.
In our example, shown in Figure 96, we will use the originally created file
package during the configuration because we will distribute it to a Windows
NT Managed Node. Then select the Windows NT node as a subscriber to this
profile manager. Now, the file package can be distributed to the Managed
Node. To do so, select the file package from the Profiles section and the
Managed Node from the Subscribers section. Then, from the menu bar,
select Profile Manager and Distribute... from the pull-down menu. A window
will appear to confirm the distribution. Click on the Distribute & Close button.
180
181
182
Type
Name
Location
Tasks
UNIX: /tmp
Windows NT Managed Node:
$DBDIR/tmp
Windows NT Endpoint:
$LCF_DATDIR/tmp
Monitors
UNIX: /tmp
Windows NT Managed Node:
$DBDIR/tmp
Windows NT Endpoint:
$LCF_DATDIR/tmp
Event
Adapters
adapter_name.log: Where
adapter_name is r3mibIID for the
alert event adapter or r3slogIID
for the syslog adapter.
UNIX: /tmp
Windows NT:
%SYSTEMROOT%\temp, where
%SYSTEMROOT% is the drive
where Windows NT is installed,
usually the C: drive.
If the \temp directory is not found,
the event adapter log files are
written in one of the following
directories:
Managed Node:
$BINDIR/TME/SAP/2.2C
Endpoint:
$LCF_BINDIR/../TME/SAP/2.2C
SAPGUI File
Package
Distribution
Managed Node:
$BINDIR/../generic_unix/TME/S
AP/fp/profilemgr, where
profilemgr is the name of the
profile manager.
183
184
Alerts provided by CCMS are also shared with the external world by using an
interface, the SAP shared memory segment. Every SAP R/3 application
server does have a shared memory segment. It is called SAP Management
Information Base (MIB), or R/3 System Management (SysMan), which
comprises all alert information from this application server. This alert
information is monitored by the wr3mib program and a TEC event adapter,
which translates the SysMan alerts to TEC events. More information on the
alert event adapter will be given in 5.3.1, Alert Event Adapter on page 186.
There is a second event adapter provided by the Tivoli R/3 Manager, the
syslog event adapter, which processes the R/3 syslog and converts new
entries into TEC events. Because this is also a TEC event adapter, the
standard Tivoli-provided filtering capabilities can be applied to these events.
More information on the syslog event adapter will be given in 5.3.3, Syslog
Adapter on page 189.
Another possibility for monitoring R/3 systems is using Tivoli Distributed
Monitoring and the Remote Function Call. This Tivoli core application
provides synchronous monitoring functionality. Details on getting information
185
from SAP R/3 using Tivoli Distributed Monitoring will be discussed in 5.3.4,
Tivoli Distributed Monitoring on page 194.
$BINDIR/TME/SAP/2.2C
TMA Endpoint
$LCF_BINDIR/../TME/SAP/2.2C
All R/3-related alert events received by the TEC server can be classified into
two categories: Specific events and Generic events. Specific events contain
all pertinent information on the event and are forwarded directly to the TEC
event consoles. On the other hand, generic events only give high-level
information as an indication of a problem. For these events, the Manager for
R/3 will perform drill-down processing to gather more detailed information
about the R/3 system through the RFC interface. In doing this, the original
event will be discarded.
5.3.1.1 Drill-Down Process
After reception, the TEC server dispatches the events to its rules engine. The
rules specific for R/3 have been previously imported and loaded into the TEC
server during the event server configuration. One of these rules will be
triggered by generic events, which come from the R/3 alert event classes (see
Appendix B, Event classes for Tivoli Manager for R/3 on page 347). It will
invoke a drill-down process and then drop the events. Figure 100 on page 187
illustrates the TEC event processing. The drill-down process begins with the
TEC rules calling the sap_alert_reader_cb.sh script, which is located in
$BINDIR/TME/TEC/scripts. This script runs on the TEC server and launches
a task with the application server as the task endpoint. The corresponding
script that is run on the remote application server is called
sap_alert_reader.sh and is located in
186
SAP Instance
CCMS
Event Console
drill-down events
specific events
Rules Engine
Function
Modules
drill-down
sap_alert_reader_cb.sh
MIB
RFC
R/3 Manager
r3slog
r3mib
wr3rfc
sap_alert_reader.sh
When this script executed, it calls the wr3rfc program that logs on to the R/3
application server and runs the J_8C1_ALERT_READER function module
imported into the SAP system during the Tivoli Manager for R/3 configuration.
This will result in information being returned from the R/3 application server,
and this information is also filtered out in order to extract the corresponding
detailed information. Then, this detailed information is formatted into one or
several TEC events (in most cases, only one event) and then sent to the TEC
server. The rules engine will forward these specific events to the TEC event
consoles.
If an error occurs during the execution of the sap_alert_reader.sh script, an
event of class AMS_WR3MIB_PROCESS_ALERT is sent to the TEC stating
187
188
$BINDIR/TME/SAP/2.2C
TMA Endpoint
$LCF_BINDIR/../TME/SAP/2.2C
189
The r3slogIID.cl defines the syslog events that are sent to the TEC. Events
that are not defined in this file cause the syslog event adapter to send events
with the event class SAP_SYSLOG_MSG. Modify the entries in the
r3slogIID.cl file to customize the syslog events to be sent to the TEC or add
new entries to this file to send additional syslog events to the TEC.
To customize the syslog events that are sent to the TEC, modify the entries in
the r3slogIID.cl file. Entries for many syslog events are defined in the
r3slogIID.cl file for your convenience. Most of the entries are commented.
Commented lines are preceded by a semicolon (;). To send additional syslog
events to the TEC, uncomment the appropriate event entries. Similarly, if you
do not want to send one of the default events to the TEC, precede the
appropriate event entry with a semicolon (;), or you can add filter criteria to
the r3slogIID.conf file.
If you want to define additional syslog events to send to the TEC, add new
syslog event entries to the r3slogIID.cl file in the following format: MessageID
[Severity [Classname]], where:
MessageID
Severity
Classname
190
;A05
;A07
A08
;AB0
;AB1
;B15
50
30
50
30
30
40
SAP_SYSLOG_A05
SAP_SYSLOG_A07
SAP_SYSLOG_A08
SAP_SYSLOG_AB0
SAP_SYSLOG_AB1
SAP_SYSLOG_B15
191
wr3slog.conf file
#**********************************************************************
#
# Tivoli Mgr for R3 tecad_wr3mib Alert Adapter Configuration File Template
#
# Version:
1.0
#
# ((c) Tivoli Systems, Inc. 1999, 1998)
# Licensed Materials - Property of Tivoli Systems
#
# tecad_wr3mib.conf - Tivoli Mgr for R3 alert adapter configuration file.
#
# File format:
#
<keyword>=<value>
#
# where <keyword> is
# ServerLocation
- Hostname of the T/EC server.
# ServerPort
- Port number on which the T/EC server is listening.
#
use zero for UNIX (assumes portmap utility at tec server host),
#
for NT port is required since no portmap utility
# ConnectionMode
- connection_oriented OR connection_less
# ErrorLogLevel
- FATAL/MAJOR/MINOR.
# TracingLogLevel
- LOW/NORMAL/VERBOSE.
#
# FilterMode=OUT- indicates events matching the Filter specifications hould be filtered
#
out, that is not sent to the event server.
# Filter:Class=SAP_SYSLOG_MSG - filter out default syslog messages
#
# ABH_R3SystemName
- triplet <hostname>_<SID>_<systemNumber>
# ABH_Label
- user defined label, no embedded blanks allowed
# ABH_TMR_Region
- Tivoli TMR_Region name
# ABH_Hostname
- hostname of server as known by R3
# ABH_SystemNumber
- R3 System Number
# ABH_PollingDelay
- delay between polling loops of the SAP R3 mib
# ABH_SID
- R3 application server SID
# ABH_Userid
- R3 RFC userid
# ABH_Password
- R3 RFC password (encrypted)
# ABH_Client
- R3 RFC client
# ABH_Language
- R3 RFC language
#
# r3mibNN where NN is the R3 system number of the system to
# be monitored and the .conf file would be named r3mibNN.conf
#**********************************************************************
ServerLocation=
ServerPort=0
ConnectionMode=connection_less
ErrorLogLevel=MINOR
TracingLogLevel=LOW
FilterMode=OUT
Filter:Class=SAP_SYSLOG_MSG
ABH_R3SystemName=
ABH_Label=
ABH_TMR_Region=
ABH_Hostname=
ABH_SystemNumber=
ABH_PollingDelay=20
ABH_SID=
ABH_Userid=
ABH_Password=
ABH_Client=
ABH_Language=
These examples are templates; so, if you would like to perform some
processes using the Syslog Event Adapter, you need to modify these
192
template files. The next section introduces some examples of how the Syslog
Event Adapter can be used to automate operations of SAP R/3.
Note
In the past, the SYSLOG has not been a strong tool for automation because
the traditional method of exposing SYSLOG events outside of R/3 (via the
Alert Event Adapter) did not support multiple, simultaneous events, and each
desired SYSLOG event had to be made "alertable" by changing R/3
parameters via CCMS.
The new Syslog Event Adapter avoids these problems by bypassing the Alert
Event Adapter and, instead, directly accessing the R/3 SYSLOG via RFC.
Also, since the filtering and event severity is controlled by the adapter
configuration files, the administrator has considerable control over the events
that the Syslog Adapter sends to the TEC.
Below are two examples of how the Syslog Adapter can be used to automate
operations of SAP R/3.
Example 1: Operations mode change
Many customers automatically change SAP R/3 operation modes to tailor the
distribution of dialog and batch work processes to the expected R/3 workload,
such as providing more batch work process during the night. The Syslog
Adapter can be used to detect this operations mode switch and trigger a TEC
rule that could automate the release of batch jobs.
To make the Syslog Adapter detect operation mode changes, you must add
event "EEA" to Syslog Adapter Configuration file and to the Syslog baroc file
to allow these types of events to pass to TEC. Refer to section "Customizing
Syslog Events" in the Tivoli Manager for R/3 Users Guide Version 2.0,
SC31-8411, for information on adding new syslog events to the Syslog
Adapter.
193
REPORT ZSAPDEMO4 .
*-----------------------------------------------------------------------*
* Sample program that writes messages to the R/3 syslog to provide
*
* status information that can be forwarded to TEC by the Manager for R/3*
* Syslog Adapter
*
*-----------------------------------------------------------------------*
CALL FUNCTION 'RSLG_WRITE_SYSLOG_ENTRY'
EXPORTING
SL_MESSAGE_AREA = 'Z0'
SL_MESSAGE_SUBID = '1'
PRE_PARAM_LONG = 'ZSAPDEMO4 Started'
EXCEPTIONS
OTHER_PROBLEM
= 1.
WAIT UP TO 20 SECONDS.
"Simulated work
CALL FUNCTION 'RSLG_WRITE_SYSLOG_ENTRY'
EXPORTING
SL_MESSAGE_AREA = 'Z0'
SL_MESSAGE_SUBID = '1'
PRE_PARAM_LONG = 'ZSAPDEMO4 Processing 10000 records'
EXCEPTIONS
OTHER_PROBLEM
= 1.
WAIT UP TO 20 SECONDS.
"Simulated work
CALL FUNCTION 'RSLG_WRITE_SYSLOG_ENTRY'
EXPORTING
SL_MESSAGE_AREA = 'Z0'
SL_MESSAGE_SUBID = '1'
PRE_PARAM_LONG = 'ZSAPDEMO4 Processing 20000 records'
EXCEPTIONS
OTHER_PROBLEM
= 1.
WAIT UP TO 20 SECONDS.
"Simulated work
CALL FUNCTION 'RSLG_WRITE_SYSLOG_ENTRY'
EXPORTING
SL_MESSAGE_AREA = 'Z0'
SL_MESSAGE_SUBID = '1'
PRE_PARAM_LONG = 'ZSAPDEMO4 Processing Complete'
EXCEPTIONS
OTHER_PROBLEM
= 1.
194
central monitors run on the TMR server where the Tivoli Manager for R/3 is
installed, but they monitor a R/3 application server on another Endpoint. They
only use the RFC interface because only this interface can be accessed
remotely. The MIB interface can not be accessed remotely. The remote
monitors and the central monitors are created from two distinct monitoring
collections: R3 Server Remote Monitors and R3 Server Central Monitors. If
you look at both monitoring collections, you will find that they have some
monitor sources in common:
Page Area
Roll Area
Buffer information
OS Collect Application Server
Besides these common sources, the R3 Server Remote Monitors collection
includes:
Performance monitor
Server status monitor
Work process monitor
Cancelled job monitor
And the R3 Server Central Monitors collection includes:
OS database collection
OS/390 OS collection
OS/390 DB2 collection
195
SAP Instance
C CMS
Event Console
Rules Engine
Function
Modules
TMR Server
RFC
MIB
R/3 Manager
wr3rfc
Distributed Monitoring
R/3 Manager
wr3rfc
wr3mib
Central
Monitors
Distributed Monitoring
The remote monitors use both wr3mib and wr3rfc programs to access the
MIB and the RFC interfaces of the SAP system. The performance information
and the SAP availability monitors get their information from the MIB interface
and, thus, use wr3mib. As this program cannot be executed remotely, we only
find these two kinds of monitors in the Server Remote Monitor collection. The
central monitors only have the ability to access the SAP systems using the
RFC interface. You can execute the wr3rfc from a central point, such as the
TMR server. The Manager for R/3 does not always have direct access to the
R/3 database server, and it never has direct access to OS/390, which is why
the corresponding monitors can only be created from the R3 Server Central
Monitors collection.
196
Note
197
Note
198
199
Manager for R3
R/3 System
sub-policy region
R3_Indicators
Indicator Collection
Profile Manager
R3 DB Server Monitors
Profile
R3 Server Autodiscovery Monitors
Subscription Lists
App Server List
TMR Server
200
The R3 Server
Autodiscovery Monitors
profile contains the
application server status
monitor. This monitor
returns the status of an
R/3 application server.
When you use automatic
discovery to create your
R/3 system and server
objects, this profile must
always be distributed to
the application servers.
Note
You can distribute other monitors to your R/3 application servers during
discovery by adding the monitors to this profile.
R3 Server Central Monitors Profile
201
202
Note
The monitors run against the application servers, but there are OS/390
DB2 database monitors in the central collections that can provide some
OS/390 DB2 information.
Figure 103. Monitoring Collections Provided by the Tivoli Manager for R/3
The monitors from each of the two monitoring collections differ in where they
are supposed to be distributed and run. They do not differ in what they are
monitoring, as both monitoring collections have the same set of monitors
except for SAP availability, performance, and OS/390 monitors. Monitors
belonging to the Server Remote Monitors collection must be run on a specific
machine and will monitor that machine directly. Such monitors are distributed
and run on the R/3 application server. This means that the Tivoli Distributed
Monitoring profile containing these monitors must have a R/3 App Server List
as subscriber. On the other hand, monitors from the Server Central Monitors
collection can be compared to proxies. This means they are distributed to a
machine and monitor other machines remotely using the wr3rfc program.
According to that characteristic, Server Central monitors have to be
distributed to the TMR server; moreover, this is the only valid subscriber.
Then, these monitors will run on behalf of a R/3 object or a SAP server. This
203
R/3 object is specified as a parameter when you create the monitor. Also,
another difference between the two monitoring collections is the monitoring of
the SAP system availability, the performance of an R/3 server, and the
monitoring of OS/390. Indeed, only the Server Central monitoring collection
provides monitors for the operating system running the database server, the
DB2 database on OS/390, and OS/390 itself. On the other hand, the SAP
system availability and performance monitors are provided only by the Server
Remote monitoring collection. In 5.3.5.5, Monitoring Sources Available from
Monitoring Collections on page 217, all the monitoring sources are described
along with their functions and the monitoring collection they belong to.
5.3.5.3 Predefined Default Monitors
After you finish installing and configuring Tivoli Manager for R/3, you will see
some predefined default monitors ready to use and to start monitoring your
SAP system. You can find these default monitoring profiles in the R3 App
Server Monitors profile manager as shown in Figure 104.
204
There are only two pre-defined default monitors in the R/3 App Server profile
manager, that for remote monitors collections and for Autodiscovery monitors.
The R3 server Central monitors profile is empty. To access pre-defined
default monitors for servers, start by double-clicking the Manager for R/3
icon from the Tivoli Desktop. You will see three profile manager icons, one for
R3 App Server Monitors, one for R/3 DB Server Monitors, and one for the
Managed Node Monitors. By clicking on the first icon, and then again on the
Autodiscovery profile icon, you will see the pre-defined default monitors for
R3 Server Autodiscovery Monitors as shown in Figure 105. You can also add
some monitors to this profile, which are needed to be distributed to the R/3
application server during the discovery process.
205
Then, still in the R3 App Server Remote Monitors profile manager, you can
open the R3 Server Remote Monitors profile that contains pre-defined default
monitors as shown in Figure 106.
206
207
Also make sure the Alert event adapter is running because the wr3mib
program is also part of the Distributed Monitoring mechanism in case of using
the R3 Server Remote Monitors monitoring collections as explained in 5.3.1,
Alert Event Adapter on page 186. You can start the Alert event adapter from
the icon pull-down menu as shown in Figure 108.
208
After performing these steps, you now have your Distributed Monitoring
monitors running against your SAP system, in this case, the application
server. You can see these events on the TEC event console as shown in
Figure 109.
209
If you want to modify a given monitor, in our example in the pf_temp profile,
open the Manager for R3 policy region from the Tivoli Desktop. Then open
the R/3 App Server Monitors profile manager, and open profile pf_temp.
Within this profile, you can see all the monitors created here, and by selecting
one of them and clicking the Edit Monitor... button, you will see more
information about this monitor as shown in Figure 110.
210
In this window, you can modify a set of pre-defined fields for this monitor in
order to customize the way you want to be notified when it occurs and also
the way you want to react when it occurs. This second option can be done by
clicking Run program and then selecting which program you want to run,
either on the monitored host or on the Managed Node of your choice. For
more information on all fields you can modify and what they will do, simply
click the Help button.
If you want to create a new monitor, you can start by opening a monitoring
profile you want to add your monitor to, for example, from the R3 Server
Central Monitors profile. This window is shown in Figure 111. Then, just
select the Add Monitor... button to create a new monitor.
211
After this is done, you will see the Add Monitor to TME 10 Distributed
Monitoring Profile window where you can select on the left the Monitoring
Collections available, and on the right, the Monitoring Sources for each
Monitoring Collection. Depending on your selection of a Monitoring Source,
sometimes you will also have a field where you can select the attribute to this
Monitor Source and also the application servers available to run this monitor.
For example, let us select the pf_temp profile in the R3 App Server Monitors
profile manager and create a monitor there. We select the R3 Server Remote
Monitors as our Monitoring Collection, and we will create a Work process as
our Monitoring Source. For some monitor sources, there are monitor
arguments to fill in, as in this case here, as shown in Figure 112.
212
For example, let us select Dialog as the type and stopped as the status.
Then we can proceed by clicking the Add Empty... button. Here, you will have
all available options for your monitor to customize as you want (see Figure
113 for more details).
213
After selecting the options you want for your new monitor, click the Change &
Close button to create it. After this, you may select the Indicator Collection
for your new Monitor. This is shown in Figure 114.
214
You can simply choose the default R3 Indicators, or you can create another
one if you want (refer to Figure 115).
215
Do not forget to select Profile from the menu bar and then Save from the
pull-down menu to finish creating your new monitor. After distributing this
monitoring profile, you can see the result of this monitor on the TEC Event
Console as shown in Figure 116.
216
217
available to monitor the operating system of either the R/3 application server
or the R/3 database server. The monitoring of the operating system also
includes a monitoring source for the OS/390 operating system. Then, for the
database itself, Tivoli R/3 Manager proposes a monitor source to monitor the
DB2 database running on OS/390. The following table lists these monitoring
sources associated with their monitoring collection. Note that for each
monitoring source a list of attributes is available to configure the monitor.
These lists are presented in Appendix C, Monitor sources and their
attributes on page 361, and you can also refer to the SAP R/3 documentation
for details and explanations about these attributes.
Table 9. Monitoring Sources
218
Monitor Sources
Roll Area
Page Area
Work Process
Monitor Sources
OS Collect - Application
Server
Application Server
Status
Dialog Performance
Update Performance
Batch Performance
Spool Performance
OS Collect - Database
Server
OS/390
OS/390 DB2
Cancelled Job
sap_server_monitor_35.baroc
tecad_wr3slog.baroc
219
sap_tecad.baroc
SAP_APM_HEARTBEAT
SAP_Alert
AMS_WR3MIB_PROCESS_ALERT
SAP_Internal_Alert
SAP_ALERT_OSCO_LOAD
SAP_MIB_Alert
SAP_MIB_Unique_Alert
SAP_ALERT_SAPSysUp
SAP_MIB_Generic_Alert
EVENT
SAP_SYSLOG_RFC_ERROR
SAP_SYSLOG
SAP_SYSLOG_MSG
SAP_SYSLOG_A05
Sentry2_0_Base
Sentry3_5_Base
SAP_Server_Monitors
APSRVR_STATUS_MONITOR
SAP_CANCELLED_JOB_MONITOR
tecad_wr3slog.baroc
sap_server_monitor_35.baroc
All event classes under the SAP_MIB_Alert super class correspond to the
CCMS alerts placed by R/3 on its MIB interface. These alerts are read by the
wr3mib program and converted to TEC events of the appropriate class. Some
of them are only high-level indications of a problem and will require a
drill-down process to get more information. These generic events have an
event class defined under the SAP_MIB_Generic_Alert. Other events coming
220
from the MIB and not requiring a drill-down have an event class defined under
SAP_MIB_Unique_Alert. Drill-down processes get detailed information
through the RFC interface of the R/3 system (using the wr3rfc program).
Resulting information is formatted into TEC events of classes defined under
SAP_Internal_Alert. Events of the class AMS_WR3MIB_PROCESS_ALERT
are generated when the alert control and alert reader tasks encounter an
error.
Note
221
sap_tecad.rls
sap_monitor.rls
sap_default.rls
222
sapsysup_read_all_internal_alerts
6. Discarding buffer alerts if they occur within 35 minutes of an R/3
operational mode switch. Generally, if an operational mode switch
occurs, the R/3 buffers are expected to remove old data and insert new
data. Poor buffer performance is expected during these times. There is
one rule that supports mode changes using alert control processing:
reset_certain_events_on_statechange
7. Automatically close syslog events as soon as they occur. This is
because R/3 only allows one R/3 syslog message to occupy the syslog
alert status at a time. By closing the syslog alerts immediately, the
probability of getting the next syslog alert is increased. Since there is
no drill-down process needed, all SAP syslog alerts should be received
by the syslog event adapter. There is one rule that supports closing
syslog events using alert control processing:
reset_syslog_alert
8. Forwarding events to alternate TEC servers. There is one rule that
supports event forwarding:
forward_sap_events
The sap_monitor.rls rule file provides the following functions:
1. Correlate Distributed Monitoring event with appropriate R/3 system.
Based on information in the event, the sub_source slot is assigned to
the value of the R/3 system label, and the sub_origin slot is assigned to
the value of the R3 application server name as defined to Tivoli. There
is one rule that supports system label assignment:
set_r3sapname_slot
2. Check for and remove duplicate events. Also, increase the repeat count
slot value. There are four rules that supports duplicate event removal:
dup_sap_cancelled_job_event
dup_sap_monitor_event
dup_sap_system_down
dup_sap_system_up
3. Coordinate events with the Distributed Monitoring engine or Distributed
Monitoring host machine coming up/going down. This entails closing all
Distributed Monitoring outstanding events for the application server(s)
on that Managed Node. There are four rules that support this status
coordination:
223
sentry_daemon_or_application_up
sentry_daemon_or_application_down
sentry_host_up
sentry_host_down
4. Coordinate events with the R/3 application server coming up/going
down. This entails closing all Distributed Monitoring outstanding events
for that application server. There are two rules that support R/3 status
coordination:
sap_system_up
sap_system_down
5. Discard Distributed Monitoring events if they come in while the
corresponding application server is down. There is no need to process
these events since there is a larger underlying problem. There is one
rule that supports Distributed Monitoring event discard:
sap_system_down_no_more_entries
6. Discard Distributed Monitoring events if they occur within 35 minutes of
an R/3 application server coming up. Generally, when an application
server is starting, it is loading/refreshing its buffers; so, poor
performance is expected during these times. There is one rule that
supports mode changes:
drop_sentry_events_on_sentry_sysup
7. Handle operator acknowledgment or closure of Distributed Monitoring
events. When an operator acknowledges or closes a Distributed
Monitoring event, the event is forwarded, and all duplicates are closed.
There are two rules that support operator acknowledgment or closure:
ack_sap_sentry_alert
close_sap_sentry_alert
8. Extract information from the cancelled job monitors and assign them to
event slots, which are: R3JobName, R3JobId, and R3JobDate. There
are two rules that support the cancelled job monitors:
sap_extract_job1
sap_extract_job2
The sap_default.rls rule file provides the following function:
Discard Distributed Monitoring events if they occur within 35 minutes of
an R/3 application server coming up. Generally, when an application
224
Please refer to Appendix D, TEC Rules and Events on page 373 for more
detailed information about TEC rules and events.
225
226
227
A p p lic a tio n
D a ta b a s e
M u lti p le S A P
S y s te m s
S yb a se
I n te r n e t
P o w e r s o ft
L o t u s N o te s
O r a c le
In f o r m i x
U N IX
W in d o w s N T
DB2
W in d o w s 9 8
IP X
S y s te m
T C P / IP
N e tw o r k
M Q S e rie s
O p e n V ie w
N e tw a r e
SunN et
SNA
N e t B IO S
SNMP
228
B u s in e s s
S y s te m s
M anagem ent
G lo b a l E n te rp ris e M a n a g e r
Tiv o li M a n a g e r fo r ...
A p p lic a tio n s
M anagem ent
S A P R /3
D e p lo y m e n t
F u n d a m e n ta l
M anagem ent
D a ta b a s e
O p e r a tio n s
A v a ila b ility
A p p lic a tio n
P e rfo r m a n ce
M ana ger
E n te r p ris e
C o n s o le
S o ftw a re
D istrib u tio n
O u tp u t
M anag er
D e c is io n
S u p p o rt
W o rk lo a d
S c h e d u le r
D is trib u te d
O b je c t
F ra m e w o rk
C o m p u tin g
R e s o u rc e s
P o lic y
Ta s k s
C o m m u n ic a tio n
S y s te m s
N e tw o rk s
M Q S e rie s
S e c u rity
S c h e d u lin g
D a ta b a s e s
D istrib u te d
M o n ito rin g
S e c u rity
G lo b a l
S ig n - O n
S e c u rity
M a nage m e nt
C o n fig u ra tio n
C o lle c tio n s
A p p lic a tio n s
D is trib u tio n s
In te rn e t
As can be seen from Figure 119, the Tivoli solutions all provide a particular
piece of a complete solution. However, the diagram also shows that individual
products can be implemented to produce a solution for a particular scenario.
Tivoli products can be combined to produce any solution an organization
needs.
More importantly, all the products and solutions can be used to feed a single
point of control, enhancing the concept of an integrated solution. In Figure
119, this single point is represented by the Tivoli Global Enterprise Manager.
This is the product that interfaces to all the other Tivoli solutions to provide a
single point of control for an enterprise management solution. Tivoli provides
management modules for a number of different applications, however, for the
purposes of this book, only the three listed are relevant. The next level deals
with the management of fundamental components and also forms the basis
for the scenarios presented in the remainder of this chapter. This level is
divided into different sections of the overall enterprise. All of these sections
need to be addressed equally for the success of the enterprise and any
management solution that is implemented to service it. The distributed object
framework level deals with the Distributed Object Framework that forms the
core of the Tivoli solutions. This level represents all the objects that are used
229
230
Quite often companies do not invest in training their operations groups too
highly. This is for a number of reasons. The main reason being that the
turnover of operations staff is high; therefore, investment in training is lost
when staff leave. Another reason is that large organizations have second and
third level support departments specialized in the above areas; therefore,
educating operators on the same subjects would be a waste of time and
money.
Companies usually choose instead to invest in some form of monitoring and
management solution, as this stays constant while staff come and go.
Operations staff then receive at least basic training in all the above areas and
are taught how to use the organizations management solution. Unfortunately,
because the technical level of operations staff is kept as low as possible, it
means that second or third level support staff need to be called for the
majority of problems regardless of the severity, or usually, the time. In an
organization with a large array of machines and applications, this can cause
highly skilled people to be caught up performing basic day-to-day tasks,
instead of dealing with the important problems they are paid to solve.
Therefore, an Operations group needs a monitoring and management
solution that will help ease the day-to-day tasks they perform and also enable
them to perform the basic tasks, and more, without needing to call support for
every problem. This not only improves the worth of an organizations
operators but also frees up the highly skilled support staff to deal with more
complex problems.
Hubs
Routers
Repeaters
Switches
231
All of these need to be monitored and managed to ensure the integrity of the
connections between servers and end-users. In an ideal world, it is also
useful to monitor a network for response times to see where and when it is
overloaded and where bandwidth needs to be expanded or components
upgraded.
However, when things do go wrong, an operator needs to be able to correct
the problem quickly and efficiently. This requires some ability to understand
the network, its connections and layout, the devices being used, and most
importantly, a method of gaining access to the device in question.
6.3.2.2 Hardware Monitoring and Problem Determination
Whereas the section above embraced the monitoring of both the network
hardware and software, this section only deals with the monitoring and
problem determination of server hardware.
232
User Logs
Daemons
Background Processes
Virtual Memory (Swap Files)
At the base level, an operating system is similar to hardware. It is really
constructed of many components that all need to run perfectly for the
operating system to function correctly.
Monitoring is required in order to watch all the vital components of an
operating system and provide some kind of an alert to inform operations of a
problem. Ideally, a monitoring solution is required that will evaluate the nature
of the problem and attempt a solution of some kind before alerting operations
to the problem.
For example, if a daemon was to fail, the monitoring solution could attempt to
automatically restart it. If this was unsuccessful, then an alert would be sent
to the operator indicating the problem. Another example is a file system
reaching a particular capacity. Again, the monitoring solution could attempt
corrective action before informing the operator. This, of course, also requires
some form of capacity management to track the growth of a file system from
day-to-day.
6.3.2.4 Application Monitoring and Problem Determination
Obviously, the most important task of any operations group is the effective
monitoring and problem determination of an organizations business critical
applications. These days, the protection of their applications is an
organizations prime goal. When applications fail to perform, or are
unavailable, both time and money are lost. Although the areas mentioned
previously are very important, after all a failure in any of them can render an
application unavailable, the most important part is the monitoring of the
application itself.
There are many applications that organizations use; however, this scenario
will focus on a standard implementation of SAP R/3.
233
R S /6 0 0 0
R S /6 0 0 0
A IX
S A P R /3
A IX
D B 2 fo r
R S /6 0 0 0
Figure 120 shows a typical SAP R/3 environment with two servers, in this
case RS/6000s, both running AIX. One is performing the role of database
server for SAP R/3, and the other is running a single SAP R/3 application
server.
First, looking at the SAP R/3 application server, it may be a requirement to
monitor some, or all, of the following areas:
Status (Up or down)
Response
Log Files (check for errors and problems)
Process Status (dialog, background, and so forth)
Connection to Database
Load (Amount of users, amount of background jobs)
Background Processing (see next section)
All of these things, and more, need to be monitored to ensure that the
application is running correctly.
The other component or application in the system is the database, in this
case, DB2 for RS/6000. The following list indicates some of the items that
need to be monitored with regards to this application:
Tablespaces (usage, growth and capacity)
Threads (deadlocks, conflicts)
Logs
234
Load
Response
From this list, and the one for SAP R/3 shown previously, it can be seen that a
number of items need to be measured per application. When an organization
is only running a few servers or applications, this can be performed manually
at regular intervals. However, when an organization has many servers and
multiple applications, this becomes an impossible task. Some form of
monitoring solution is needed, one that will monitor the application either in
real-time or at set intervals, detect any problems, and inform the operations
group so that prompt action can be taken.
6.3.2.5 Batch Scheduling, Monitoring, and Problem Determination
Every organization, especially those using SAP R/3 or similar ERP packages,
employ some form of batch, or background, processing. This can take many
formats, such as daily reports for management, bulk processing of customer
orders, bulk invoicing, and so forth. Some organizations run their batch
processing during normal business hours; however, this is really only feasible
if batch processing is light. Most organizations perform their batch processing
outside core business hours, usually because the batch processing places a
tremendous load on the system and would render it unresponsive or slow for
users.
Usually batch schedules are time critical. Any failure can place the whole
schedule in jeopardy, as jobs are left waiting for the output from a failed job.
SAP R/3 has its own built in suite of batch job creation, scheduling, and
monitoring tools, and they work well. However, they all require someone to be
logged on to the machine in order to use them. As said previously, if an
organization only has a couple of systems, then this is not a problem; but if
there are a lot of servers and SAP R/3 applications, then this becomes an
impossible task. When batch processing schedules are time critical, this
becomes potentially damaging. Job failures can go unnoticed for long periods
of time if manual checking is being performed. Therefore, a monitoring
solution for batch processing is of paramount importance to any organization
that relies on time critical batch schedules.
For example, an organization has a factory that produces products based on
the output of a batch job. This job reports the supply and demand information
from the previous day. This means that this report needs to be available
before the start of business on any particular day; otherwise, how does the
factory know what to manufacture? Therefore, if the batch job that is
responsible for this report fails, or any of the jobs that feed this batch job fail,
then it needs to be detected and corrected as soon as possible.
235
236
237
SAP system log, this reduces the need for an operator to log on to each
physical system to check for errors. An operations group only needs to wait
for alerts to appear on the Tivoli Enterprise Console, then action these
accordingly.
6.3.4.4 Tivoli Workload Scheduler
Tivoli Workload Scheduler is an important part of any large scale SAP
operations solution. Traditionally, when monitoring SAP batch schedules, an
operator would have to be physically logged into a system to monitor the
schedule. This means that if there are multiple systems to monitor, the
operator must have multiple windows open and keep switching between these
to monitor the batch schedules. Tivoli Workload Scheduler removes this time
consuming and potentially dangerous problem. Because Tivoli Workload
Scheduler can managed batch schedules across different applications,
systems, and platforms, only one window is needed. Also, an operator does
not need to go looking for problems, as these are reported to the Tivoli
Workload Scheduler focal point automatically.
There are only two types of batch job inside SAP. These are System or User
Created jobs. System jobs are those native to SAP. They perform some kind
of system maintenance or statistics collection. For example, the
REORGJOBS batch job, which deletes old batch job logs from SAP to
conserve file system space, can be monitored by Tivoli Workload Scheduler.
Most of the time, this job runs with no problems; however, from time to time it
can fail for a number of reasons. When this job fails, it stops clearing down
the batch job logs. As a result, they keep growing unchecked until they
eventually fill the file system they reside in. This can cause the SAP R/3
application to crash; so, this job and other system jobs need to be monitored
constantly to ensure that they are working as planned. This can be
accomplished with the aid of Tivoli Workload Scheduler.
The other type of SAP batch jobs are User created jobs. These are jobs that
have either been written by ABAP developers to perform specific functions for
an organization, or they could be standard system jobs that have been
renamed and adjusted to perform a particular task. In either case, when these
jobs are correctly defined to Tivoli Workload Scheduler, they can be
monitored like any other.
Because Tivoli Workload Scheduler works across different platforms, it
means that if some of the organizations batch schedules actually run outside
the SAP R/3 application system, they can still be monitored as a part of the
whole schedule. For example, if some of the processing is carried out on an
OS/390 mainframe, this can be monitored by Tivoli Workload Scheduler.
238
239
240
241
SAP Syslog
For the resources considered in this scenario, the following three tables will
list all the available element lists with their event sources. The following table
(Table 10) shows event sources related to applications.
Table 10. Element List: Applications
242
Event Source
SAP R/3
DM (remote collections)
SAP R/3
r3mib
SAP R/3
SAP R/3
user-defined script
notes_log
event_reporter
nt_event_log
MQ Series
mq_adapter
Event Source
MQ Series
DM
ADSM
adsm_plus_aix
ADSM
adsm_plus_nt
Backint
logfile
Backint
snmp_adapter
Interface handler
nt_event_log
TSI/Mercator
nt_event_log
Tivoli Framework
DM (universal, TME)
TEC
DM (universal)
Netview
DM (universal)
Netview
netview
snmp
PSSP
sp_tec_agent
HACMP
errpt
HACMP
snmp
HACMP
clinfo
AIX
errpt
AIX
DM (unix)
AIX
logfile
Windows NT
nt_event_log
Netfinity
snmp
Quota Manager
nt_event_log
Diskkeeper
nt_event_log
McAfee
nt_event_log
Kixstart
nt_event_log
Directory Replicator
nt_event_log
Spooler
nt_event_log
243
The following table (Table 11) shows event sources related to network
devices.
Table 11. Element List: Network Devices
Event Source
8224_snmp_MIB
8260_snmp_MIB
8265_snmp_MIB
8274_snmp_MIB
Access routers
2503_snmp_MIB
fsms100_snmp_MIB
3-com switch-3000
3000_snmp_mib
3-com switch-1000
2000_snmp_MIB
2503_snmp_MIB
The following table (Table 12) shows event sources related to other systems
and devices.
Table 12. Element List: All Systems
244
Event Source
RS/6000 SP nodes
errpt
RS/6000 SP nodes
sp_tec_agent
RS/6000
errpt
SP Switches
sp_tec_agent
SP Frames
sp_tec_agent
SP Control Woorkstation
snmp_MIB
SP Control Woorkstation
errpt
errpt
snmp_MIB
adsm
nt_event_log
errpt
Event Source
Adapters
errpt
Adapters
DM (unix)
Adapters
netview
Disks
errpt
NT Servers
nt_event_log
NT Server Disks
nt_event_log
Netfinity Server
nt_event_log
nt_event_log
Internal Storage
nt_event_log
Internal Storage
errpt
SP Power Supply
SP_snmp_MIB
RS Power Supply
errpt
errpt
nt_event_log
Network Interfaces
DM (unix)
Security
logfile
Security
nt_event_log
WINS
nt_event_log
DHCP
nt_event_log
DM (oracle)
DM (oracle)
DM (oracle)
ccms
DM (TME)
Print Queues
nt_event_log
Print Queues
logfile
245
These three tables clearly give an idea of the complexity of your environment
in terms of monitoring. To create a workable solution, first most of these
events must be reduced in amount. Secondly, how could we manage this
environment in terms of: What is the root-cause of the problems if several
events are sent to TEC at almost the same time? How could you effectively
monitor your environment?
There must be some guidelines or some way to work this situation out;
otherwise, there will be no effective monitoring process, and that could
negatively affect your organization. To manage the environment, and so
managing the events, some methods must be used. So, in this case, we will
be using a methodology that was previously called: Event Management
Design Methodology. Now this methodology is called: Event Management
Design/Monitoring Design. A brief explanation about this method will be given
in the next section. And after this section, the monitoring result will be
presented.
6.4.4.1 Event Management Design/Monitoring Design (EMD/MD)
The Event Management and Monitoring Design Methodology is an IBM
design methodology that analyses a client's IT environment and creates a
tailored design for processing and correlation of the client's systems and
network events. More detailed information on this method can be found in the
redbook entitled Designing Tivoli Solutions for End-to-End Systems and
Service Management , SG24-5104.
246
Rules for
automatic actions
& filtering
systems
Helpdesk
Operations
network
events
applications
Level 2
Event Server
Level 3
During the filtering activity, for each area on the element lists, the Subject
Matter Experts (SME) must be consulted to identify the most important events
for their specific area. To come back to our scenario, and especially for
determining the monitoring requirements of SAP-related events, we
performed the following steps:
247
Selected the most important events from all event sources that can be
used for indicating availability.
The default monitoring collections regarding the performance indicator
(Buffer, Performance, Roll, and Page Area as described in 5.3.5, Default
monitoring on page 199) will not be used, but instead, they created
thresholds from SAP that actually will be read by the wr3mib adapter. This
is only the starting point because the SAP SMEs will be able to change for
themselves different monitoring thresholds for the Development (DEV),
Quality Assurance (QAS), and Production (PRD) SAP servers. Also, this is
the usual flow of the staggering implementations of SAP.
Creating extra monitors to detect the Oracle log file.
Creating extra monitors to detect the number of extents and the
extent-growth in the Oracle Tablespaces.
6.4.4.3 The Distributed Monitoring Solutions
In this section, we give the monitoring solutions to use for specific
environments to cover the availability and performance monitoring. This will
be presented in several tables. Also, an example of an event worksheet as
one of the deliverables from the Event Management Methodology is provided
in Figure 122 on page 258.
The following table (Table 13) shows an example of monitor definitions for the
R/3 Manager.
Table 13. Tivoli Manager for R/3 Monitors
248
Monitor
Description
Parameters
Timing
SAP System
Availability
Availability monitor:
Becomes
unavailable: FATAL,
Becomes available:
HARMLESS to
reset
N/A
Every 1 minute
Sentry2_0_countst
r
Occurrence of an
error ORA-0600 in
the ORACLE alert
log:
FATAL
Pattern: ORA-0600
Every 1 minute
Sentry2_0_countst
r
Occurrence of an
error ORA-1653 in
the ORACLE alert
log:
FATAL
Pattern: ORA-1653
Every 1 minute
Monitor
Description
Parameters
Timing
Sentry2_0_countst
r
Occurrence of an
error ORA-1654 in
the ORACLE alert
log:
FATAL
Pattern: ORA-1654
Every minute
Sentry2_0_filechk
Extent-growth in
relation to max.
extents:
>10% WARNING,
>20% CRITICAL
Output file of
sapdba -check
(All Tablespaces)
Every day
Sentry2_0_filechk
Number of extents
in relation to max.
extents:
>70% WARNING,
>80% CRITICAL
Output file of
sapdba -check
(All Tablespaces)
Every day
Daemon Status
Availability monitor
for SAP WR3MIB:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Daemon:
Tecad_wr3mib
The following table (Table 14) shows an example of monitor definitions for
Domino Manager.
Table 14. Tivoli Manager for Domino/Notes Monitors
Monitor
Description
Parameters
Timing
Program Status
Availability monitor
on Notes
processes:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Notes processes:
tivaddin, nevent,
nreplica, namgr,
nreport, nsched,
nserver, nupdate,
nrouter, nsmtpmta,
nservice, nosesctl,
nomsgcnv,
niseshlr, nisesctl,
nimsgcnv, ndrt,
nclrepl, ncldbdir,
nadminp
Every 15 minutes
249
The following table (Table 15) shows an example of monitor definitions for the
UNIX monitoring collection (default monitoring).
Table 15. UNIX Monitoring Collection: Default
250
Monitor
Description
Parameters
Timing
Percent Space
used
Threshold monitor
on file system:
>80% WARNING
>90% CRITICAL
<80% HARMLESS
to reset
File systems:
/var, /var/log, and
/tmp
Every 10 minutes
Percent Space
used
Threshold monitor
on file system:
>90% WARNING
>98% CRITICAL
<90% HARMLESS
to reset
File systems:
/home
Every 10 minutes
Percent Space
used
Collect monitor on
file system
File systems:
/var, /var/log, /tmp,
and /home
Every hour
Daemon Status
Availability monitor
on default UNIX
daemons:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Daemons:
errdemon, inetd,
errpt, portmap,
cron, qdaemon,
syslogd, snmpd,
srcmstr, syncd, init,
tecad_logfile
Available swap
space
Threshold monitor
on UNIX swap
space:
<20 Mb WARNING
<10 Mb CRITICAL
>40 Mb
HARMLESS to
reset
N/A
Available swap
space
Collect monitor on
UNIX swap space
N/A
Every hour
The following table (Table 16) shows an example of monitor definitions for the
UNIX monitoring collection (specific monitoring).
Table 16. UNIX Monitoring Collection: Specific
Monitor
Description
Parameters
Timing
Daemon Status
Availability monitor
on UNIX daemon
for ADSM:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Daemon:
dsmserv, dsmadmc
Percent Space
used
Threshold monitor
on file systems for
SP/2 CWS:
>80% WARNING
>90% CRITICAL
<80% HARMLESS
to reset
File systems:
/spdata, /tftpboot
Every 10 minutes
Daemon Status
Availability monitor
for SP/2 CWS
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Daemons:
hardmon, hbd, hrd,
kerberos, sdrd,
splogd
Daemon Status
Availability monitor
for SP/2 nodes
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Daemon:
Fault_service_
Worm_RTG_SP
251
Monitor
Description
Parameters
Timing
Daemon Status
Availability monitor
for all SP/2 nodes
and CWS:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Daemons:
haemd, hagsd,
hagsglsmd, hatsd,
xntpd, sp_configd
Daemon Status
Availability monitor
for HACMP:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Daemons:
clstrmgr, clsmuxpd
The following table (Table 17) shows an example of monitor definitions for the
Universal monitoring collection.
Table 17. Universal Monitoring Collection
252
Monitor
Description
Parameters
Timing
Remote Oserv
status
Threshold monitor
distributed to the
TMR server:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Every 10 minutes
Remote Oserv
status
Threshold monitor
distributed to all
TME servers in the
environment:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Every 10 minutes
Monitor
Description
Parameters
Timing
Application status
Availability monitor:
Becomes
unavailable:
CRITICAL
(including a Sentry
notice)
Becomes available:
HARMLESS to
reset
Applications:
All oracle-daemons
Every 15 minutes
Application status
Availability monitor:
Becomes
unavailable:
CRITICAL
(including Sentry
notice)
Becomes available:
HARMLESS to
reset
Applications:
All TEC-daemons
Every 15 minutes
The following table (Table 18) shows an example of monitor definitions for
TME monitoring.
Table 18. TME Monitors
Monitor
Description
Parameters
Timing
No of Oserv errors
Threshold monitor
Increase by 15:
CRITICAL
N/A
Every 15 minutes
Tivoli DB DirSpace
Threshold monitor
<20Mb CRITICAL
<40Mb WARNING
>40Mb
HARMLESS to
reset
N/A
Every hour
Tivoli DB DirSpace
Collect monitor
N/A
Every hour
253
The following table (Table 19) shows an example of monitor definitions for the
Oracle monitoring collection.
Table 19. Oracle Monitoring Collection
Monitor
Description
Parameters
Timing
Oracle Tablespace
Percent Space
used
Threshold monitor
on TEC Oracle
Tablespace:
>90% WARNING
>98% CRITICAL
<90% HARMLESS
to reset
TEC_DATA_TS
Every 1 hour
Oracle Tablespace
Percent Space
used
Collect monitor
TEC_DATA_TS
Every 1 hour
Oracle Tablespace
Percent Space
used
Threshold monitor
on Inventory Oracle
Tablespace:
>90% WARNING
>98% CRITICAL
<90% HARMLESS
to reset
TIVOLI_DATA_TS
Every 1 hour
Oracle Tablespace
Percent Space
used
Collect monitor
TIVOLI_DATA_TS
Every 1 hour
The following table (Table 20) shows an example of monitor definitions for the
Windows NT monitoring collection (default monitoring).
Table 20. Windows NT Monitoring Collection: Default
254
Monitor
Description
Parameters
Timing
Percent Free
Space
Threshold monitor
on Logical Disk
>80% WARNING
>90% CRITICAL
<80% HARMLESS
to reset
Every 10 minutes
Percent Free
Space
Collect monitor on
Logical Disk
Every hour
Monitor
Description
Parameters
Timing
NT Service Status
Availability monitor
on default
Windows-NT
services:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Services:
Computer Browser,
TCP/IP NetBIOS
Helper, Time
Helper, Tivoli
Remote Execution
Service,
Workstation,
EventLog, Alerter,
McAfee Task
Manager, McAfee
Alert Manager,
Messenger, Plug
and Play, Remote
Procedure Call
(RPC) Service,
Server,
TECNTAdapter,
ADSM Central
Scheduler Service,
Net Logon
Threshold monitor
on Windows-NT
paging file:
>80% WARNING
>90% CRITICAL
<60% HARMLESS
to reset
Paging file
C:\pagefile.sys
Collect monitor on
Windows-NT
paging file
Paging file
C:\pagefile.sys
Every 1 hour
Percent Processor
Time
Collect monitor
N/A
Average during an
hour
Interrupts/sec
Collect monitor
Processor
monitored
Average during an
hour
Collect monitor
Average during an
hour
Packets Outbound
Errors
Collect monitor
Network Interface 1
Average during an
hour
Packets Received
Errors
Collect monitor
Network Interface 1
Average during an
hour
255
Monitor
Description
Parameters
Timing
Processor Queue
Length
Collect monitor
N/A
Average during an
hour
The following table (Table 21) shows an example of monitor definitions for the
Windows NT monitoring collection (specific monitoring).
Table 21. Windows NT Monitoring Collection: Specific
Monitor
Description
Parameters
Timing
Percent Free
Space
Threshold monitor
on Logical Disk E:
on all TME servers
>80% WARNING
>90% CRITICAL
<80% HARMLESS
to reset
Logical Disk E:
Every 10 minutes
Percent Free
Space
Collect monitor on
all TME servers
Logical Disk E:
Every hour
NT Service Status
Availability monitor
on Windows-NT
ADSM service on
ADSM servers:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Service:
ADSM Server
NT Service Status
Availability monitor
on Windows-NT
services on:
AccountBDCs
ResourceBDCs
Services:
KiXtart RPC
Service, Directory
Replicator
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
256
Monitor
Description
Parameters
Timing
NT Service Status
Availability monitor
on Windows/NT
services on:
AccountPDCs
ResourcePDCs
Services:
Spooler, Netfinity
Support Program,
Quota Manager
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
The following figure (Figure 122) also shows an example worksheet that
includes the information about AIX errlog event definitions.
257
258
259
260
Servers
Workstations
Printers
261
that staff are unable to work to full capacity while the relevant access method
is corrected.
An ideal solution would enable all of the levels to be managed at once.
Standard access profiles could be created and distributed to the relevant
machines and users. This would make changes and updates a lot simpler.
Also, the solution would need to be centralized, thus, making the
implementation of user IDs and security requirements easier across the
entire organization.
6.5.2.3 Data
Data can be catergorized as the large RDBMS systems used with products,
such as SAP R/3, right down to the documents produced by the
aforementioned word processing packages. All of this data needs to be
stored, transmitted, and produced securely without unauthorized access,
either external or internal.
262
Global Enterprise Manager provides an easy to use and effective GUI that
operators can utilize to monitor and control the entire enterprise. It enables
the arrangement and management of resources by viewing them as a whole
enterprise. This makes it much easier to manage even a large enterprise, as
resources of all types can be arrange, manipulated, and viewed at random
with little trouble. It also enables better management of the resources as a
whole as problems can be spotted easily, as can security issues. Tivoli Global
Enterprise Manager simplifies and streamlines the management of any
enterprise or business system making it easier and more efficient to manage.
This give administrators more time to concentrate on defining and
implementing security and resource control policies and procedures.
6.5.4.2 Tivoli Security Management
Tivoli Security Management enables the management of security across
different platforms through the use of a role-based security model. With
263
264
265
This means that problems where users are not able to access a particular
resources because they have forgotten their password, or it has expired, are
reduced. Also, because the whole process is centralized, it means that any
problems a user may have can be identified and solved quickly so that little
time and productivity is lost over the correction and management of user IDs
and passwords.
6.5.4.6 Tivoli Output Manager
Tivoli Output Manager is a powerful tool for enterprise-wide output control. It
enables the coordination of routing paths, delivery, and, above all, security of
data.
This means that users have to go through the relevant authorization layers to
use the output network. This enables the use of user-to-user notifications and
reliable access control of the resources in the output network.
It almost removes the risk of documents being printed to the wrong area, as a
user in the Human Resources department would probably not have the
authority to use output devices in the Accounts department; therefore,
confidential information could not accidentally be printed in the wrong place.
It also means that SAP R/3 output is secure. Usually once data has been
passed from R/3 onto the output network, it is easily accessible to anyone
266
with the relevant packet sniffing software. This is also applicable to most
applications output; however, R/3 is not unique in this.
Routed Output Resources
Because Tivoli Output Manager is structured around a rule based foundation,
it means that when certain resources are down, fault tolerant routing rules
can be used to still deliver and notify the appropriate people of the different
path that was used. This is, of course, all calculated within the rules defined
for access to each resource type.
The rule engine can also respool and extract archive documents to output
resources if duplicates are detected. This is very useful for streamlining the
output environment and prevents large reports from duplicating over slow
network links between distribution centers.
Reliable and Secure Output Channels
The delivery path from the users workstation to the output resource is always
in an encrypted form. This means that data is secure, and even if packets are
intercepted, then the data contained in them is useless. This feature is
especially useful for delivering data across the Internet safely and securely.
Tivoli Output Manager provides definitions for secure output resources. This
allows the users to rely on the output network for delivery to all the secure
devices if a particular device is off-line.
Automated Delivery Channels
This option of Tivoli Output Manager allows the definition of rules on certain
output resources, for example, aggregate all printing from a certain print
server and archive the data onto disk.
267
268
269
270
271
The following diagram shows how the five components combine to provide
the overall application performance management solution.
272
Tivoli Management
Server
TAPM Front-End
User Interface
Profile push
and CLIs
Database
Engine
responses
Record
upload
Tivoli Management
Agent (Endpoint)
TAPM Back-End
TAPM Engine
Applications
Tivoli Management
Gateway
Data
collection
upload
Upcall Collector
273
9. Configured TAPM
10.Installed Sybase Adaptive Server Enterprise 11.9.2
11.Created Sybase Database for TAPM
12.Created the RIM object
13.Ran the TAPM database creation script
14.Installed Winrunner Quicktest for R/3
15.Created a Winrunner Testcase
16.Registered Winrunner Testcase to TAPM
17.Created Monitoring Profile
18.Distributed Monitoring Profile to Endpoints
19.Install Loadrunner on the Required Endpoints
As stated previously, the installation can be completed in a different order.
The database, for example, can be installed first even before Tivoli
Framework is installed. However, it will not be fully configured until TAPM is
installed. The previously ordered listed only shows the steps we took to install
TAPM and is not a recommended installation method.
274
275
276
We gave this Profile Manager the name tot16, as this was one of the
Endpoints that we were going to use to measure application performance.
Please note that the Dataless Endpoint Mode check box must be selected to
allow the rights to distribute to Endpoints.
7.2.1.3 Registering applications
Any applications that are to be monitored must first be declared to the TAPM
registry. This is a once only operation. Once an application has been
registered, you do not need to repeat this task in the future. This task can be
performed at any time up until the actual creation of the monitoring profiles.
Registering applications is achieved in the following ways:
277
2. Step 1 must then be repeated for all the applications that need registering,
then Step 3 shows how to register API instrumented applications and
simulation scripts.
3. At the command line, type the following command:
sh wmarreg.sh -a application_name [shell_script_name] |
[simulation_script_name -v]
278
279
selecting the application required and clicking the Schedule button. This will
give a dialog box as follows:
A start and end date must be set for the monitoring schedule. The start date
cannot be less than the current date, and the end date must be more than the
current date.
The collection interval can be set in increments of ten minutes, starting from
ten and going up 60 minutes, or once an hour. For the schedule to be
accepted, it must include at least one scheduling rule. To add a scheduling
rule, click the New Rule button and fill in the schedule as shown in the
following figure:
280
Once the schedule has been completely defined, click the Add & Close
button in the main schedule dialog as shown in Figure 129 on page 280. This
will add the monitoring schedule to the profile.
While creating the monitoring profile, it is necessary to state what data, if any,
will be saved to the TAPM database for analysis or reference later. The
database settings are found on the Add Entry to the Profile dialog as seen in
Figure 128 on page 279. Clicking the Database Settings button will produce
an dialog as follows:
281
The default settings are as shown in Figure 131. Change them to any desired
values and then click Add & Close to apply those settings. It is important to
remember that the greater the level of detail selected, the faster the database
will grow in size.
The final act is to click the Add & Close button on the Add Entry to the Profile
dialog as shown in Figure 128 on page 279. This will cause the Application
Availability Profile dialog to be displayed again. It should now look something
like as follows:
282
Clicking on the Enable and Disable buttons will allow the activation and
deactivation of individual monitoring profiles. The final act in creating the
profile is to close this dialog by selecting Profile and then Close.
7.2.1.5 Adding subscribers and distributing the monitoring profile
The final two actions that need to be taken before the profiles actually
become active, is to add subscribers for the profile and then distribute it to
those subscribers. Adding subscribers is achieved as shown in the following
diagram:
283
Once all the desired subscribers have been selected, click the Set
Subscriptions & Close button to apply those subscribers.
The final task is to distribute the profile to relevant Endpoints. This is
achieved as demonstrated in the following figure:
284
This will cause the profile created about to be distributed to the specified
Endpoints. Monitoring will begin immediately; however, as specified above,
data will only be upload to the database once every day. The default time is
midnight.
7.2.1.6 Installation of Sybase Adaptive Server Enterprise
The next step we performed was the installation of Sybase Adaptive Server
Enterprise 11.9.2. This was an evaluation copy downloaded from the Sybase
Web site on a limited license. We then created a database called tapm_db on
our Sybase server and changed the sa users password to be tapmtapm. For
detailed instructions of how to install Sybase and create a new database,
please see the relevant Sybase documentation and manuals.
Note
All the commands examples in the following section were executed from a
bash shell.
285
The next step was to create the RDBMS Interface Module (RIM) object so
that TAPM could communicate with the database and configure it. The format
of the command to create a RIM object is as follows:
wrcrtrim [-i] [-v vendor] [-h hostname | -o host_oid] [-d database] [-u
user] [-H rdms_home] [-s server_id] [-I instance_home] rim_name
The following table shows the details for the database that we created.
Table 22. Configuration Details for out TAPM Database
wcrtrim Parameter
Value
Vendor
Sybase
Hostname
pokibmtapm
Database
tapm_db
User
sa
RDBMS Home
d:\Sybase
Server ID
pokibmtapm
rim_name
tapm
This command created the RIM object, and we verified the correct creation by
typing:
wgetrim tapm
The RIM connection was then tested with the following command:
isql -U sa -S pokibmtapm -D tapm_db -P tapmtapm
This showed that the RIM object had been created successfully, and the next
step was to run the database configuration script.
286
Information
Although we created our RIM object manually, there is a script that can be
used to help with this process. It attempts to get RIM object attributes. Any
that it cannot discover, the user is prompted to enter.
The script can be found in $BINDIR/TME/MAR/SQL directory and can be
executed by typing:
./cr_tapm_rim.sh
The configuration of the database is achieved by the use of a script that can
be found in the directory listed in the information box above. To execute the
script, type the following command:
./cr_tapm_db.sh
This script is mostly automatic. It tries to retrieve the RIM object attributes
and, if successful, configures the database. However, under certain
circumstances and configurations, it may be necessary to provide it with extra
information. For more detailed information on how to install and configure a
TAPM database, please refer to the relevant documentation.
The script creates a number of tables in the TAPM database. The following
screenshot shows the tables after creation in our Sybase database:
287
Winrunner is easy to use, and you can simulate users easily using this
product. The first step is to actually decide what business processes are to be
simulated. For the purpose of this project, we decided to use a simple set of
functions that an administrator might perform to check the system in the
morning. This was just to test the functionality of TAPM itself. Winrunner will
allow the complete simulation of business processes. It will even simulate the
entry of different sorts of data from prepared data files. For the purpose of
this test, we decided to simulate the following:
Logon
Checking batch processing (sm37)
Checking the system log (sm21)
Checking the application servers (sm51)
288
Log off
To create a basic test case in Winrunner is easy. All that is required is that a
new business process can be created. This is achieved as follows:
Click on the
icon. This adds a New Business Process to the test case.
This first one was renamed Logon.
It is then necessary to add an R/3 connect and then a logon step to this
process. This is done as shown in the following figure:
It is then necessary to add a logon step to the business process. This can be
seen in Figure 137 just below the R/3 Connect step. Adding this step is
289
achieved in the same way. The only difference is in the values that need to be
entered.
To record another business process, it is necessary to add another blank
business process to the test case. This one was renamed sm37, as this was
the transaction that was used for this step. The recording of user interaction is
simple. Once a step has been created, a user just needs to press the record
button.
Then, return to a running SAP session and execute the steps that are to be
recorded. For example we recorded the following for this step from the initial
GUI screen after login:
/nsm37
Set Username to *
Set From time to 00:00
Set To time to 23:59
Enter
Opened the COLLECTOR_FOR_PERFORMANCEMONITOR job log.
Step back to the screen you started from.
It is then necessary to press the stop recording button in Winrunner.
Once the recording has been completed, the step should look as follows:
290
291
This dialog allows the setting of a Simulation Interval, that is, how often the
script will be run during the pre-defined monitoring periods. Set the desired
interval time and click the Add & Close button to save this information.
Once the distribution has been completed, it can be found on the Endpoints in
the C:\tivoli\lcf\dat\1\Mar\vus directory as a tar file.
7.2.1.8 Installing Loadrunner on an Endpoint
For any virtual user script to execute successfully, a program called
Loadrunner must be installed on each Endpoint that is going to run the virtual
user script. Loadrunner can be found in the Loadrunner directory on the
TAPM CD-ROM. Run the setup program to install this program.
7.2.1.9 Final notes on TAPM
Once all the above steps have been completed, the monitoring of the SAP
R/3 application performance should be possible. As stated before, data
collected throughout the course of a day is uploaded to the TAPM database,
once a day at midnight, after it has gone through an aggregation process on
the Endpoint. This data can then be accessed by Tivoli Decision Support to
provide accurate data for the defining of service levels, availability profiles,
and, of course, performance.
292
293
There are several TDS Discovery Guides that are shipped with the product.
Other guides are available as additional options. Since Tivoli is frequently
announcing availability of new Discovery Guides, please refer to
http://www.tivoli.com
294
Operating Systems
Windows NT 4.0
Windows 95
Database Management Systems
Oracle
Sybase
SQL Server 6.5
Informix
DB2
295
ODBC
INVENTORY
DM
TEC
DATABASES
Client system
running Discovery
Interface
Client system
Client system
running Discovery running Discovery
Interface
Interface
Enterprise
database system
ODBC
System running
Administrator and client
296
Note
Tivoli Decision Support for SAP R/3 was a work-in-progress during this
project. The features and functions described in the following section are
subject to change without notice any time before or after general release.
The purpose of this Discovery Guide is to supply data to help plan the R/3
resources growth. Most of the performance problems are results of system
workload gradually growing to the point where it exceeds the capacity of the
systems or because soft errors gradually increase in volume until a
catastrophic hard error occurs.
Based on the numbers of variables involved in deciding what systems to
monitor, dates and times to retrieve data, the variations in SLA values, and in
order to extract data from the database repository, TDS for SAP R/3 makes
use of a tool called R/3 Collector. The R/3 Collector is a Windows NT-based
tool that allows the input of the necessary information required to retrieve
data from each server that the analysis is required. It also allows the input of
the necessary information to exclude transactions, programs, or user IDs that
are not required to be part of the reports.
The Tivoli Decision Support for SPA R/3 provides the following capabilities:
Gathering and reviewing information based on key questions and reports
that address issues, such as performance, service level agreement, server
workload, and transaction tuning.
297
298
299
Example 2
The line chart (Figure 144) displays the percentage of dialog steps that are
less than the dialog response time entered in the TDS for R/3 Collector
Service Level Agreement configuration section. This chart displays each
system as a different line with data points being taken each day.
300
Example 3
The following report (Figure 145) shows each transaction code by average
response time.
301
Example 4
The following chart (Figure 146) shows R/3 load balance analysis. In this
chart, we focus on the data of 1999/09/21.
302
Example 5
As you can see, the following chart (Figure 147) shows the data of
1999/09/21 by servers.
303
304
305
Tivoli GEM
Console
Tivoli GEM
Server
TEC Server
Events
Tivoli GEM
Console
Tasks
Events
Tivoli GEM
Console
306
TMA, each Tivoli GEM component contains the following software (refer to
Figure 149):
Managed Node
Managed Node
Tivoli GEM
Topology Server
+
Framework
Tivoli GEM
Topology Console
+
Java
TMR Server
Tivoli GEM Instrumentation
for Tivoli Manager for R/3
+
TEC ACF
+
Software Distribution
+
Framework
Tivoli GEM
Event Enablement
+
TEC Server
+
Distributed Monitoring
+
Framework
Events
TEC Server
Tivoli GEM
Console
Tivoli GEM
Server
Managed Node
(Endpoint Gateway)
Events
Tasks
downcall
upcall
TMR Server
Java
+
TEC ACF
+
Software Distribution
(Gateway Module)
+
Distributed Monitoring
+
Framework
Endpoint
Java
The following table (Table 23) shows detailed information about the software
configurations for the Tivoli GEM environment.
Table 23. Tivoli GEM Software Configurations
Tivoli
Component
GEM
Required Software
Versio
n
2.2.1
1.1.7
2.2.1
Tivoli Framework
3.6.1
307
Tivoli
Component
GEM
Endpoint Gateway
Endpoint
TMR Server
Required Software
Versio
n
2.2.1
3.6.1
Distributed Monitoring
3.6.1
Tivoli Framework
3.6.1
1.1.7
3.6.1
Software Distribution
3.6.1
Distributed Monitoring
3.6.1
Tivoli Framework
3.6.1
1.1.7
3.6.1
2.0
3.6.1
Software Distribution
3.6.1
Tivoli Framework
3.6.1
In this environment, to manage your SAP R/3 resources by using Tivoli GEM,
you need to install and configure Version 2.0 of Tivoli Manager for R/3
properly.
As you can see, each component of Tivoli GEM requires many prerequisites
including non-Tivoli modules; so, the installation processes of Tivoli GEM
environment is a bit complicated. In this project, we installed each Tivoli GEM
component in the following order:
1. Install and configure JDK.
2. Install and configure Tivoli GEM Topology Server.
3. Install and configure Tivoli GEM Event Enablement.
4. Install and configure Tivoli GEM Topology Console.
5. Install and configure Tivoli GEM Instrumentation for Tivoli Manager for
R/3.
308
Note
Since our Version 2.0 of Tivoli Manager for R/3 environment has been
already completed, we are not going to explain installation and
configuration related to the R/3 Manager in this chapter.
The following sections introduce the overview of each software installation.
7.4.2.2 Java Development Kit installation
Tivoli GEM implements Java interfaces. Therefore, when you configure Tivoli
GEM, you need to install the Java Development Kit (JDK). As we mentioned,
JDK is required to be installed in the following Tivoli GEM components:
In this Web site, you will be able to find the following download page (refer to
Figure 150):
309
At the download page, you can download the latest version of JDK. The JDK
is provided for each platform; so, you need to download the appropriate JDK.
Note
When you use the IBM Java Web site that we introduced, you need to
register your information before downloading. Then, you will be able to get
the user ID for accessing the Web page. This registration process will take
approximately one day.
After downloading JDK, you install JDK on each Tivoli GEM component that
you need JDK. The installation process of JDK is quite simple. In our case,
we installed JDK in the following platforms:
AIX V4.3.2
Windows NT V4
310
You can find the Tivoli GEM Topology Server V2.2.1 module in the Tivoli GEM
installation CD-ROM. If you complete the installation successfully, the
following messages are displayed (refer to Figure 152):
311
312
313
314
Windows NT 4
Sun Solaris 2.6
In this project, we configured Tivoli GEM Console on the Tivoli GEM Server
machine. You can find the Tivoli GEM Topology Console V2.2.1 module in the
Tivoli GEM installation CD-ROM. The Tivoli GEM Console can also be
installed by using Tivoli Desktop (for Managed Nodes) or by using
InstallSheld (for non Managed Node). The following figure (Figure 155) shows
the Tivoli GEM Topology Console installation screen on Tivoli Desktop.
315
Once you complete the Tivoli GEM Console installation, you can find the
Tivoli GEM Console icon on Tivoli Desktop as follows (refer to Figure 157).
316
TMR Server
You can find the Tivoli GEM Instrumentation for Tivoli Manager for R/3 V2.0
module in the Tivoli Manager for R/3 V2.0 installation CD-ROM. The Tivoli
GEM Instrumentation for R/3 Manager can also be installed by using Tivoli
Desktop as follows (refer to Figure 158):
317
318
Figure 159. Tivoli GEM Instrumentation for R/3 Manager Installation Completion
Once you complete the Tivoli GEM Instrumentation for R/3 Manager
installation, you can find the new policy region and three new task libraries
that are contained in the new sub-policy region in Tivoli Desktop as follows
(refer to Figure 160):
319
These task libraries are used for Tivoli GEM operations. The following
sections introduce the configuration processes of Tivoli GEM.
320
This configuration order is just an example, and you can change this order.
However, some configurations must be done before the specific
configuration. Therefore, if you do not have a special reason, we
recommend you follow this order.
The following sections introduce the overview of each configuration process.
7.4.3.1 Configuring TEC Event Server
To import the TEC new classes and rules, you need to run the Configure
Event Console task that is provided by the Tivoli Manager for R/3. When you
use Tivoli GEM for managing your SAP R/3 systems by using Tivoli GEM
Instrumentation for R/3 Manager, this configuration is necessary to include
additional R/3 Manager Instrumentation event classes and rules
(sap_gemevents.rls) in the TEC rule base even if you have already configured
TEC Event Server for R/3 Manager. The Tivoli GEM Instrumentation for R/3
Manager rule file (sap_gemevents.rls) includes TEC rules that forward all R/3
Manager monitor events to the Tivoli GEM Server.
After installing Tivoli GEM Instrumentation for Tivoli Manager for R/3 module,
run the Configure Event Console task (refer to Figure 161).
321
Then, the additional event classes and rules for Tivoli GEM Instrumentation
for R/3 Manager (sap_gemevents.rls) are imported and updated in the TEC
rule base.
7.4.3.2 Configuring Event Enablement
After Tivoli GEM Instrumentation for R/3 Manager is installed, you need to
configure the workstation environment for use with instrumented business
components on the Tivoli GEM Server. To do this, you need to perform the
following processes on the Tivoli GEM Server.
1. To update the TEC rules and event classes for event enablement, run the
ihsttec.sh script that is located in the following directories:
%BINDIR%\TDS\EventService (for Windows NT)
$BINDIR/TDS/EventService (for UNIX)
322
To forward events to one or more servers, edit the ihsttec.cfg file to specify
the location of the servers to which TEC events should be forwarded.
Enter the following line for each server that should receive events.
SERVER_HOST=hostname
Where, the hostname specifies the name of the host where the server is
installed.
7.4.3.3 Setting up the Tivoli GEM Console user accounts
To log in to the Tivoli GEM Console, the user ID and password must be
defined on the machine where the Tivoli GEM Server is running. The Tivoli
GEM Console login user ID will be rejected unless it belongs to either:
323
In this configuration, you can configure the already existing user as a Tivoli
GEM Console user. For example, you can configure Administrator user as
a Tivoli GEM Console user on Windows NT system.
7.4.3.4 Configuring the Windows NT service
To run the Tivoli GEM Topology Server process as an Windows NT service,
you need to configure the Windows NT service on the Tivoli GEM Server. To
do this, you need to execute the following command that is contain in the
%BINDIR%\TDS\server\bin directory:
service account_name password
password
After performing this operation, the Tivoli GEM Server process is installed as
two Windows NT services. These are the server and the topology
communications server. Then the startup option is set manually. Therefore, to
start the Tivoli GEM Server process (server and topology communications
server) automatically each time the Tivoli GEM Server machine is rebooted,
you need to change the startup option from manual to automatic by using the
Windows NT service control applet.
Note
When you need to remove the service related to the Tivoli GEM Server
(server and topology communications server), you can use the following
command that is contained in the %BINDIR%\TDS\server\bin directory:
service delete
324
for R/3 provides the BDF, CDF and icon files that are used for Tivoli GEM.
These files can be found in the R/3 Manager installation CD-ROM. To import
the BDF, CDF, and icon files, you need to load the application management
package (AMP) file.
To do this, select File -> New AMP on the Tivoli GEM Console (refer to Figure
163). Then, specify the AMP file name (\GEMFILES\sapr3.pkg) in the R/3
Manager installation CD-ROM.
New AMP
325
When you run the task, you should run the task on all R3System,
R3AppServer, and R3DBServer objects. The following figure (Figure 165)
shows the task execution option screen.
326
As you can see, to monitor the up-to-date status of all SAP R3 managed
resources, we specified all SAP R/3 managed resources (R3System,
R3AppServer, and R3DBServer) as the target of the task. As a result, the
Tivoli GEM heartbeat will be performed to all SAP R/3 managed resources in
the TMR. If the task is completed successfully, the following messages are
displayed (refer to Figure 166).
327
You can also confirm the setting of the Tivoli GEM heartbeat on the TEC
console as follows (refer to Figure 167).
328
Note
When you do not run the Send GEM Heartbeat task on the specified SAP
R/3 managed resource, the SAP R/3 managed resource may be displayed
as unknown status on the Tivoli GEM Console because there is no way to
monitor the up-to-date status of that SAP R/3 managed resource. To avoid
this situation, we recommend you to run the Send GEM Heartbeat task on
all SAP R/3 managed resources in your management environment. We will
introduce the unknown status in Using Tivoli GEM for SAP R/3
management on page 329.
329
330
As you can see, the life cycle toolbar shows four different functions as follows:
Plan
Build
Verify
Control
331
332
333
To monitor or control your SAP R/3 managed systems, normally you use the
control mode screen. The following sections introduce how you can manage
the SAP R/3 managed systems by using the control functions of Tivoli GEM.
7.4.4.2 Displaying the topology information
If you configure Tivoli Manager for R/3 and Tivoli GEM properly, Tivoli GEM
can automatically display the topology information of your SAP R/3 managed
resources graphically on the Tivoli GEM Console. This is very user-friendly
and easy to understand in managing your complicated SAP R/3 environment.
The following figure (Figure 173) shows the topology information of our test
environment in this project.
334
335
As you can see, Tivoli GEM displays the topology information by using the
business tree. In this screen, the lower layer in the tree shows more specific
information, and the upper layer in the tree shows the entire information.
For example, in our case, we configured the R/3 application server and
database server on the same system. Therefore, the upper layer shows the
R/3 systems (wwdn07_IG3 and is1n05_PD9) that we configure our TMR, and
the lower layer shows the R/3 application server (wwdn07_IG3_00) and R/3
database server (wwdn07_IG3_DB) that are configured in the wwdn07_IG3
R/3 system.
In this example, SAP R/3 environment is not complicated. However, in a
large-scale SAP R/3 systems environment, it will be very complicated. Tivoli
GEM can manage this kind of SAP R/3 systems environment easily and
efficiently by using the user-friendly GUI.
7.4.4.3 Displaying the SAP R/3 Resource Properties
In the Tivoli GEM Console, you can refer to the SAP R/3 resource properties
easily. At the SAP R/3 resource that you can refer to its properties, click your
right mouse button to show the pull down menu. On this menu, select the
resource properties menu. The following figure (Figure 174) shows this
processes.
336
As you can see, Tivoli GEM provides the pull-down menu bar, and we can
refer to a lot of information by using this menu bar (refer to the Figure 175).
The following section introduces the typical example of the information that
can be obtain from the menu bar.
337
Figure 175. The Pull-Down Menu Bar of SAP R/3 Application Server
338
As you can see, in the Tivoli GEM event viewer, you can monitor the same
events that are displayed on the TEC console. In this event viewer, you can
also change its properties. For example, to filter the displayed events, you can
modify the severity attributes by using the following screen (refer to Figure
177).
339
340
As you can see, the information that can be obtained by running task on the
Tivoli GEM Console is absolutely same as the result of the task execution on
Tivoli Desktop. You can use the same way to run other tasks on the Tivoli
GEM Console.
7.4.4.6 Displaying the Monitor Status
In the Tivoli GEM Console, you can also display all running monitors on the
specific SAP R/3 server. To do this, you just need to double-click the icon of
the specific R/3 server that you would like to display all running monitors.
Then, the following running monitors status are displayed (refer to Figure
179).
341
Figure 179. The Running Monitors Status of SAP R/3 Application Server
If you do not execute this task on some SAP R/3 managed resources, it will
be displayed as the unknown status in the Tivoli GEM Console. The following
figure (Figure 180) shows how the unknown status object is displayed on the
Tivoli GEM Console.
342
As you can see, in this example, the R/3 system (wwdn07_IG3) and R/3
database server (wwdn07_IG3_DB) are displayed with a shadow. Normally, if
the status is normal, the R/3 object is displayed without a shadow.
To avoid this situation, we recommend you to run the Send GEM Heartbeat
task on all your SAP R/3 managed resources. Then, the Tivoli GEM keep
monitoring the up-to-date status of each object and displays them properly.
7.4.5 Conclusion
As you can see, Tivoli GEM is able to provide a lot of information and enables
you to perform a lot of operations on the Tivoli GEM Console. Basically, most
of the information and operations are based on TEC or Tivoli Manager for
R/3. However, in other words, you can do almost everything about SAP R/3
management operations on the Tivoli GEM Console instead of Tivoli Desktop.
The Tivoli GEM Console GUI is user-friendly and highly configurable, and
each of the functions are integrated into the Tivoli GEM Console smartly. It
allows you to perform seamless management.
343
Tivoli GEM provides the next generation of SAP R/3 management and
application management style.
344
345
346
The following sections show all event classes for R/3 Manager.
Event Class
Description
SAP_ALERT_StateChange
SAP_ALERT_SAPsysUp
SAP_ALERT_SAPsysDown
SAP_ALERT_SlogId
347
348
Event Class
Description
SAP_ALERT_SlogFreq
SAP_ALERT_Buf
SAP_ALERT_Enqueue
SAP_ALERT_Rollpag
SAP_ALERT_Trace
SAP_ALERT_DpQueue
SAP_ALERT_PerfDia
SAP_ALERT_PerfUpd
SAP_ALERT_PerfBtc
SAP_ALERT_PerfSpo
SAP_ALERT_AbapUpd
SAP_ALERT_AbapErr
SAP_ALERT_AbapSql
SAP_ALERT_DbIndcs
SAP_ALERT_DbFreSp
SAP_ALERT_DbArcSt
SAP_ALERT_DbBckup
SAP_ALERT_Spo
Spool alert.
SAP_ALERT_Arch
Archive alert.
Event Class
Description
SAP_ALERT_GenP3
SAP_ALERT_GenP4
SAP_ALERT_GenP5
SAP_ALERT_GenP6
SAP_ALERT_GenP7
SAP_ALERT_GenP8
SAP_ALERT_GenP9
SAP_ALERT_GenP10
SAP_ALERT_GenP11
SAP_ALERT_GenP12
SAP_ALERT_GenP13
SAP_ALERT_GenP14
SAP_ALERT_GenP15
Event Class
Description
SAP_ALERT_ABAP_ERR
SAP_ALERT_ABAP_SQL
SAP_ALERT_ABAP_VB
SAP_ALERT_BUFF_CUA
SAP_ALERT_BUFF_DBST
349
350
Event Class
Description
SAP_ALERT_BUFF_FTAB
SAP_ALERT_BUFF_IRBD
SAP_ALERT_BUFF_PRES
SAP_ALERT_BUFF_PXA
SAP_ALERT_BUFF_SNTAB
SAP_ALERT_BUFF_TABL
SAP_ALERT_BUFF_TABLP
SAP_ALERT_BUFF_TTAB
SAP_ALERT_DB_ARCSTUCK
SAP_ALERT_DB_BACKUP
SAP_ALERT_DB_FREESPC
SAP_ALERT_DB_INDICES
SAP_ALERT_DB_OPTMSTAT
SAP_ALERT_DPQU_BTC
SAP_ALERT_DPQU_DIA
SAP_ALERT_DPQU_ENQ
SAP_ALERT_DPQU_SPO
Event Class
Description
SAP_ALERT_DPQU_V2
SAP_ALERT_DPQU_VB
SAP_ALERT_ENQU_ENQ
SAP_ALERT_GENP_03
SAP_ALERT_GENP_04
SAP_ALERT_GENP_05
SAP_ALERT_GENP_06
SAP_ALERT_GENP_07
SAP_ALERT_GENP_08
SAP_ALERT_GENP_09
SAP_ALERT_GENP_10
SAP_ALERT_GENP_11
SAP_ALERT_GENP_12
SAP_ALERT_GENP_13
SAP_ALERT_GENP_14
SAP_ALERT_GENP_15
351
352
Event Class
Description
SAP_ALERT_GENP_ARCH
SAP_ALERT_GENP_SPO
SAP_ALERT_OSCO_FILE
SAP_ALERT_OSCO_LOAD
SAP_ALERT_OSCO_PAGE
SAP_ALERT_OSCO_SWAP
SAP_ALERT_PERF_BTC
SAP_ALERT_PERF_DIA
SAP_ALERT_PERF_ENQ
SAP_ALERT_PERF_SPO
SAP_ALERT_PERF_V2
SAP_ALERT_PERF_VB
SAP_ALERT_RLPG_PAG
SAP_ALERT_RLPG_ROL
SAP_ALERT_SAPsysDown
SAP_ALERT_SAPsysUp
SAP_ALERT_SLOG_FREQ
SAP_ALERT_SLOG_ID
Event Class
Description
SAP_ALERT_StateChange
SAP_ALERT_TRSW_TRSW
Event Class
Syslog Message
SAP_SYSLOG_A05
No memory available.
SAP_SYSLOG_A07
Timeout.
SAP_SYSLOG_A08
SAP_SYSLOG_AB0
SAP_SYSLOG_AB1
SAP_SYSLOG_B15
SAP_SYSLOG_B24
SAP_SYSLOG_B33
SAP_SYSLOG_BB2
SAP_SYSLOG_BS2
SAP_SYSLOG_BV3
SAP_SYSLOG_BV4
SAP_SYSLOG_BY1
DB error &5.
SAP_SYSLOG_BY2
SAP_SYSLOG_BY3
SAP_SYSLOG_BY4
SAP_SYSLOG_BYL
353
354
Event Class
Syslog Message
SAP_SYSLOG_BYM
SAP_SYSLOG_BYO
Deadlock occurred.
SAP_SYSLOG_BZ7
SAP_SYSLOG_BZ8
Output buffer (&5&5 bytes) is too small for the record (&5&5
bytes).
SAP_SYSLOG_BZW
SAP_SYSLOG_D01
Transaction termination &5 (&a &b &c &d &e &f &g &h &i).
SAP_SYSLOG_E11
SAP_SYSLOG_EAA
SAP_SYSLOG_EAS
SAP_SYSLOG_EAW
SAP_SYSLOG_EAY
SAP_SYSLOG_EAZ
SAP_SYSLOG_EB3
SAP_SYSLOG_EBF
SAP_SYSLOG_EBG
SAP_SYSLOG_EBH
SAP_SYSLOG_EBI
SAP_SYSLOG_ED6
SAP_SYSLOG_F3U
SAP_SYSLOG_F4B
SAP_SYSLOG_F5O
SAP_SYSLOG_F6H
SAP_SYSLOG_F7U
SAP_SYSLOG_F7Y
SAP_SYSLOG_F8M
Event Class
Syslog Message
SAP_SYSLOG_F8X
SAP_SYSLOG_FAI
SAP_SYSLOG_FAJ
SAP_SYSLOG_FAP
SAP_SYSLOG_FBA
SAP_SYSLOG_FBB
SAP_SYSLOG_FBI
SAP_SYSLOG_FBJ
SAP_SYSLOG_FBN
Spool is full.
SAP_SYSLOG_FCC
SAP_SYSLOG_GE0
SAP_SYSLOG_GEA
SAP_SYSLOG_GEG
SAP_SYSLOG_GEI
SAP_SYSLOG_GH0
SAP_SYSLOG_GI0
SAP_SYSLOG_GI6
SAP_SYSLOG_P00
SAP_SYSLOG_P05
SAP_SYSLOG_P0B
SAP_SYSLOG_Q0E
SAP_SYSLOG_Q0M
SAP_SYSLOG_Q0N
SAP_SYSLOG_Q18
SAP_SYSLOG_R00
SAP_SYSLOG_R05
355
356
Event Class
Syslog Message
SAP_SYSLOG_R0N
SAP_SYSLOG_R0O
SAP_SYSLOG_R0R
SAP_SYSLOG_R0S
SAP_SYSLOG_R18
SAP_SYSLOG_R1A
SAP_SYSLOG_R20
SAP_SYSLOG_R22
SAP_SYSLOG_R29
SAP_SYSLOG_R2B
SAP_SYSLOG_R33
SAP_SYSLOG_R38
SAP_SYSLOG_R3C
SAP_SYSLOG_R44
SAP_SYSLOG_R45
SAP_SYSLOG_R65
Update terminated.
SAP_SYSLOG_S05
SAP_SYSLOG_S07
SAP_SYSLOG_S0B
SAP_SYSLOG_S10
SAP_SYSLOG_S1F
SAP_SYSLOG_S8D
SAP_SYSLOG_SK0
SAPcomm: Error.
SAP_SYSLOG_SK3
Error (&A) at status update (spool open &B &C &D &E).
SAP_SYSLOG_ST0
SAP_SYSLOG_US1
Event Class
Syslog Message
SAP_SYSLOG_US2
SAP_SYSLOG_US3
SAP_SYSLOG_US4
SAP_SYSLOG_US6
Event Class
Monitoring Source
BATCH_SERVICE_MONITOR
Batch Performance
DIALOG_SERVICE_MONITOR
Dialog Performance
FIELD_DESC_BUFFER_MONITOR
GENERIC_KEY_BUFFER_MONITOR
INITIAL_RECORDS_BUFFER_MONITOR
LONG_RUNNING_PROCESS_MONITOR
MENU_BUFFER_MONITOR
OS_COLLECT_APSRVR_MONITOR
OS Collect - Application
Server
OS_COLLECT_DBSRVR_MONITOR
OS390_COLLECT_MONITOR
OS/390
OS390_DB2_MONITOR
OS/390 DB2
PAGE_AREA_MONITOR
Page Area
PROGRAM_BUFFER_MONITOR
ROLL_AREA_MONITOR
Roll Area
SAP_CANCELLED_JOB_MONITOR
Cancelled Job
SCREEN_BUFFER_MONITOR
SHORT_NTAB_BUFFER_MONITOR
357
Event Class
Monitoring Source
SINGLE_RECORD_BUFFER_MONITOR
SPOOL_SERVICE_MONITOR
Spool Performance
TABLE_DEF_BUFFER_MONITOR
UPDATE_SERVICE_MONITOR
Update Performance
WORK_PROCESS_DISPATCH_QUEUE_MONITOR
WORK_PROCESS_MONITOR
Work process
Event Class
Description
APSRVR_STATUS_MONITOR
SAP_APM_HEARTBEAT
AMS_R3MONITOR_ALERT
AMS_WR3MIB_PROCESS_ALERT
SAP_SYSLOG_RFC_ERROR
358
Event Class
Description
APM_HEARTBEAT
APM_THRESHOLD
359
360
Keyword
R/3 Reference
Attribute
Keyword
R/3 Reference
USER_CPU_UTIL
CPU Utilization
system (%)
SYSTEM_CPU_UTIL
IDLE_CPU_UTIL
SYSTEM_CALLS_SEC
st06 / System
calls/sec
Interrupts per
second
INTERRUPTS_SEC
st06 / Interrupts/sec
Number of CPUs
NUMBER_CPUS
st06 / Count
Load Average (1
min)
LOAD1_AVG
Load Average (5
min)
LOAD5_AVG
361
362
Attribute
Keyword
R/3 Reference
LOAD15_AVG
Context switches
per second
CONTEXT_SWITCH_SEC
st06 / Context
switches/sec
Physical Memory
PHYSICAL_MEMORY
Physical Memory
Free
FREE_MEMORY
PAGE_INS_SEC
PAGE_OUTS_SEC
Kilobytes paged in
per second
KB_PAGED_IN_SEC
st06 / Kb paged
in/sec
KB_PAGED_OUT_SEC
st06 / Kb paged
out/sec
Configured swap
space size
CONFIG_SWAP
st06 / Configured
swap kb
FREE_SWAP
st06 / Free in
swap-space kb
Maximum swap
space
MAX_SWAP
st06 / Maximum
swap-space kb
SIZE_SWAP
st06 / Actual
swap-space kb
DISK_UTILIZATION
DISK_WAIT_TIME
Disk kilobytes
transferred per
second
DISK_DATA_TRANSFER_SEC
st06 / Disk Kb
transferred/sec
DISK_RESPONSE_TIME
DISK_QUEUE_LENGTH
Attribute
Keyword
R/3 Reference
Disk average
service time
DISK_SERVICE_TIME
DISK_OPERATIONS_SEC
st06 / Disk
Operations/sec
LAN_PACKETS_IN_SEC
LAN_PACKETS_OUT_SEC
LAN_COLLISIONS_SEC
LAN Collisions
LAN_PACKET_IN_ERRORS_SEC
LAN_PACKET_OUT_ERRORS_SEC
Note: Disk values apply to the disk with the highest response time at the last sampling
period.
Attribute
Keyword
R/3 Reference
ROLL_AREA_FREE
ROLL_AREA_PERCENT_FREE
ROLL_AREA_SHARED_MEMORY
ROLL_AREA_SIZE
363
Attribute
Keyword
R/3 Reference
ROLL_CURRENTLY_USED
ROLL_AREA_PERCENT_USED
ROLL_FILE_SIZE
ROLL_MAX_USED
ROLL_MAX_PERCENT_USED
364
Attribute
Keyword
R/3 Reference
PAGE_AREA_FREE
PAGE_AREA_PERCENT_
FREE
PAGE_AREA_SHARED_
MEMORY
PAGE_AREA_SIZE
PAGE_CURRENTLY_USE
D
Attribute
Keyword
R/3 Reference
PAGE_AREA_PERCENT_
USED
PAGING_FILE_SIZE
PAGE_MAX_USED
PAGE_MAX_PERCENT_
USED
Attribute 1
Keyword
R/3 Reference
All
All
sm50 / Type
Dialog
Dialog
sm50 / Type
Update
Update
sm50 / Type
Update2
Update2
sm50 / Type
Batch
Batch
sm50 / Type
Spool
Spool
sm50 / Type
Enqueue
Enqueue
sm50 / Type
Attribute 1
Keyword
R/3 Reference
Free
Free
sm50 / Status
Waiting
Waiting
sm50 / Status
Running
Running
sm50 / Status
Stopped
Stopped
sm50 / Status
Completed
Completed
sm50 / Status
365
Attribute 1
Keyword
R/3 Reference
*******
*******
sm50 / Status
All
All
sm50 / Status
366
Attribute
Keyword
R/3 Reference
All
All
Dialog
Dialog
Update
Update
Update2
Update2
Batch
Batch
Spool
Spool
Enqueue
Enqueue
Nowp
Nowp
Attribute 1
Keyword
R/3 Reference
All
All
Dialog
Dialog
Update
Update
Update2
Update2
Batch
Batch
Spool
Spool
Enqueue
Enqueue
Attribute 2
Keyword
R/3 Reference
Threshold in seconds
Attribute
Keyword
R/3 Reference
Allocated Memory
ALLOCATED_MEMORY
Available Memory
AVAILABLE_MEMORY
DB Accesses
DB_ACCESSES
st02 / Database
accesses
DB Accesses Saved
DB_ACCESSES_SAVED
st02 / DB accesses
saved
Frames Swapped
FRAMES_SWAPPED
st02 / Frames
swapped
FREE_DIR_ENTRIES
367
368
Attribute
Keyword
R/3 Reference
PERCENT_FREE_DIR_ENTRIES
Free Memory
FREE_MEMORY
PERCENT_FREE_MEMORY
Hits
HITS
st02 / Hits
Hit Ratio
HIT_RATIO
LAST_RESET_DATE
LAST_RESET_TIME
MAX_DIR_ENTRIES
Objects Swapped
OBJECTS_SWAPPED
Quality
QUALITY
st02 / DB access
quality %
Requests
REQUESTS
st02 / Requests
Total Resets
TOTAL_RESETS
Used Directory
Entries
USED_DIR_ENTRIES
Used Directory
Entries Percent
PERCENT_USED_DIR_ENTRIES
Used Memory
USED_MEMORY
Used Memory
Percent
PERCENT_USED_MEMORY
Attribute
Keyword
R/3 Reference
FREQUENCY
RESPONSE
WAIT
Attribute
Keyword
R/3 Reference
MAX_ACTIVE_BP_PAGE
S
MIN_BP_HIT_RATIO
BP0_HIT_RATIO
BP2_HIT_RATIO
BP3_HIT_RATIO
BP32K_HIT_RATIO
BP_SHORTAGE
BP_HIPER
BP0_MAX_ACTIVE_PAG
ES
369
370
Attribute
Keyword
R/3 Reference
BP2_MAX_ACTIVE_PAG
ES
BP3_MAX_ACTIVE_PAG
ES
BP32K_MAX_ACTIVE_PA
GES
Deadlocks
DEADLOCKS
st04 / Deadlocks
Lock Suspensions
LOCK_SUSPENSIONS
st04 / Suspensions
Lock Timeouts
LOCK_TIMEOUTS
st04 / Timeouts
EDM_POOL_FULL_FAIL
URES
EDM_POOL_IN_USE
DYN_CACHE_HIT_RATIO
Number of times
MAXKEEPD was
exceeded
MAXKEEPD_EXCEEDED
st04 / MAXKEEPD
exceeded
CLOSE_THRESHOLD_R
EACHED
Commits
COMMITS
st04 / Commits
Rollbacks
ROLLBACKS
st04 / Rollbacks
Checkpoints
CHECKPOINTS
st04 / Checkpoints
Attribute
Keyword
R/3 Reference
CPU_UTIL
SYSTEM_CPU_UTIL
Paging Rate
PAGING_RATE_SEC
PAGE_INS_SEC
PAGE_OUTS_SEC
PAGE_INS_PRIVATE_SE
C
PAGE_OUTS_PRIVATE_S
EC
Pages to Expanded
Storage per second
PAGES_TO_EXPSTOR_S
EC
PAGES_FROM_EXPSTO
R_SEC
BLOCKED_PAGES_PAGE
D_IN
Blocks paged in
BLOCKS_PAGED_IN
UNUSED_INTERVAL_CO
UNT
Available frames in
expanded storage
EXPSTOR_AVAILABLE_F
RAMES
Migration age
MIGRATION_AGE
TOTAL_AVAILABLE_FRA
MES
371
372
SAP_Server_Monitors
373
SAP_Alert_Buffer (10)
AMS_WR3MIB_PROCESS_ALERT
The SAP_Alert class hierarchy is quite similar to Version 1.5 of R/3 Manager.
The major changes are:
The introduction of the SAP_Alert_Buffer class and the movement of the
ten buffer alerts from the SAP_Internal_Alert class to the
SAP_Alert_Buffer class.
The removal of the Heartbeat_event (and its six associated rules).
The event classes that appear on the TEC console are the:
SAP_MIB_Unique_Alert
SAP_Internal_Alert
SAP_Alert_Buffer
AMS_WR3MIB_PROCESS_ALERT
The SAP_MIB_Unique_Alert class includes the SAPsysUp, SAPsysDown,
and StateChange events. The first two are issued when the application server
starts up and shuts down, respectively. The last one is issued when on
operational mode switch occurs.
The AMS_WR3MIB_PROCESS_ALERT is an error alert. If this alert occurs,
there is most likely a problem with the alert_reader or alert_reader_cb scripts.
The removed event class is Heartbeat_event.
374
375
extracts the system label from the info slot and assigns it to the sub_source
slot.
Events for a particular application server are correlated by application server
triplet. Manager for R/3 provides this in both the hostname and sub_origin
slots. The event adapters set these slots. For DM monitors, the triplet is
passed in the "info" slot. A rule is provided that extracts the triplet from the
info slot and assigns it to the hostname and sub_origin slots.
The new extraction rules remove the 1.5 restriction that monitors must
originate from specially named profiles that start with the "system label"
name.
The following is rules:
set_r3sapname_slot (sap_monitor.rls/3)
Duplicate events are those that have the same values for a predefined set of
slots. Manager for R/3 provides rules to detect duplicate events and drop
duplicates.
All the true duplicate event processing applies to DM-based events. The
cancelled jobs events and the status events are new with 2.0. For these
events, the original is kept, its duplicate counter incremented, and the new
event is dropped. Processing of DM events from 1.5 was not changed; the old
event is dropped and the new event is kept. Note that it is particularly
important to keep the most recent status event.
376
377
Application server has come up. Since the application server is restarting, it
will take it some time to reach "steady state". This settling down interval is
assumed to be 35 minutes in the TEC rules. During this time, any events
(except for cancelled jobs) from the DM monitors are discarded since they are
assumed to be attributed to the application server startup. For example,
buffer attributes, response times, and storage area values are all subject to
fluctuation during this time.
378
Application server is up, but has undergone an operation mode switch. Since
the application server is restructuring its Dialog and Batch processes, it may
take it some time to reach "steady state". This settling down interval is
assumed to be 35 minutes in the TEC rules. During this time, the R/3 system
itself might be detecting buffer problems. These alerts are automatically reset
in the R/3 system (telling R/3 to discard this alert but continue to monitor for
the same threshold levels), and they are closed in TEC. In addition, all
DM-based events are essentially dropped.
The following are rules:
reset_certain_events_on_statechange (sap_tecad.rls/8)
drop_sentry_events_on_statechange (sap_default.rls/1)
There is a mismatch here. We should treat sysUp and stateChange the same
as far as allowable events. Presently, we handle them differently.
sap_default.rls 1 should not be dropping cancelled jobs during a mode switch
(state change).
379
380
SAP_Server_Monitors
SAP_MIB_Generic_Alert
SAP_Internal_Alert
SAP_SYSLOG_RFC_ERROR
The application server is down. We do not expect, nor want, any events
related to the application server except for those relating to state change. The
only event classes that will convey a state change are
SAP_MIB_Unique_Alert (SAP_Alert_SAPsysUp, SAP_Alert_SAPsysDown,
SAP_Alert_StateChange) and SAP_Status_Monitors
(APSRVR_STATUS_MONITOR).
In fact, this rule should really exclude the SAP_Alert_Buffer, SAP_SYSLOG,
and AMS_WR3MIB_PROCESS_ALERT events. However, since the
application server is down, we should not be getting any of these events
anyway.
We are especially concerned about dropping SAP_Server_Monitors and
SAP_SYSLOG_RFC_ERROR events since the function may be still be
running, but since there is no application server available, we may be getting
false events.
The following is rules:
sap_system_down_no_more_sentries (sap_monitor.rls/14)
Rule 14 should really exclude the SAP_Alert_Buffer, SAP_SYSLOG, and
AMS_WR3MIB_PROCESS_ALERT events.
381
forward_sap_events (sap_tecad.rls/13)
ack_sap_sentry_alert (sap_monitor.rls/16)
close_sap_sentry_alert (sap_monitor.rls/17)
Rules are provided to synchronize TEC actions with R/3 alert status. These
actions map the TEC actions of close/acknowledge to the R/3 actions of
reset/acknowledge.
Note that R/3 alert actions have the following meanings:
Reset
Problem is fixed.
382
These rules need to include SAP_Alert_Buffer class also. In 1.5 they were
SAP_Internal_Alerts and were closed. This got dropped in 2.0.
Synchronizing TEC events with closure actions in R/3 relies on the fact that
R/3 will generate a harmless alert for the condition being acted upon. The
same harmless alert is generated whether the R/3 administrator
acknowledged the alert or closed the alert. The harmless alert looks identical
to the original problem alert except for the different status. The original alert
may have been critical; the closed alert is harmless. This allows the TEC
rules to correlate the original TEC event with the new TEC event. If there is a
"duplicate" match, then the first TEC event is closed and the new event is kept
in its place. This is not a true duplicate. Since the new event is harmless, the
event will be dropped by the "harmless" rules.
The following is rules:
dup_sap_event (sap_tecad.rls/1)
Syslog alerts are syslog messages that have been tagged alertable in the R/3
system through transaction RZ06. When an alertable message is written to
the R/3 syslog, R/3 intercepts the message and also places an alert on the
383
SysMan for a Critical Syslog Message. As long as this alert is posted, R/3 will
not post any other syslog alerts. This is a shortcoming of the SysMan API.
Manager for R/3 1.5 addressed this problem by automatically resetting the
alert in an effort to allow subsequent syslog alerts to be generated. Even with
this TEC rule in place, it was still possible to miss syslog alerts.
The syslog adapter overcomes this shortcoming. The syslog adapter will
retrieve all syslog messages regardless of their alert status. With the syslog
adapter, it is no longer to tag syslog as alertable in RZ06.
This rule is being retained in 2.0 to maintain a bridge from the 1.5 release,
even though this processing is no longer really necessary.
The following is rules:
reset_syslog_alert (sap_monitor.rls/9)
Most of the alerts from the SysMan API are generic, meaning that they are
only high level indications of a problem in some area. They are not specific as
to the nature of the problem. For example, the SysMan will report a buffer
problem, but it will not indicate which R/3 buffer has the problem. To get the
detailed information, Manager for R/3 provides a drill-down rule. This rule
launches a TEC task (that launches a second task) to read the R/3 internal
alert information. The result of this process is a specific SAP_Internal_Alert
that provides the detailed alert information. For example, in response to the
buffer alert, drill-down might report that the PXA buffer has the problem.
The following is rules:
convert_mib_to_internal_alert (sap_tecad.rls/4)
384
GEM events require the sub_source slot to match the product identifier. Rules
are provided to set the sub_source to :Tivoli;R3Application;2.0:. In addition,
the monitor name is provided in its English description and the hostname slot
is set to the R/3 instance. This is done for all events of SAP_Server_Monitors
and SAP_Status_Monitors before they are sent to GEM.
The conversion of the SAP_APM_HEARTBEAT to APM_HEARTBEAT is done
to introduce a timing delay in the system between the creation of Manager for
R/3 objects and the creation of those objects in GEM.
The following are rules:
sap_gemevnts_rule1 (sap_gemevents.rls/1)
385
sap_gemevnts_rule2 (sap_gemevents.rls/2)
sap_gemevnts_rule3 (sap_gemevents.rls/3)
386
The host monitor was provided in 1.5 as a means to check the availability of
an R/3 server machine. It used the DM host monitors. This function was
dropped in 2.0, but the rules for handling the monitor results are still in the
product.
These rules are not really selective and will process any host status. There is
no way to make these R/3 specific.
The following are rules:
sentry_host_up (sap_monitor.rls/8)
sentry_host_down (sap_monitor.rls/9)
387
388
389
AIX
CICS
IBM
NetView
OS/390
SAP
Tivoli Enterprise
TME
Special notices
391
392
Collection Kit
Number
SK2T-2177
SK2T-6022
SK2T-8038
SK2T-8039
SK2T-8044
SK2T-2849
SK2T-8046
SK2T-8040
SK2T-8043
393
CD-ROM Title
Application Development Redbooks Collection
IBM Enterprise Storage and Systems Management Solutions
Collection Kit
Number
SK2T-8037
SK3T-3694
394
e-mail address
usib6fpl@ibmmail.com
Contact information is in the How to Order section at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl
Telephone Orders
United States (toll free)
Canada (toll free)
Outside North America
1-800-879-2755
1-800-IBM-4YOU
Country coordinator phone number is in the How to Order
section at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl
Fax Orders
United States (toll free)
Canada
Outside North America
1-800-445-9269
1-403-267-4455
Fax phone number is in the How to Order section at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl
This information was current at the time of publication, but is continually subject to change. The latest
information may be found at the Redbooks Web site.
395
Order Number
First name
Quantity
Last name
Company
Address
City
Postal code
Country
Telephone number
Telefax number
VAT number
Card issued to
Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.
396
List of abbreviations
AIX
Advanced Interactive
Executive
CLI
Command Line
Interface
DB2
Database 2
ERP
Enterprise Resource
Planning
FTP
GUI
Graphical User
Interface
IBM
International Business
Machines Corporation
ITSO
International Technical
Support Organization
LCF
Lightweight Client
Framework
R/3
Release 3
RDBMS
Relational Database
Management System
SAP
Systems Applications
and Products in Data
Processing
TCP/IP
Transmission Control
Protocol/Internet
Protocol
TEC
Tivoli Enterprise
Console
TMA
Tivoli Management
Agent
TME
Tivoli Management
Environment
TMR
Tivoli Management
Region
397
398
Index
A
ABAP 197, 238
ABAP file package 89, 129
access 265, 266
access method 263
account 324
administration task 36
administrator 44, 109, 125, 184, 264, 299
administrator group 323
administrator system 295
Administrator user 324
ADSM 42, 241
AIX 234, 241, 258, 310, 314
alert 128, 139
alert event adapter 83, 84, 158, 159, 185, 186,
208, 219
API 278
application 99, 227, 230, 232, 242, 262, 265
application management 21, 304, 317, 344
Application Management Package (AMP) 325
application performance 292
Application Proxy 62, 103, 122
Application Response Measurement (ARM) 26,
272
application server 4, 6, 52, 57, 62, 63, 69 , 72, 76,
78, 85, 95, 103, 115 , 122, 124, 128, 130, 131, 140,
142, 144, 145, 148, 152, 159, 160, 163, 165, 167,
168, 185, 186, 194, 201, 202, 203, 218, 223, 224,
234, 288, 336, 342
argument 166
ARM API 26
AS/400 232
attribute 100
authority 129
authorization 138, 197
authorization role 60, 122, 124
automatic discovery 18, 52, 66, 85, 128, 140, 144,
201
availability 227, 240
B
background process 233
BACKINT 43
backup 122, 123, 125
bandwidth 232
bandwidth optimization 16
baroc file 190, 219, 247
Baroc Files
sap_server_monitor_35.baroc 219
sap_tecad.baroc 219
tecad_wr3slog.baroc 219
bash 285
batch file 277
batch job 35, 52, 73, 164, 238
batch process 230, 235, 288
BDF 325
benchmark 30
buffer quality 200
business application 1, 240, 305
Business Application Programming Interface (BAPI)
35
business design 119
business function 2
business information 2
business operation 293
business process 3, 4, 20, 22, 241, 288
business system 8, 22, 65, 240, 305, 331
business system management 21
business tree 336
C
cancelled batch job 53
capacity planning 299
CCMS 17, 163, 184, 188, 197, 220
CDF 325
CD-ROM 64, 169, 173, 181
central monitor 194
centralized control 269
centralized location 51
character column 71
class object 93, 103
Classes
J class 88
Y class 88
Z class 88
CLI 38, 53, 70, 272
client capture 27
client machine 295
client server model 3, 25
Cognos PowerPlay 19
399
D
daemon 233
data 261
data file 130
database 3, 5, 51, 149, 202, 217, 234 , 239, 265,
272, 281, 285, 292, 295, 299, 304
database configuration 107
database server 4, 52, 57, 62, 115, 124, 128, 140,
141, 143, 144, 150, 152, 163, 167, 196, 202, 204,
207, 218, 234, 336, 343
database structure 293
DataHub 31
dataless profile manager 97, 131, 178
DB2 5, 31, 116, 234, 295
DB2 Enterprise Control Center (DB2 ECC) 31
DB2 UDB 31
DBA 31
dbaccess 167
default monitoring 199
de-install 85
delivery channel 268
delivery mechanism 293
400
E
e-business 2
elapsed time 26, 79
EMD/MD 246
encrypted form 45, 61, 268
end user 20
end user application performance 25
Endpoint 53, 72, 83, 91, 97, 103, 122, 124, 128,
132, 183, 272, 292, 309
Endpoint Gateway 63, 91 , 103, 108, 113, 122,
124, 128, 148, 272, 309
Endpoint Gateway database 92
Endpoint Manager 91
Endpoint method 90, 94
Endpoint method cache 91, 96
enterprise 227, 265, 267, 295
enterprise management 228
enterprise resource 228
ERP 2, 4, 21, 22, 235
errlog 258
error log 232
event 16, 52, 53, 89, 154, 186, 222, 239, 248, 305 ,
338
Event Adapter 15, 53, 84, 85, 128, 151, 160, 164,
185, 222, 247
event analyzer 27
event class 151, 190, 197, 219, 221, 305, 321
event correlation 15
Event Enablement 305, 308, 312, 322
event group 155, 157
event management 259
event repository 260
event severity 190
event slot 224
event source 155, 158 , 242, 247
event source group 89
Event Sources
SENTRY 222
WR3MIB 89, 158, 222
WR3SLOG 158
WRSLOG 89
executable program 277
exit code 150
Extended ERP (xRP) 3
F
fan-out 16
file 93, 265
file package 16, 37, 50, 132, 168, 171, 173, 176,
178
file server 241, 295
file system 232
filter 53, 186, 191, 239, 247
filtering capability 84
Framework function 91
fresh installation 85
ftp 169
function module 128, 136, 198
G
GEM Console 30, 305, 308, 314, 323, 324, 329,
342, 343
GEM event viewer 339
GEM heartbeat 325
GEM Instrumentation 50, 65, 305, 308, 317, 321
GEM log 340
GEM Server 305, 308, 310, 315, 321, 323, 324
GEM sign on screen 330
H
hard disk 110
hardware 107, 115, 230, 237, 261
harmless event 84, 222
heartbeat event 305
help desk 240
hierarchy 57
high-level view 331
historical data 297
hostname 108
HP-UX 314
hub 231
I
IBM 3
IBM Java Web site 310
icon 52, 54, 67, 72, 89, 132, 237, 279, 289
icon file 325
ID 58
IDL interface 103
import logfile 136
indicator 49, 58
indicator collection 56, 126, 199
Informix 5, 168, 295
infrastructure 242
installation 97, 119, 120, 169
InstallSheld 315
instance profile 139
integer column 71
interconnected TMR 53
interface function 62
internal alert table 188
Internet 45, 268
Internet business model 3
Internet-ready architecture 3
IP-based network 46
IT 3, 21
IT administrator 18
IT environment 246
IT infrastructure 9
401
ITS 6
K
Kerberos Security Registry 38
key word 73
L
language 146, 176
large-scale environment 49, 66
LCF architecture 93
life cycle toolbar 331
life-cycle management 33
load balance 299
Loadrunner 292
Local Area Network (LAN) 1
Lockdown Module 41, 264
log file 188, 234
logical design 120
login 36, 133, 139, 266
logoff 289
logon 288
long running process 53
Lotus Notes 241, 265
M
machine 262
Maestro 35
Managed Node 37, 38 , 62, 64, 83, 85, 97, 103,
122, 124, 128, 132, 142, 145, 148, 150, 160, 169,
178, 183, 211, 223, 309, 311, 315
managed resource 276, 304, 327
management discipline 8
Management Information Base (MIB) 237
management operation 91, 343
manual 168, 175
MarProfile 275, 279
master server 38
measurement agent 26
memory 110
402
network topology 46
Network X-Ray 28
NIS Domain 97
notice 274
notice group 274
Nowp type 82
performance monitoring 29
personal computer 1
physical architecture design 120
plan mode 332
platform 119, 132, 173, 178, 238, 265, 294, 310
platform type 72, 144
policy definition 36, 266
policy region 49, 55, 67, 86, 125, 142, 275, 319
Policy Regions
Manager for R3 126, 130, 141, 144, 163,
167, 169, 174
Manger for R3 199
R3 Configuration 127, 144, 164, 169, 174
policy-based management 18
predefined monitor 37, 199, 204
predefined task 67, 71, 164
prerequisite 50, 62, 120
presentation client 4
print 263
print server 241
printer 265
probe 28
problem determination 230, 240, 241
process count 53
process ID 76, 78
process status 80, 234
process type 76, 79
processor 110
production 51
profile 169
profile based methodology 36
profile manager 49, 56, 98, 108, 126, 130, 169,
178, 199, 277
profile manager hierarchy 97
Profile Managers
P
page area 164, 200
parameter 204
parameter file 148
password 36, 61, 129, 139, 146, 197, 260, 266,
285, 323, 324, 330
patch 108, 120
PC Managed Node 38, 97, 178
PC Server 232
PeopleSoft 21
performance 227, 240, 277
performance data 20
performance management 25
Q
queued request 82
403
R
R/3 application 6, 202, 217
R/3 buffer 217, 223
R/3 Collector 297
R/3 database 167
R/3 monitor 52
R/3 object 50, 57, 63, 66, 103, 128, 144, 203
R/3 process 76, 78
R/3 resource 297
R/3 server 58, 297
R/3 system 3, 16, 18, 52, 66, 72, 128, 129, 140,
141, 144, 145, 148, 155, 156, 163, 181, 184, 199,
202, 223, 287, 306, 309, 336, 343
R/3 system release 68
r3mibIID program 186
RACF 265
RDBMS 5, 31, 39, 207, 239, 260, 263
RDBMS home 286
reboot 92
redbook 51
reference installation 169, 178
release 108
Remote Function Call (RFC) 52, 61, 67, 85, 128,
145, 185, 189, 194
remote monitor 194
repeater 231
replica server 38
reporting capability 20
resource 99, 265
Resource Access Control Facility (RACF) 40
resource management 268
resource role 52, 55
resource type 99
response 52
response time 27, 200, 217, 232, 299
restructure 54
RFC function 61
RFC interface 61, 138, 186, 195, 221
RFC user 128, 145, 146
RIM 286
role 265
role-based security 40, 264
roll area 164, 200
root 133
root user 122, 124
router 231
routine task 18
routing rule 268
RS/6000 232, 234, 241
404
rule base 18, 37, 50, 84, 151, 186, 219, 221, 247,
260, 305, 321
rule-based foundation 45
rules engine 186
Rules Sets
sap_default.rls 222
sap_monitor.rls 222
sap_tecad.rls 222
running monitor 341
running process 79
S
SAP 3
SAP administrator 128, 135, 199
SAP instance 6
SAP R/3 1, 3, 35, 41, 43, 49, 107, 115, 119, 154,
163, 217, 234, 241, 263, 265, 271, 292, 297, 304,
314, 327
SAP R/3 application 21, 317
SAP R/3 environment 9, 21
SAP R/3 management 16, 344
SAP R/3 resource property 336
SAP R/3 user account 36
SAP user 128, 129
SAP Users
DDIC 129
SAP* 129
SAP utility 43
SAPGUI 5, 16, 18, 74, 77, 119, 129 , 138, 141,
168, 169, 173, 175, 178, 181, 197, 277, 287
SAPOSCOL 17
saprouter program 82
sapsetup program 181
scenario 227
schedule 145
schedule list 66
scheduling rule 280
script 104, 145, 150, 260, 287
Scripts
cr_tapm_rim.sh 287
ihsttec.sh 322
R3Mgr_mn_deinstall.2.0 85
R3Mgr_tmr_deinstall.2.0 85
sap_alert_control_cb.sh 188
sap_alert_reader.sh 186
sap_alert_reader_cb.sh 186
sap_config_adapter.sh 159
sap_config_rfc.sh 145
sap_control_reader.sh 188
sap_eventserver_config.sh 152
sap_start_db.exit.sh 150
sap_stop_db_exit.sh 150
sap_tec_config.sh 155
wmarreg.sh 278, 291
SCSI disk array 232
Seagate Crystal Reports 19
secure encryption method 38
security 60, 261, 268
security group 41
security policy 42
security profile 41, 265, 267
Sentry engine 78
Sentry monitor 49, 104
server ID 286
service delivery organization 241
service level 28, 292
Service Level Agreement (SLA) 29, 297, 299
severity attribute 339
severity level 52
shared drive 295
shared memory pool 139
shared memory segment 139, 185
SID 6, 58, 60, 68, 130, 141, 150, 167
SID-specific indication 55, 66, 199
Simple Network Management Protocol (SNMP) 46,
237
simulation 288
simulation interval 292
SMIT 310
SNMP event 46
SNMP manager 15
SNMP trap 46, 237
software 112, 115, 227, 261
Software Distribution 10, 16, 37, 62, 119, 130,
168, 171, 173, 176, 178
Software Installation Service (SIS) 274
solution 115, 227
source file 133
SP 115
SP2 241
specialized management 8
specific event 186
specification 109
SQL 167
T
table 287
tablespace 234, 248
task 15, 49, 52, 58, 61, 64, 75, 104, 126, 141, 145,
150, 163, 167, 169, 174, 340
Task Libraries
R3 App Server Tasks 73, 76, 126, 164
R3 Configuration Tasks 71 , 127, 144, 146,
152, 169, 174
R3 DB Server Tasks 126, 164, 167
R3 Internal Tasks 127
R3 List Maintenance Tasks 127
R3 System Tasks 126, 164, 168
405
406
wdepset 93
wgateway 92
wgetrim 286
wlookup 93, 99
wlsinst 108
wmarregapp 277
wpostemsg 83
wr3rfc 53, 70
wrcrtrim 286
Tivoli core application 50, 62, 120
Tivoli Data Protection for SAP R/3 10, 43
Tivoli database 61, 123, 125, 197, 296
Tivoli Database Manager Product 10, 31, 236, 241
Tivoli Databases
gwdb.bdb 92
imdb.bdb 92
Tivoli Decision Support (TDS) 19, 242, 292, 293
Tivoli Decision Support for SAP R/3 21, 294, 297
Tivoli Desktop 15, 35, 52, 55, 67, 89, 104, 122,
124, 125, 140, 150, 163, 167, 169, 205, 272, 312,
315, 319, 341, 343
Tivoli Enterprise 1, 7, 16, 21
Tivoli Enterprise Product 10, 19
Tivoli Global Sign-On 10, 37, 264
Tivoli Global Sign-On Plus Module 37
Tivoli Management Agent (TMA) 53, 62 , 83, 85,
90, 97, 103, 108, 122, 124, 128, 131, 142, 148,
150, 169, 178, 272, 306
Tivoli Management Application 15, 18, 90, 93, 99
Tivoli Management Environment (TME) 7
Tivoli Management Framework 10, 15, 31, 62, 99,
119, 274, 305
Tivoli Manager for DB2 31, 207
Tivoli Manager for Domino 62, 250
Tivoli Manager for MQSeries 10 , 33
Tivoli Manager for Oracle 31, 202, 207
Tivoli Manager for R/3 10, 16, 21, 49, 51, 54, 64,
90, 116, 119, 121, 128, 145, 149, 163, 217, 236,
241, 248, 308, 343
Tivoli Manager for Sybase 32
Tivoli Manager series product 49, 62, 64, 105
Tivoli Module Builder 331
Tivoli Module Designer 331
Tivoli Name Registry (TNR) 99
Tivoli object 140
Tivoli Objects
EventServer 84
139
184
137
288
74 , 288
77
288
st02 18
st06 18
su01 129, 138
transaction simulation 27
transformer model 296
transport 89, 128, 129, 134
transport buffer 134
tsadmn group 323
tsuser group 323
two-tier 25
U
UNIX 3, 71, 132 , 144, 167, 168, 174, 183, 188,
237, 250, 322
unknown status 329, 342
upcall 63, 93, 104
upgrade 97
URL 19
user 286, 298
user access 37
user created job 238
user group 323
user ID 37, 61, 133, 189, 197, 260, 266, 323, 330
user information 38
user interface 54
user-defined event class 84
V
vendor 286
verify mode 332
Virtual User Script (VUS) 291
W
Web interface 3
Web server 43
Web site 120
wide node 115
Windows 95 5, 168, 174, 295, 314
Windows 98 5, 314
Windows NT 3, 71, 111, 133, 149, 167, 168, 169,
174, 181, 183, 188, 241, 255, 265, 295, 297, 310,
315, 322, 323
Windows NT service 324
Winrunner 288 , 291
Winrunner-Quicktest for R/3 287
work process 52, 76, 79, 164
work process table 71
407
workstation 168
wr3mib program 185, 196, 208, 220, 221
wr3rfc function 61
wr3rfc program 148, 187, 196, 197, 201, 203 , 221
X
xterm 167
408
_ IBM employee
Please rate your overall satisfaction with this book using the scale:
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction
__________
Yes___ No___
Comments/Suggestions:
409
SG24-5500-00
Printed in the U.S.A.
SG24-5500-00