Using Tivoli To Manage A Large-Scale SAP R 3 Environment

Using Tivoli to Manage a Large-Scale SAP R/3
Environment
Yoichiro Ishii, Jamie Cooper, Yasuko Takada, Andre Wahjudi
International Technical Support Organization

www.redbooks.ibm.com
SG24-5500-00
SG24-5500-00
International Technical Support Organization

Using Tivoli to Manage a Large-Scale SAP R/3
Environment
December 1999
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.
First Edition (December 1999)

This edition applies to Version 2.0 of Tivoli Manager for R/3 for use with the IBM AIX Operating Systems.
Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. JN9B Building 003 Internal Zip 2834
11400 Burnet Road
Austin, Texas 78758-3493
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
Copyright International Business Machines Corporation 1999. All rights reserved.
Note to U.S Government Users Documentation related to restricted rights Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
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
Chapter 2. What is new: Tivoli Manager for R/3 Version 2.0 . . . . . . . . 49

2.1 Tivoli Manager for R/3 packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2 Overview of the Tivoli Manager for R/3 . . . . . . . . . . . . . . . . . . . . . . . . 51
Copyright IBM Corp. 1999
iii
2.2.1 Brief overview of new features and improvements . . . . .

2.3 New functions in Version 2.0 of Tivoli Manager for R/3 . . . . . .
2.3.1 Restructure of Tivoli Manager for R/3 . . . . . . . . . . . . . . .
2.3.2 Tivoli Management Agent (TMA) support . . . . . . . . . . . .
2.3.3 The Tivoli Global Enterprise Manager support . . . . . . . .
2.3.4 Automatic Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.5 Improvement of status report . . . . . . . . . . . . . . . . . . . . .
2.3.6 Extensive Improvement in RFC API Tool . . . . . . . . . . . .
2.3.7 New tasks of Version 2.0 of Tivoli Manager for R/3. . . . .
2.3.8 New monitors of Version 2.0 of Tivoli Manager for R/3 . .
2.3.9 Improvement of interconnected TMR support . . . . . . . . .
2.3.10 User-Configurable Syslog Event Adapter . . . . . . . . . . .
2.3.11 Filtering events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.12 Migration tool for Version 2.0 of Tivoli Manager for R/3
2.3.13 De-install tool for Version 2.0 of Tivoli Manager for R/3
2.3.14 Delivery of ABAP program using J class . . . . . . . . . . . .
2.3.15 New R/3 specific event sources . . . . . . . . . . . . . . . . . .
2.4 Advanced knowledge of Tivoli Manager for R/3 . . . . . . . . . . .
2.4.1 R/3 Manager Endpoint methods . . . . . . . . . . . . . . . . . . .
2.4.2 R/3 Manager object . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3 Tivoli Application Proxy internals . . . . . . . . . . . . . . . . . .
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . 52
. . 54
. . 54
. . 62
. . 64
. . 66
. . 69
. . 70
. . 71
. . 78
. . 83
. . 84
. . 84
. . 85
. . 85
. . 88
. . 89
. . 90
. . 90
. . 99
. 103
Chapter 3. Our SAP R/3 System environment. . . . . . . . . . . . . . . . . . . 107

3.1 Overview of our environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.2 Overview of our SAP R/3 environment . . . . . . . . . . . . . . . . . . . . . . . 115
iv
Chapter 4. Planning and implementation . . . . . . . . . . . . . . . . . . .

4.1 Overview and objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Installation planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Installation Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Installing and configuring Tivoli Manager for R/3 . . . . . . . . . . . .
4.3.1 Installing Tivoli Manager for R/3 . . . . . . . . . . . . . . . . . . . . .
4.3.2 Configuring Tivoli Manager for R/3 . . . . . . . . . . . . . . . . . . .
4.3.3 Configuring each SAP R/3 System . . . . . . . . . . . . . . . . . . .
4.3.4 Configuring the Tivoli Manager for R/3 to the R/3 System. .
4.3.5 Configuring event handling . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 119
. 119
. 120
. 120
. 121
. 122
. 128
. 128
. 140
. 151
Chapter 5. Managing SAP R/3 environment . . .

5.1 Version 2.0 of Tivoli Manager for R/3 . . . . . . .
5.1.1 SAP R/3 System Management tasks and
5.1.2 SAPGUI distribution . . . . . . . . . . . . . . . .
5.2 Log files for troubleshooting . . . . . . . . . . . . . .
5.3 Monitoring functions of Tivoli Manager for R/3
5.3.1 Alert Event Adapter . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 163
. 163
. 163
. 168
. 183
. 184
. 186
Using Tivoli to Manage a Large-Scale SAP R/3 Environment
....
....
jobs
....
....
....
....
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
Alert Control Process . . . . . . .

Syslog Adapter . . . . . . . . . . . .
Tivoli Distributed Monitoring . .
Default monitoring . . . . . . . . .
TEC event classes and rules .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
. 188
. 189
. 194
. 199
. 219
Chapter 6. SAP R/3 Management scenarios . . . . . . . . . . . . . .

6.1 Tivoli SAP R/3 Management solutions . . . . . . . . . . . . . . . . .
6.2 SAP R/3 Management scenarios . . . . . . . . . . . . . . . . . . . . .
6.3 Operations scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 What are operations? . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2 Detailed scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.3 Operations software solution . . . . . . . . . . . . . . . . . . . .
6.3.4 Solution implementation . . . . . . . . . . . . . . . . . . . . . . . .
6.3.5 Scenario summary . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Availability and performance scenario . . . . . . . . . . . . . . . . .
6.4.1 What is meant by availability and performance? . . . . . .
6.4.3 Availability and performance software solution . . . . . . .
6.5 Security and resource management scenario . . . . . . . . . . . .
6.5.1 What is meant by security and resources? . . . . . . . . . .
6.5.3 Security and Resource Management Software solution
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 227
. 227
. 230
. 230
. 230
. 231
. 236
. 237
. 240
. 240
. 240
. 241
. 241
. 242
. 259
. 260
. 260
. 261
. 264
. 264
. 268
Chapter 7. Examples of new features in SAP R/3 Management . .

7.1 Tivoli Application Performance Manager . . . . . . . . . . . . . . . . . .
7.2 Installation and configuration of TAPM components . . . . . . . . . .
7.2.1 Installation and configuration of TAPM . . . . . . . . . . . . . . . .
7.3 Tivoli Decision Support for SAP R/3 . . . . . . . . . . . . . . . . . . . . . .
7.3.1 Tivoli Decision Support components . . . . . . . . . . . . . . . . . .
7.3.2 Supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.3 Tivoli Decision Support architecture . . . . . . . . . . . . . . . . . .
7.3.4 Tivoli Decision Support work flow . . . . . . . . . . . . . . . . . . . .
7.3.5 Tivoli Decision Support for SAP R/3 . . . . . . . . . . . . . . . . . .
7.3.6 TDS for SAP R/3 Cubes and Related Reports . . . . . . . . . .
7.3.7 Examples of using TDS for SAP R/3 Analysis. . . . . . . . . . .
7.4 Tivoli Global Enterprise Manager . . . . . . . . . . . . . . . . . . . . . . . .
7.4.1 Overview of Tivoli GEM . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.2 Installing Tivoli GEM for SAP R/3 management . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 271
. 271
. 273
. 274
. 293
. 293
. 294
. 295
. 296
. 297
. 298
. 299
. 304
. 305
. 306
7.4.3 Configuring Tivoli GEM for SAP R/3 management . . . . . . . . . . 320

7.4.4 Using Tivoli GEM for SAP R/3 management . . . . . . . . . . . . . . . 329
7.4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Appendix A. Winrunner-Quicktest for R/3 test case. . . . . . . . . . . . . . . 345
Appendix B. Event classes for Tivoli Manager for R/3 . . . . . .
B.1 R3 alert event classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 R/3 operational event classes. . . . . . . . . . . . . . . . . . . . . . . . . .
B.3 R/3 Syslog event classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.4 Distributed monitoring event classes . . . . . . . . . . . . . . . . . . . .
B.5 Special event classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.6 Tivoli GEM event classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
......
......
......
......
......
......
......
.
.
.
.
.
.
.
347
347
349
353
357
358
358
Appendix C. Monitor sources and their attributes . . . . . . . . . . . . . . . . 361

C.1 OS collect source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
C.2 Roll area source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
C.3 Page area source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
C.4 Work process source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
C.5 Work process dispatch queue source. . . . . . . . . . . . . . . . . . . . . . . . . . . 366
C.6 Long running work process source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
C.7 Buffer source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
C.8 Performance source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
C.9 OS/390 DB2 source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
C.10 OS/390 source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Appendix D. TEC Rules and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
D.1 Event Classes: Distributed Monitoring based . . . . . . . . . . . . . . . . . . . . . 373
D.2 Event Classes: Alert adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
D.3 Event Classes: Syslog adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
D.4 Event Classes: GEM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
D.5 Correlating events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
D.6 Rules: Handling duplicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
D.7 Rules: Handling harmless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
D.8 Rules: Handling start up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
D.9 Rules: Handling mode switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
D.10 Rules: Handling shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
D.11 Rules: Handling application server down . . . . . . . . . . . . . . . . . . . . . . . 380
D.12 Rules: Forwarding events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
D.13 Rules: Synchronizing R/3 with TEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
D.14 Rules: Synchronizing TEC with R/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
D.15 Rules: Handling Syslog alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
D.16 Rules: Drill down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
D.17 Rules: Handling jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
vi
D.18 Rules: Handling GEM events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

D.19 Rules: Handling daemons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
D.20 Rules: Handling hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Appendix E. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Appendix F. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
F.1 IBM Redbooks publications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
F.2 IBM Redbooks collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
F.3 Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
F.4 Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
IBM Redbooks fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
List of abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
IBM Redbooks evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
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.
SAP R/3 three tier architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Initial SAPGUI login screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Complex ERP management environment . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Tivolis integrated solution - SAP R/3 management. . . . . . . . . . . . . . . . . . 10
Tivoli product architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Example: Business systems management scenario . . . . . . . . . . . . . . . . . 23
Tivolis action for business systems management. . . . . . . . . . . . . . . . . . . 24
Tivoli Global Enterprise Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
The Tivoli approach to managing application performance . . . . . . . . . . . . 28
Example: Database management scenario . . . . . . . . . . . . . . . . . . . . . . . . 32
Tivolis action for database management . . . . . . . . . . . . . . . . . . . . . . . . . 33
Example of security groups and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Typical output environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Example of a NetView display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Tivoli Manager for R/3 components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
The relationship between Tivoli Core Applications and R/3 Manager . . . . 51
Tivoli Manager for R3 icon on Tivoli Desktop . . . . . . . . . . . . . . . . . . . . . . 55
Contents of manager for R/3 Policy Region. . . . . . . . . . . . . . . . . . . . . . . . 56
R/3 System on policy region: Manager for R3 . . . . . . . . . . . . . . . . . . . . . . 57
Application server and database server in R/3 System . . . . . . . . . . . . . . . 58
Distributing monitors and tasks in prior Version of R/3 Manager . . . . . . . . 59
New format of distributing monitor and tasks. . . . . . . . . . . . . . . . . . . . . . . 60
New TMR roles of manager for R/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
The example of application proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 64
Tivoli Global Enterprise Manager Console . . . . . . . . . . . . . . . . . . . . . . . . 65
Schedule setting for automatic discovery . . . . . . . . . . . . . . . . . . . . . . . . . 67
R/3 System on policy region:Manager for R3 . . . . . . . . . . . . . . . . . . . . . . 68
R/3 System properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
The status icons of application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Task library: R3 configuration tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Task library: R3 App Server tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Display batch jobs output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Job overview alphabetic on SAPGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Cancel batch job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Release batch job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Display work process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Work processes output after running the task . . . . . . . . . . . . . . . . . . . . . . 77
Process overview on SAPGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Cancel work process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Add monitor to Sentry profile (long running work process) . . . . . . . . . . . . 80
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.
Add monitor to Sentry profile (work process). . . . . . . . . . . . . . . . . . . . . . . 81

Add monitor to Sentry profile (work process dispatch queue) . . . . . . . . . . 82
New TEC event source icons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Endpoint method cache management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
R/3 Manager Endpoint methods handling . . . . . . . . . . . . . . . . . . . . . . . . . 96
The Difference between dataless and classic profile manager . . . . . . . . . 98
Application Proxy and Tivoli Object Database . . . . . . . . . . . . . . . . . . . . . 103
Overview of our environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Installing Application Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Installing Tivoli Manager for R/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
New Manager for R3 icon on the desktop . . . . . . . . . . . . . . . . . . . . . . . . 126
Policy region: Manager for R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
R/3 Configuration task libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
R3 Profile Manager: R3 Transports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Change to the dataless profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Edit File Package properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Unix Package Unix options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Checking the development class J8C1 . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Checking active table structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
User list at SAPGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Display R/3 instance profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Assigning the new TMR roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Create R/3 system from desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Create R/3 application server from desktop. . . . . . . . . . . . . . . . . . . . . . . 143
Create R/3 database server from desktop . . . . . . . . . . . . . . . . . . . . . . . . 144
Configure Autodiscovery for UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Task Library: R3 Configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Configure remote function call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Configure remote function call output . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Tivoli Manager for R3 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Task Library: R3 configuration tasks (for Event Server) . . . . . . . . . . . . . 153
Configure Event server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Task Library: R3 Configuration tasks (for Event Console). . . . . . . . . . . . 155
Configure event console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Configure Event console output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
TME 10 Event server configuration (Event Group) . . . . . . . . . . . . . . . . . 158
Tivoli Enterprise Console (for Event Source). . . . . . . . . . . . . . . . . . . . . . 159
Task Library: R3 Configuration Tasks (for Event Adapter) . . . . . . . . . . . 160
Configure Event Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
WR3MIB and WR3SLOG Event on TEC console . . . . . . . . . . . . . . . . . . 162
Task Library: R3 App Server Tasks Collection . . . . . . . . . . . . . . . . . . . . 164
Display Batch Jobs Execute Task Window . . . . . . . . . . . . . . . . . . . . . . . 165
Display Batch Jobs Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
84. Display Batch Jobs Output Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

85. Task Library: R3 DB Server Tasks Collection . . . . . . . . . . . . . . . . . . . . . 168
86. Edit Job for a Reference Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
87. Settings for the Jobs execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
88. Result of the Job Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
89. Edit the Profile: Configuring the R/3 SAPGUI Client File Package . . . . . 173
90. Edit Job for a Native Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
91. Native Installation Job Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
92. Result of the Job Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
93. Edit the Profile: Configuring the R/3 SAPGUI Client Native Installation . 178
94. Change to Dataless Profile Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
95. Cloning Profile into Dataless Profile Manager . . . . . . . . . . . . . . . . . . . . . 180
96. Distributing the SAPGUI Client File Package . . . . . . . . . . . . . . . . . . . . . 181
97. Example of SAPGUI Access on a Windows NT Client . . . . . . . . . . . . . . 182
98. CCMS Alert Overview (Customized) - Transaction RZ20 . . . . . . . . . . . . 184
99. Explanation for the Alerts and Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
100.Event Adapters and the Drill-Down Mechanism . . . . . . . . . . . . . . . . . . . 187
101.Tivoli Distributed Monitoring in an SAP R/3 System . . . . . . . . . . . . . . . . 196
102.Default Profile Managers, Subscription Lists and Profiles. . . . . . . . . . . . 200
103.Monitoring Collections Provided by the Tivoli Manager for R/3. . . . . . . . 203
104.The Default R3 App Server Profile Manager . . . . . . . . . . . . . . . . . . . . . . 205
105.Predefined R3 Server Autodiscovery Monitors . . . . . . . . . . . . . . . . . . . . 206
106.Predefined R3 Server Remote Monitors . . . . . . . . . . . . . . . . . . . . . . . . . 207
107.Distributing Monitoring Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
108.Starting Alert Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
109.TEC Event Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
110.Modifying a Default Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
111.Profile Properties to Add a New Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 212
112.Creating New Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
113.Creating New Monitor: Edit Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
114.Select Indicator Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
115.Indicator Collection List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
116.Work Process Monitor Event on TEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
117.Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
118.An example of the enterprise stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
119.Tivoli Enterprise Management Approach . . . . . . . . . . . . . . . . . . . . . . . . 229
120.Typical SAP R/3 Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
121.Illustration of Event Management Design and Monitoring Design. . . . . . 247
122.Example of a Worksheet for Event Source: AIX errlog . . . . . . . . . . . . . . 259
123.Tivoli Application Performance Manager Components . . . . . . . . . . . . . . 273
124.Adding the TAPM Notice Group to the Administrator . . . . . . . . . . . . . . . 275
125.Adding Marprofile to the pokibmtapm Policy Region. . . . . . . . . . . . . . . . 276
126.Creating a TAPM Profile Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
xi
127.Creating a Blank Monitoring Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

128.Adding Applications to a Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
129.The Schedule Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
130.Adding a Monitoring Rule to a Schedule . . . . . . . . . . . . . . . . . . . . . . . . . 281
131.Database Settings Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
132.Application Added to Application Availability Profile . . . . . . . . . . . . . . . . 283
133.Adding Subscribers to the Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
134.Distributing the Monitoring Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
135.Tables Created by Create Database Script. . . . . . . . . . . . . . . . . . . . . . . 287
136.Initial Screen of Winrunner-Quicktest for R/3 . . . . . . . . . . . . . . . . . . . . . 288
137.Adding an SAP Connect Step to a Business Process. . . . . . . . . . . . . . . 289
138.sm37 Step From Winrunner Testcase. . . . . . . . . . . . . . . . . . . . . . . . . . . 291
139.Simulation Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
140.Tivoli Decision Support Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
141.TDS Architecture Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
142.Cubes and related reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
143.Example 1: R/3 load balance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 300
144.Example 2: R/3 Service Level Agreement. . . . . . . . . . . . . . . . . . . . . . . . 301
145.Example 3: R/3 response time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
148.The Interactions between Tivoli GEM Components . . . . . . . . . . . . . . . . 306
149.Software Configurations on Each Tivoli GEM Component . . . . . . . . . . . 307
150.Downloading Java Development Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
151.Tivoli GEM Topology Server Installation . . . . . . . . . . . . . . . . . . . . . . . . . 311
152.Tivoli GEM Topology Server Installation Completion . . . . . . . . . . . . . . . 312
153.Tivoli GEM Event Enablement Installation . . . . . . . . . . . . . . . . . . . . . . . 313
154.Tivoli GEM Event Enablement Installation Completion . . . . . . . . . . . . . . 314
155.Tivoli GEM Topology Console Installation. . . . . . . . . . . . . . . . . . . . . . . . 315
156.Tivoli GEM Topology Console Installation Completion . . . . . . . . . . . . . . 316
157.Tivoli GEM Topology Console Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
158.Tivoli GEM Instrumentation for R/3 Manager Installation . . . . . . . . . . . . 318
159.Tivoli GEM Instrumentation for R/3 Manager Installation Completion. . . 319
160.Instrumentation Task Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
161.Configuring TEC Event Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
162.Creating Tivoli GEM Console User Group . . . . . . . . . . . . . . . . . . . . . . . 323
163.Importing Application Management Package File . . . . . . . . . . . . . . . . . . 325
164.Send GEM Heartbeat Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
165.Executing the Send GEM Heartbeat Task . . . . . . . . . . . . . . . . . . . . . . . 327
166.The Send GEM Heartbeat Task Completion . . . . . . . . . . . . . . . . . . . . . . 328
167.TEC Events of the Send GEM Heartbeat Tasks . . . . . . . . . . . . . . . . . . . 329
168.Tivoli GEM Console Sign On Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
169.Tivoli GEM Console Initial Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
xii
170.The Plan Mode Screen of Tivoli GEM Console . . . . . . . . . . . . . . . . . . . . 332

171.The Verify Mode Screen of Tivoli GEM Console . . . . . . . . . . . . . . . . . . . 333
172.The Control Mode Screen of Tivoli GEM Console . . . . . . . . . . . . . . . . . 334
173.SAP R/3 Managed Resources Topology Information . . . . . . . . . . . . . . . 335
174.Displaying SAP R/3 Resource Properties . . . . . . . . . . . . . . . . . . . . . . . . 337
175.The Pull-Down Menu Bar of SAP R/3 Application Server . . . . . . . . . . . . 338
176.Tivoli GEM Console Event Viewer Screen . . . . . . . . . . . . . . . . . . . . . . . 339
177.The Tivoli GEM Event Viewer Properties . . . . . . . . . . . . . . . . . . . . . . . . 340
178.The Result of the Display_Buffer_Info Task Execution . . . . . . . . . . . . . . 341
179.The Running Monitors Status of SAP R/3 Application Server . . . . . . . . . 342
180.The Unknown Status SAP R/3 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . 343
181.Winrunner-Quicktest for R/3 test case (1/2) . . . . . . . . . . . . . . . . . . . . . . 345
182.Winrunner-Quicktest for R/3 test case (2/2) . . . . . . . . . . . . . . . . . . . . . . 346
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.
List of Operating and Database Systems that SAP R/3 Supports. . . . . . . . 5

Summary of Tivolis Management Solutions . . . . . . . . . . . . . . . . . . . . . . . 11
Functions and benefits of Tivoli Manager for MQSeries . . . . . . . . . . . . . . 34
Some advantages of Tivoli Workload Scheduler for R/3 . . . . . . . . . . . . . . 36
The Relationship between R/3 Roles and Tivoli Basic Roles . . . . . . . . . . 61
Description and Location of two De-install Scripts. . . . . . . . . . . . . . . . . . . 86
Installation Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Log Files for Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Monitoring Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Element List: Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Element List: Network Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Element List: All Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Tivoli Manager for R/3 Monitors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Tivoli Manager for Domino/Notes Monitors . . . . . . . . . . . . . . . . . . . . . . . 250
UNIX Monitoring Collection: Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
UNIX Monitoring Collection: Specific . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Universal Monitoring Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
TME Monitors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Oracle Monitoring Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Windows NT Monitoring Collection: Default. . . . . . . . . . . . . . . . . . . . . . . 255
Windows NT Monitoring Collection: Specific . . . . . . . . . . . . . . . . . . . . . . 257
Configuration Details for out TAPM Database . . . . . . . . . . . . . . . . . . . . . 286
Tivoli GEM Software Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
R/3 Alert Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
R/3 Operational Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
R/3 Syslog Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Distributed Monitoring Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Special Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Tivoli GEM Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
OS Collect Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Roll Area Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Page Area Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Work Process Source (Attribute 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Work Process Source (Attribute 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Work Process Dispatch Queue Source . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Long Running Work Process Source (Attribute 1) . . . . . . . . . . . . . . . . . . 367
Long Running Work Process Source (Attribute 2) . . . . . . . . . . . . . . . . . . 367
Buffer Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Performance Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
OS/390 DB2 Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
xv
41. OS/390 Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
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.
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization, Austin Center.
Yoichiro Ishii is an Advisory I/T Specialist working as a project leader at the
International Technical Support Organization Tivoli Group, Austin Center. He
manages Tivoli projects and develops technical documents including
xvii
redbooks on Tivoli Enterprise topics. He also teaches IBM classes worldwide

on all areas of systems management, application management, and network
management. Before joining the ITSO in mid-1998, Yoichiro worked at IBM
Japan as an I/T Specialist for systems and network management, consulting
major IBM customers. In this role, he architected systems management
design and solution for large government projects. He can be reached at
ishii@us.ibm.com.
Jamie Cooper is the Managed SAP Operations Team Leader at North
Harbour, IBM United Kingdom. He has worked on SAP R/3 related projects
since he joined IBM in May, 1997. He has specialised in AIX, SAP R/3, and
Lotus Notes. He helped to build the Managed SAP Operations team, which he
finds himself the team leader of at this time. He is also a Lotus Notes
developer, when time permits, and has written several Notes applications
tailored towards operations use. He is also responsible for writing a large
amount of educational and technical documents for his, and other operations,
departments.
Yasuko Takada is an IT Engineer in Japan. She has several years of
experience in the Tivoli Systems Management field. She has worked at the
IBM Systems Engineering field support department for three years. She has
joined a customer project deploying workstations with Tivoli system
management products on large environment.
Andre Wahjudi is an advisory I/T Specialist with IBM Netherlands. He joined
CIMAD Consultants BV in January of this year as a SAP IT Consultant (which
recently became IGS BMS/ERP Services). Since he joined IBM in August
1996, Andre has worked on the Tivoli Systems Management area for several
multinational clients with the focus on SAP Management. In these Tivoli
projects, he has also been involved in the design, implementing, and support
of the solution. Andre is a certified SAP Consultant and holds an Electrical
Engineering degree from Delft University of Technology.
Edson Manoel is an Advisory ITSO representative working as a project
leader at the International Technical Support Organization, Tivoli Group,
Austin Center. He applies his extensive field experience as an I/T Tivoli
Specialist to his work at the ITSO where he writes extensively on all areas of
systems management. Prior joining the ITSO, Edson worked at IBM Brazil
Professional Services Organization as an I/T Architect where he was involved
in numerous projects, designing and implementing systems and network
management solutions for major IBM Brazil customers.
Thanks to the following people for their invaluable contributions to this project:
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.
1.1 Information Technology environment

Up until a few years ago, the personal computer (PC) was considered an
unsuitable resource for serious business data processing. However, the tight
integration of single and multi-user systems in todays world is a standard
feature of modern business applications.
Not until the wide dissemination of PCs during the early to mid 1980s were
the conditions set for an entirely new way of thinking. At first, the PC was
largely ignored as a platform for business data processing. Then, for several
years it was thought that the PC could act as a graphical front end for a
business application; however, the business application would still have to run
on a central machine. Unfortunately, this approach was not revolutionary
enough to achieve real progress in the design of commercial applications. Not
until the second half of the 1980s, with the market success of linked PC
solutions, which were based on Local Area Networks (LANs), did a new
approach win out. That approach was the client/server principle.
However, there is a drawback to the seemingly wonderful world of the
client/server: Not every client/server architecture is suited for implementing
company-wide applications. This is especially true of applications that can
only separate the graphical user interface (GUI) from the closely tied
application and database functions. In this case, the scalability of the system
is extremely limited since the monolithic system of application and database
functions remain intact.
This is just one of the reasons that the three-tier client/server architecture,
with its distribution of presentation, application, and database functions on
separate computers, has prevailed as a viable foundation for company-wide
client/server solutions. This architecture provides the foundation for a
completely new generation of business applications; a generation which is
distinguished by sophisticated GUIs, interfaces to external applications, use
of multimedia technology, functionality that is unimpaired by scarce
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.
1.2 Evolution of ERP

How did information technology develop from mere record keeping to a
proactive business tool? Competitive market pressures, such as continual
price erosion and short product life cycles, have prompted many companies
during the last decade to turn to technology to meet these challenges.
As the 1990s unfolded, software vendors began to connect a wide range of
business functions and enterprise wide solutions began to emerge as finance
and accounting, sales-order administration, procurement, logistics, and a
variety of other business functions were interconnected with manufacturing
and material planning software applications. The early 1990s gave birth to
full-function ERP (Enterprise Resource Planning) systems that integrated
business functions, shared common data, and provided connectivity with a
single interface. Soon after, the ERP marketplace exploded. Single-source
transaction processing engines linked internal operating segments, including
finance, manufacturing, purchasing, order administration, and logistics.
Packaged software, fueled by reliable hardware, modern databases, and
huge information technology advances, offer tremendous business
functionality to even the largest enterprises. Continued advancements in
hardware and middleware technologies have enabled worldwide connectivity
of ERP systems throughout an enterprise.
Offering integrated common processes, globally shared data, and shortened
transaction cycle times resulting in reduced administrative costs, ERP
software products represent some of todays ground-breaking technology.
1.3 ERP - The backbone of e-business

The rise of e-business technologies has caused a fundamental change in the
way companies interact, both with their customers and their trading partners.
Today, companies realize that it is critical to establish their e-business
strategy in relation to ERP. ERP contains a tremendous degree of access to
and control over critical business information. ERP brings all of a companys
data together in real time, making it possible to gain unprecedented insight
into how the business is performing and where it is headed.
With "enterprise" now being extended beyond the traditional boundaries of
the organization to include customers and suppliers, the importance of
well-managed, supply-chain-enhancing processes is heightened. As the

organizations mission critical transaction system, ERP has evolved to
become the "Enterprise application backbone" supporting the extended value
chain to create new business processes. ERP vendors have responded to
this dramatic shift in the way business is being conducted by evolving to xRP
- extended ERP. xRP involves extending ERP applications to integrate the
value chains of customers and partners into the organization.
1.4 SAP - The leading ERP vendor

As the market leader of Enterprise Resource Planning (ERP) Solutions, SAP
(Systems, Applications, and Products in Data Processing) has grown to
become the worlds fourth largest independent software supplier.
With headquarters in Walldorf, Germany, five former IBM employees started
SAP in 1972. From its inception, SAP approached application software from a
business perspective. The original idea of SAP was to provide customers the
ability to interact with a common corporate database for a comprehensive
range of applications. By collaborating with business and IT executives, and
partners worldwide, SAP developed a unique understanding of the
challenges faced in implementing technology solutions for business users.
Gradually, the applications have been assembled, and today many
corporations including IBM and Microsoft, are using SAP products to run their
business.
SAP applications built around the latest R/3 (release 3) system provide the
capability to manage financial, asset, cost accounting, production operations
and materials, personnel, plants, and archived documents. The system uses
the client server model and runs on multiple platforms, including Windows NT
and UNIX.
Since the introduction of Web interfaces and a scalable, Internet-ready
architecture in 1996, SAP has been working with companies making the
transition to the Internet business model. It is now focused on inter-enterprise
software solutions that integrate the processes within and among enterprises
and business communities.
1.5 What is SAP R/3?

This section only provides a brief overview of SAP R/3. For more in depth
information on SAP R/3, refer to the appropriate R/3 materials.
Introduction
SAP R/3 is a client/server application system used for Enterprise Resource

Management (ERP). R/3 has many modules that allow the modelling of all
parts of the enterprise business and can manage data from finance, sales,
accounting, manufacturing, human resources, and other business
departments.
R/3 allows the customer to integrate business data and processes. R/3 can
act as a catalyst for change, as it not only allows the customer to automate
business processes using information technology but also can be used to
drive changes to the business processes themselves.
R/3 has a multi-tier architecture with the following components:
Database server
Application servers
Presentation clients
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.
Traditionally, there is one database server in an R/3 system. This can be a

stand-alone or run in parallel with an R/3 application on the same server. The
database server stores data in a Relational Database Management System
(RDBMS). These database servers can run on a number of platforms;
however, the standard implementation of R/3 inside IBM uses DB2 for
RS/6000 or OS/390. The protocol used for communication between the three
main components of the R/3 system is TCP/IP unless DB2 for OS/390 has
been used for the R/3 database, in which case, UDP is also used. The
following table gives a quick reference of which operating systems support
which database systems. Only the most widely used databases and operating
systems supported by SAP R/3 are listed:
Table 1. List of Operating and Database Systems that SAP R/3 Supports.
Database System
Operating System
DB2
All Major UNIX Platforms

IBM OS/400
IBM OS/390
Oracle
Windows NT
Informix
Windows NT
Microsoft SQL Server
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
Figure 2. Initial SAPGUI login screen
An R/3 system is comprised of one database server and one or more

application servers as well as the presentation clients. The R/3 system is
identified by a three-character system identifier (SID), such as DEV, TST,
FP7, and so forth. The SID allows the grouping of the database server and
the application servers, and it identifies the R/3 system as a whole.
Instances are assigned to the application servers in the R/3 system. An
instance is a single R/3 application running on any application server. It is
possible to run multiple instances on a single application server; however, this is
not common and is rarely seen in IBM internal implementations of R/3. Of the
instances in an R/3 system, one is deemed the Central instance. Usually, in
IBM internal implementations of R/3, this is the machine that either holds the
DB2 for RS/6000 database server, as well as an SAP instance, or it has the
connection to the OS/390 LPAR that holds the DB2 for OS/390 database.
R/3 has many additional components that have not even been mentioned
here, such as SAPGUI servers and ITS.
1.6 A brief history of Tivoli

Tivoli was founded in Austin, Texas in 1989. At the time, client/server was still
a new buzzword. The company correctly foresaw that the typical large
organization would want to combine all its computers, databases, and
business applications into a single integrated network computing
environment.
Tivoli also foresaw that the cost and complexity of systems and network
management would be a major barrier to network computing. Existing
management solutions could not be integrated to support network computing
because each of these solutions has been developed to solve one particular
problem on one computing platform. This meant that customers would have to
use multiple management solutions and employ multiple teams with multiple
skills.
To overcome the cost and complexity, customers would require a single
network computing management solution. This would have to be an
integrated solution that could manage all the systems, databases, and
applications in a network as well as the network itself. However, it was
unlikely that any single vendor could provide such a comprehensive solution.
Tivoli saw a tremendous opportunity to create an open, object-oriented,
flexible, scalable management framework and build an entirely new industry
around it, an industry that would be based on standards and cooperation.
During the next eight years, Tivoli pursued this opportunity. Working closely
with partners, they developed and refined the Tivoli Management
Environment (TME). This was the first and only software specifically designed
for the seamless management of an entire enterprise from desktop to data
center.
Tivoli merged with IBM in March, 1996. The Tivoli Systems name has
remained, and it has become an independent business unit of IBM. Before
the merger, IBM had its own systems management product line known as
SystemView. Tivolis products were known collectively as TME 3.0. The
merger allowed the best of both product lines to be combined into one
offering called TME 10. In current versions of Tivoli, the TME 10 brand name
has been phased out, and all applications are known collectively as the Tivoli
Enterprise Software.
Introduction
1.7 SAP management challenges

Since SAP applications depend on information from numerous corporate
systems, it is not enough to simply monitor the applications alone for "red
alerts". What if a problem occurs in the middleware as data is translated from
the mainframe to another server for use in a SAP solution? Where does IT
look when the sales force cannot access product delivery information? Is it a
problem with the SAP solution? The integrated sales automation package? Or
perhaps, the problem is in the database feeding the SAP application.
In the past, companies developed islands of management - separate
organizations and tools that addressed once seemingly separate issues;
network management, mainframe management, database management, LAN
management, and desktop management. Yet with the increasing complexity
of todays environments, transforming systems management to a centralized,
integrated approach has become a necessity to optimize the use of
information across an organization.
Managing the complete SAP R/3 environment means extending management
beyond the monitoring and control of network devices, system platforms, and
middleware such as MQSeries, and production services. It adds specialized
management for application events, application jobs and output, application
software distribution, and application service levels. This specialized
management enables R/3s IT and business owners and users to understand,
control, and improve business systems that use or interact with R/3. The
range of management disciplines spans security, problem and change
management, job scheduling, output management, event monitoring and
correlation, help desk, software distribution and configuration, and IT asset
inventory management.
1.8 The Tivoli Management Environment

Consistent and centralized management of distributed systems of different
brands and architectures is crucial to large customer environments. Tivolis
applications are a suite of distributed systems management products that
have been gaining a lot of attention within IBM and among customers since
the merger between IBM and Tivoli.
The current computing environment relies more and more on distributed
client/server setups for information system needs where users at the client
workstations perceive the network as one big server or service provider.
Distributed computing or network computing ties people, information, and
resources more closely together. However, this brings a challenge when
considering the management of these systems. Managers face the complex

problem of maintaining many different types of hardware and operating
systems.
Tivoli provides a way to manage network computing resources of many
different types from a single point. Tivoli products provide a consistent
interface to different operating systems and services. Tivoli allows
administrators to control users, systems, and applications from one desktop.
It also provides a streamlined way to automate and delegate routine, time
consuming tasks.
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
Figure 3. Complex ERP management environment
1.9 Tivolis management solution for SAP R/3

Tivolis solution for managing the SAP R/3 environment is one of the most
comprehensive solution available in the market today. Tivoli offers a complete
set of management tools that address each layer of IT infrastructures networks, systems, databases, middleware, and applications - under a single,
integrated, and centralized monitoring and reporting environment. Using this
multi-disciplinary, "big picture" approach, companies can remain proactive in
deploying and monitoring ERP applications and the associated infrastructure
components that may impact access to business critical data.
Tivolis R/3 management solution covers the full cycle and range of
management requirements for the SAP R/3 environment. Tivolis SAP R/3
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
1.10 Tivoli Product Architecture

The Tivoli applications all share a common framework called the Tivoli
Management Framework. The Tivoli Framework is open and object-oriented
and includes a set of managers, brokers, and agents that conform with the
Common Object Request Broker Architecture (CORBA) specifications
produced by the Object Management Group (OMG). This technology allows
major differences between computer operating systems to be hidden from the
Tivoli users and allows the encapsulation of key services in objects that can
be used by multiple management applications. To put this in more simple
10
terms, it allows for platform-independence, a unifying architecture, and the

ability of third-party vendors to easily adapt to the Tivoli Framework.
The following figure shows the relationship between the Tivoli Framework and
some of the additional modules in the Tivoli Architecture.
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
Figure 5. Tivoli product architecture
1.11 Summary of Tivolis management solutions

The following table (Table 2) gives a brief description and indication of the key
strengths of the Tivoli solutions discussed in this chapter. It also indicates for
each product what the prerequisites are in terms of other Tivoli products:
Table 2. Summary of Tivolis Management Solutions
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
Integration with Tivoli

and partners
management
applications and
ability of correlating
the events.
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
GEM monitors the

state of discrete
applications as well as
the relationships and
data flow between
interconnected
applications and the
dependencies
between applications
and physical
resources.
Tivoli Global
Sign-On
Provides a secure and

easy to use solution
that grants users
access to the
computing resources
they are authorized to
use with just one logon.
Tivoli Framework
Tivoli User
Administration
Tivoli Software
Distribution
Removes the need

for end-users to
manage multiple
user-IDs and
passwords.
Simplifies user ID
management.
Tivoli
Workload
Scheduler
Uses common policies

to manage job
schedules across
platforms and
applications.
n/a
Integrates R/3 batch

workloads with other
application job
schedules.
Tivoli
Solution
Description
Prerequisite
Key Strengths
Tivoli
Decision
Support
Reporting and analysis

via Online Analytical
Processing (OLAP)
enables exploration of
management data to
evaluate trends, analyze
event impact, plan
upgrades, prevent
recurrence of problems.
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
Predefined monitors for

unattended monitoring
of database
performance and
availability. Task libraries
automate routine
administrative tasks.
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
Uses Tivoli Inventory or

other query to select
targets for push or pull
distribution. Fans out
distribution service to
regional servers.
Tivoli Framework
Breadth of Platforms
covered. Scalability.
Tivoli Output
Manager
Delivers any output to

any user based on
central policy and user
preferences. Ensures
that R/3 printing
completes.
n/a
Breadth of output and

platform coverage.
Central policy allows
user participation in
output decisions.
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
Breadth of data and

platforms covered.
Speed and
automation of backup
and hierarchical
storage management.
Fault recovery
capabilities.
Repeatable, reliable
backup and recovery
of R/3.
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
Because it covers all

the different
measurement
techniques, it provides
the basis for accurate
measurement and
reporting.
Tivoli
Netview
Tivoli solution focused

on managing IP-based
networks. Generates
SNMP traps that are
displayed in a central
event window.
Tivoli Framework
Simple to use and

configure. Gives the
ability to view the
status of the whole IP
network at once.
Tivoli User
Administrati
on
Extends the capabilities

of the Tivoli environment
to allow the
management of user
accounts on a number of
platforms including R/3.
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
Makes Tivoli Security

Management
simpler. Allows and
encourages the
exchange of
knowledge and
experience.
The following sections describe overview of each Tivoli Enterprise Products

that enable highly integrated SAP R/3 management.
1.11.1 Tivoli Management Framework

The Tivoli Management Framework is the backbone of the Tivoli solution and
the basis for all Tivoli systems management applications. The Tivoli
Framework provides the basic systems management services, such as
communications, presentation, security, and so forth, that all the Tivoli
systems management applications use, therefore, ensuring consistency and
integration.
All Tivoli systems management tasks, regardless of the application or
component that is to be managed, are performed using the Tivoli Desktop,
which provides a user interface consistent throughout Tivoli management
applications.
1.11.2 Tivoli Distributed Monitoring

Tivoli Distributed Monitoring is the Tivoli application for monitoring systems
and applications. Distributed monitoring is tightly integrated with the Tivoli
Framework and provides monitoring capabilities for a wide range of systems
and components. The strength of distributed monitoring is that monitoring
collections for components can easily be added, thus, allowing the monitoring
of any kind of component.
1.11.3 Tivoli Enterprise Console

The Tivoli Enterprise Console (TEC) provides a central event display and
correlation for the enterprise regardless from which source the events are
originating. Unlike traditional SNMP managers, Enterprise Console uses
event adapters that can convert any kind of event stream into Tivoli
Enterprise Console events that can then be processed by the Enterprise
Console. Event adapters are available for a wide range of systems and
applications.
The major strength of the Tivoli Enterprise Console is that events from any
kind of system can be displayed and, more importantly, be correlated into one
place. This allows, for example, correlating a network event that comes from
NetView with an application event coming from R/3 and triggering an action
as a result of the correlation.
Introduction
15
1.11.4 Tivoli Software Distribution

Tivoli Software Distribution provides a simple and reliable service to distribute
software in the enterprise across platforms and networks. Software
Distribution has such features as fan-out and bandwidth optimization.
Software is grouped in file packages that Software Distribution can then
automatically distribute to the desired targets.
Many applications require distribution of components or data across the
network. This function can be provided by Software Distribution. For example,
the Tivoli Manager for R/3 provides utilities that assist in the creation of file
packages. This means that the SAPGUI component can be automatically
deployed to a large number of presentation clients.
1.11.5 Tivoli Manager for SAP R/3

Tivoli Manager for R/3 is the foundation of Tivoli's comprehensive, reliable,
and cost-effective SAP R/3 management solution. It seamlessly integrates
the management of R/3 with the rest of the enterprise by monitoring R/3
resources, managing R/3 alerts, automating routine tasks, and deploying
software for R/3 desktops. Tivoli Manager for R/3 maximizes your R/3
investment by building on the Tivoli Enterprise environment. Together they
provide a common management infrastructure and comprehensive set of
management tools for enterprise R/3 management.
Tivoli Manager for R/3 consolidates management of multiple R/3 systems that
use different versions of R/3 and integrates this management with the rest of
the enterprise environment. It manages the monitoring and operational tasks
for R/3 production, testing, development, and training environments from one
central location and captures and reports events from all R/3 systems.
Through the Tivoli Enterprise Console, Tivoli Manager for R/3 manages the
display of valid events as a function of R/3 server availability. The information
of these events can be processed with the events information about the
operating system, the network, the database, and other related components.
This provides an overall picture on how the R/3 environment is performing
and helps operators quickly identify and resolve the cause of any availability
problems.
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.
1.11.6 Tivoli Decision Support

Tivoli Decision Support (TDS), along with the Tivoli Decision Support
Discovery Guides, provides a ready-to-use view into the wealth of data
gathered by Tivoli Enterprise Products. The product line consolidates this
data from Tivoli products and transforms it into easily accessible IT
business-relevant information. This information, presented in a variety of
graphical formats can be viewed interactively (slice, dice, drill down, drill
through), posted on a URL. Tivoli Decision Support provides insight,
revealing hidden patterns and natural relationships among the data and the
ability to better answer IT business-relevant questions quickly and
on-the-mark.
Tivoli Decisions Support is a multidimensional query and reporting tool and
simple query and reporting software targeted at help desks and customer
support operations. The product is specifically targeted at helping
technologists and business users better understand their internal help desk
and external customer support operations.
To meet the specific needs of help desk/customer support analysis, Tivoli
Decision Support includes two primary elements:
A combination of multidimensional analysis and reporting as well as
simple query and reporting tools - specifically Tivoli has OEMed Cognos'
PowerPlay offering and Seagate's Crystal Reports.
Templates known as Decision Support Guides that assist administrators in
selecting which questions to ask and locating the data that will answer
these questions.
These facilities are the backbone for user organizations, either alone or
working with Tivoli, to quickly incorporate focused decision support
capabilities into their own operations. The templates are a case in point.
Decision Support Guides are currently available for Call Center Performance,
Relationship Management, Knowledge Management, and Service Level
Management.
Introduction
19
Decisions Support offers a number of business advantages. The major ones

are as follows:
End-users can access information themselves. Decisions Support allows
anyone, from support analysts to CEOs, to directly view the summary and
detailed information that is relevant to them. This means that technical
staff are relieved of the burden of trying to guess what information would
be valuable to each user, as they are able to get exactly what is required
the first time. Decisions Support eliminates a number of manual and time
consuming processes, such as the traditional White Board, which is the
manual mechanism found in most call centers to display performance
data.
Business processes are changed for the better. Decisions Support
enables users to show, from a quantitative perspective, which business
activities were successful and which were not. This enables the easy
identification and correction of the most critical problem areas. This, in
turn, leads to improved call handling and support dispatching capabilities.
By discovering which activities and questions consume the most time and
energy, it is possible to allocate resources appropriately as well as
improve procedures and documentation.
Eliminates the need to build and maintain a separate and historical
database for reporting. This ability to run against production data reduces
reporting overhead on the technical staff and increases the timeliness of
reaction.
Performance Analysis and Reporting
Tivoli provides a set of reporting capabilities for performance data with a
Decisions Support Guide for Tivoli Application Performance Manager.
Organizations spend numerous hours and resources gathering performance
statistics, analyzing the data to determine needs, trends, and creating the
multidimensional graphs that evaluate their performance and needs. Tivoli
easily automates these functions in a solution that uses collected
performance data to track the performance levels of the target system.
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
What performance trends may cause problems in the future?

With expertise in targeted applications, you can create relationships between
the various performance indicators to determine trends across related data
points. For example, a performance module for the SAP R/3 environment may
provide multi-level reports on transaction execution, workload analysis, and
resource consumption. However, because of the comparatively
non-distributed nature of PeopleSoft transaction execution, implementing the
same metrics and rules for PeopleSoft might not be as efficient. To provide a
comprehensive solution across implementations of various ERP solutions
and applications, middleware and underlying database metrics also need to
be monitored and measured. Irrespective of the application, the performance
module must use the latest in object-oriented techniques, data storage and
graphical interfaces. This allows the generation of specialized reports
addressing application performance regardless of whether it encompasses a
single server or a whole enterprise.
Tivoli Decision Support for SAP R/3 (TDS R/3 Guide) provides the ability to
evaluate and analyze the performance and capacity of the SAP R/3
application. The TDS R/3 Guide can help avoid unnecessary investments in
additional server capacity by providing quantitative information and analysis
about SAP workload patterns, trends, and the service provided on a
transaction by transaction basis. The TDS R/3 Guide transforms management
of the R/3 application from a reactive, problem based approach to a proactive,
service based methodology. The end result is better service with lower overall
costs.
Included with the Tivoli Manager for R/3 is the Tivoli Decision Support for
SAP R/3, which extends management perspective to enable analysis of the
performance and capacity of the R/3 environment during long intervals.
We will describe more detailed information about Tivoli Decision Support for
SAP R/3 in Chapter 7, Examples of new features in SAP R/3 Management
on page 271.
1.11.7 Tivoli Global Enterprise Manager

The evolving role of IT today demands that IT be focused on achieving the
business goals. Companies today need to have a business-relevant view of
the technology. Tivoli Global Enterprise Manager (GEM) extends the
capabilities of Tivoli Enterprise to provide a new paradigm for applications
management called business systems management. Business systems
management allows customers to manage groups of related applications that
Introduction
21
underpin and enable critical business functions, such as enterprise resource

planning (ERP).
Mission-critical business systems present a unique management challenge.
They typically span host and distributed environments, are comprised of
many interconnected application components, both commercial and custom,
and rely on diverse middleware, databases, and supporting platforms.
Tivoli Global Enterprise Manager gives customers a single point of
management and control and allows them to utilize the concept of end-to-end
business systems management to organize related components and give
business context to management decisions.
Tivolis Global Enterprise Manager, enables customers to view the ERP
components in a unified manner. This approach significantly improves
problem solving by allowing IT staff to see the interrelationships and
dependencies between ERP components. Most importantly, Tivoli Global
Enterprise Manager allows customers to solve IT problems in the context of
the business processes that rely on the underlying technology. With Tivoli
Global Enterprise Manager, the IT staff has the knowledge they need to
understand how an underlying infrastructure problem impacts the business.
For example, the following figure (Figure 6) shows an example of business
systems management in most customer environments.
22
Scenario:
Problem Resolution Between ERP and

Other Systems
Sales Force
Automation
Server
CICS
System
Figure 6. Example: Business systems management scenario
Normally, in most customer environments, the business systems involve

many components - application server, database, application, middleware,
and so on - and these environments are complicated. Customers spend
numerous hours and resources understanding, controlling, or monitoring their
business systems topology, hierarchy, and status. Tivoli Global Enterprise
Manager easily resolves these problems and provides up-to-date topology
information of the business systems. The following figure (Figure 7) shows
Tivolis action for business systems management using Tivoli Global
Enterprise Manager.
Introduction
23
impact2:
understood in real time
Business
Scenario
Single view across multiple disciplines

Problem Resolution Between ERP and
Can manage by technical and business rules
Other
Systems
High
level views
and actions powered by product specific tools
R&D System
Manufacturing
System
MQ Series
Link for R/3
Queue
Manager
HQ System
Human Resources
System
Sales System
Figure 7. Tivolis action for business systems management
Tivoli Global Enterprise Manager is Tivolis solution for managing applications

and systems from a business perspective. Once and application is
instrumented from Global Enterprise Manager, Tivoli allows management of
this component in the wider context of a business system. The following
figure (Figure 8) gives some idea of what Global Enterprise Manager
integration looks like.
24
Figure 8. Tivoli Global Enterprise Manager
We will describe more detailed information about Tivoli Global Enterprise

Manager (GEM) in Chapter 7, Examples of new features in SAP R/3
Management on page 271.
1.11.8 Tivoli Application Performance Manager

Tivoli Application Performance Manager (TAPM) is Tivolis performance
management solution. It encompasses the best parts of four standard
measurement techniques to provide an accurate view of the end-user
application performance. This comprehensive solution tightly integrates with
Tivoli's existing resource management, alerting, reporting, and analysis
solutions. Application Performance Manager provides application
performance management in a comprehensive solution.
In recent years, two-tier client/server applications have become increasingly
important. The number of servers has increased from a few mainframes to
dozens or even hundreds of smaller systems. TCP/IP and its dynamic routing
have become the standard network protocol, and performance of the
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.
Using ARM is the least invasive technique. Response can be measured

without sending any extra traffic across the network to be processed by
servers. It also enables the collection of measurements without traffic
interception and event processing. Because application developers control
the measurements, it is easy to ensure accurate measurement of user
transactions. Even if the transaction itself changes as result of
enhancements, the instrumentation can be updated at the same time.
Transaction simulation
This method does not measure the real application. A script or program acts
as a proxy for it. The proxy is executed periodically, and it passes
measurements to an agent, preferably by making ARM API calls. The results
of this can be used to approximate the end-user experience. However,
26
because it is a simulation, the results can never be considered too accurate

although they can be used to predict performance problems.
Transaction simulation is considered a low-cost and reliable approach. It does
not depend on access to source code, and it has two distinct advantages over
the other options:
1. It can be used to establish a consistent baseline for trend analysis.
2. It can be used to actively probe networks and servers at a time when no
users are active, such as in the middle of the night.
However, problems can arise in some environments, as this method creates
artificial loads, and it does not measure actual user transactions.
Client capture
This does not require any changes to be made to the application. Instead, it
relies on sensors at key interfaces. These observe all activity of that type
within a system. An event indicating the activity is forwarded to an event filter
where events unrelated to the monitored application are discarded. The
remaining events are forwarded to an event analyzer. The analyzer looks for
patterns to determine the type of transaction that was executed, and it
measures the response time. The status of the transaction is also captured.
This makes it possible to determine whether it completed successfully or not.
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
There are a number of challenges with implementing a solution based on

Network X-Ray probes:
Deploying enough probes can be expensive especially if you plan to
measure the response time of all users. This is particularly true in the case
of switched networks.
Probes have little or no business process context. Scaling one probe to
measure many hundreds of users is a difficult task.
If your environment uses encryption, probes cannot measure any
transactions.
Generally, because it is a challenge to associate individual packets with an
application, Network X-Ray has limited value in determining performance
information in a business application context.
The Tivoli Approach to Application Performance Management
The following figure (Figure 9) illustrates the Tivoli approach to managing
application performance including service levels. The approach uses all three
system based techniques in conjunction with a back-end process for
managing the measured data.
Start
Application
Using ARM
Stop
Measurement
Agent
Start
Transactions
Simulating
Applications
Stop
Client Capture
Sensor
Application
Sensor
Event
Filter
Event
Transactions
Analyzer
Sensor
Figure 9. The Tivoli approach to managing application performance
28
This approach allows the ability to measure different transactions in different

ways depending on the environmental needs. It also enables the use of
multiple measure techniques on the same system. One possible scenario is
that the ARM is used for end-user transactions, however, client capture could
be used to measure lower level calls to a server or database.
No matter how a transaction is measured, the same management processes
can be applied to the data. The collected data can be used for service-level
reporting, on-line monitoring, or even problem diagnosis. Ultimately,
techniques can be combined with the same agent and even for the same
transaction.
Performance monitoring is a basic prerequisite for performance management.
Performance monitoring enables real-time data collection and analysis to
report the current status of the application, the level of resource consumption,
and the rate of error detection.
Tivoli Application Performance Manager forms the foundation for the
following:
1. Managing compliance with Service Level Agreements (SLAs).
2. Isolating bottlenecks.
3. Balancing workloads to optimize service levels and cost efficiencies.
4. Analyzing transactions and their resource consumption to understand how
to redesign and reconfigure the application to achieve optimal
performance.
5. Tuning resources.
Tivoli Application Performance Manager focuses on performance
management from an end-user or business perspective. This enables Tivoli
Application Performance Manager to measure the service levels of business
transactions and use this information as a basis for understanding how each
component affects the application performance. Once a component is found
to be a major factor in end-user service levels, it can then be analyzed and
investigated in depth.
Tivoli Application Performance Manager bases performance on the effect to
end-users. This means that time and money are not wasted on pursuing
solutions that provide less than the maximum possible value.
With the use of analysis programs, great quantities of data can be reduced
and refined to the information necessary to make informed business
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
Instead of drowning in the data, intelligent combination of all this data

provides usable information to IT and business managers.
We will describe more detailed information about Tivoli Application
Performance Manager (TAPM) in Chapter 7, Examples of new features in
SAP R/3 Management on page 271.
1.11.9 Tivoli Database Management Products

The Tivoli Database Manager Products allow for the seamless management
of RDBMS components with Tivoli. Similar to the Tivoli Manager for R/3, they
use the Tivoli Management Framework and core applications to manage a
certain application, in this case, RDBMS servers.
1.11.9.1 Tivoli Manager for DB2
Tivoli Manager for DB2 addresses the needs of DBAs who support the
operational environment. It focuses on monitoring DB2 servers, task
scheduling, and automated task execution on AIX, Sun Solaris, and Windows
NT. DBAs can discover databases automatically and display DB2 instance
and database properties. Tivoli Manager for DB2 provides DB2 systems
management on the Tivoli Management Framework. Using the Tivoli
management by subscription paradigm, Tivoli Manager for DB2 provides the
database administrator with the necessary controls to manage hundreds of
DB2 servers from one console.
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
resources are available and operating optimally. These people generally do

not have the level of database specific knowledge that a DBA possesses but
must be able to detect problems with databases and engage the appropriate
expertise to remedy the situation. By providing a sophisticated event and alert
management solution, the Tivoli Manager for Oracle reduces the overhead
and streamlines the problem detection and resolution cycle for these people,
therefore, resulting in higher database availability.
1.11.9.3 Tivoli Manager for Sybase
The Tivoli Manager for Sybase performs a very similar task to the Tivoli
Manager for Oracle described above. It is designed to aid the same two
groups as the Tivoli Manager for Oracle and also provides the same cost and
time reductions afforded by that product. They could almost be classified as
identical in feel and function.
For example, the following figure (Figure 10) shows an example of database
management in most customer environments.
Scenario:
ERP Availability - Database slow!
Figure 10. Example: Database management 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:
All Actions taken Automatically

ERP Availability - Database slow!
ERP system not effected
No requirement for operator, help desk, DBA, or
Basis/Peopletools specialists
Tivoli
Distributed
Monitoring /
DB Managers
Tivoli
Enterprise
Console
Figure 11. Tivolis action for database management
Tivoli Database Manager Products enable proactive management. Tivoli

Database Manager Products provide efficient monitoring function and detect
potential problems before they occur. If some rules are defined in TEC
properly, these rules resolve the potential problem automatically. These
processes are performed without interruption; so, end-users can continue
their work using ERP applications without any problems.
1.11.10 Tivoli Manager for MQSeries

The Tivoli Manager for MQSeries is an enterprise level management solution
that brings Tivolis life-cycle management capabilities to organizations using
the MQSeries across host and distributed environments. The most powerful
aspect of Tivolis MQSeries management approach is that MQSeries is
managed in the context of the applications and business systems that utilize
it. This provides IT managers with the information they need to understand
the business-level impact of MQSeries availability and performance.
Introduction
33
It is the only MQSeries management solution that manages MQSeries and is

an integral part of a larger business solution. It is also the only MQSeries
management product that manages the entire application stack, from
low-level network and operating system resources up through the
applications, that utilize MQSeries for messaging. Tivoli Manager for
MQSeries provides centralized management for distributed MQSeries
networks that span geographic distances and heterogeneous systems.
Tivoli Manager for MQSeries has a number of management services. The
following table lists these along with their functions and benefits:
Table 3. Functions and benefits of Tivoli Manager for MQSeries
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.
Saves significant time, effort,

and money in deploying
MQSeries software and
subsequent upgrades.
MQSeries
Configuration
Supports the definition and

configuration of MQ objects
from a central console. A
discovery feature automatically
detects Queue Managers and
their associated objects in
MQSeries networks--even on
OS/390.
Reduces the complexity of

defining and deploying
MQSeries networks resulting in
speedier and less error-prone
deployments.
Comprehensive
Monitoring
Provides extensive in-band and

out-of-band monitoring to
ensure the availability of
MQSeries. Captures MQSeries
events and passes them to a
central console for display and
action. The health and
performance of MQSeries
processes, hosts, and system
resources necessary for
reliable MQSeries operation is
monitored and displayed live at
the central management
console.
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.
Simplifies and reduces labor

required to manage MQSeries
networks.
Rules-Based
Event
Correlation
Correlates MQSeries events

with other sources, such as
network devices and operating
systems, based on
user-defined rules.
Allows events to be evaluated in

context with one another for
accurate problem diagnosis
and resolution.
Automated
Operations
Actions can be automated to

execute on a scheduled basis
or as the result of event
occurrences.
Provides lights-out
management.
End-to-end
MQSeries
Management
Manages MQSeries networks

that span host and distributed
environments.
A complete view and

manageability of your entire
MQSeries network.
Tivoli Global
Enterprise
Manager
Integration
Allows MQSeries to be
managed as a component of
larger business systems.
Higher availability of the

business systems that drive
your business.
1.11.11 Tivoli Workload Scheduler

Tivoli Workload Scheduler, also known as Maestro, is the Tivoli product for
enterprise-wide job scheduling. Tivoli Workload Scheduler is an application
with full functionality in scheduling purposes and is available on several
platforms. Currently, these include all flavours of UNIX, for example, AIX and
HP UX, Windows 95, Windows 98, and Windows NT. It can be integrated with
Tivoli using the Tivoli Plus for Tivoli Workload Scheduler product. This
product allows the management of Tivoli Workload Scheduler from the Tivoli
Desktop.
Tivoli Workload Scheduler for SAP R/3:
Tivoli Workload Scheduler has been certified with SAP's Business
Application Programming Interface (BAPI) for scheduling R/3.
Enables batch job coordination between SAP R/3 and other environments.
Is certified by SAP.
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
Allows a single point of control

for SAP R/3 and non-SAP R/3
scheduling.
Saves money through

reduced training and
simplifies troubleshooting
through consolidated
information.
Cross-application
support
Allows scheduling
dependencies between
disparate system.
Enables SAP R/3 jobs to be

dependent on non-SAP R/3
jobs and vice-versa.
Fault tolerance
Allows processing to continue

in the event of a node or
network failure.
Ensures reliability in the

SAP/R3 scheduling
environment.
Rule-based
processing
Introduces advanced
scheduling features into the
SAP R/3 environment through
Tivoli Workload Scheduler.
Improves and expands data

integrity enterprise wide.
1.11.12 Tivoli User Administration

Tivoli User Administration extends the capabilities of the Tivoli environment to
allow management of user accounts on UNIX, Windows NT, and Novell
NetWare platforms (Tivoli User Administration for SAP R/3). Additionally, and
of most relevance to this book, you can also manage SAP R/3 user accounts
all from a single location.
Tivoli User Administration provides your network computing environment with
the following features:
Centralized and GUI-based control of administration tasks.
Consistent administrative policy definition.
Automation of repetitive administration tasks.
Parallel operations performed on many users and systems.
Delegation of administrative tasks to other administrators.
Configuration error reduction via profile based methodology.
Single action user management to synchronize logins and passwords.
36
1.11.13 Tivoli Global Sign-On

Tivoli Global Sign-On provides a secure and easy to use solution that grants
users access to the computing resources they are authorized to use with just
one logon. Global Sign-On is primarily designed for large enterprises, which
consist of multiple applications and systems, within heterogeneous,
distributed computing environments. Global Sign-On removes the need for
end-users to manage multiple user IDs and passwords.
1.11.13.1 Tivoli Global Sign-On Components
Tivoli Global Sign-On consists of a number of components. When Global
Sign-On is installed, so are the following items:
Tivoli Global Sign-On Plus Module

Tivoli Global Sign-On Server
Tivoli Global Sign-On Clients
Tivoli Global Sign-On Database Server (Optional)
Tivoli Global Sign-On Database Client (Optional)
Tivoli Global Sign-On User Administration
Tivoli Global Sign-On Plus Module
The Tivoli Global Sign-On Plus Module is a prerequisite that must be installed
before the Tivoli environment can be used to create and distribute the Global
Sign-On Server and Client.
Using the Plus modules and Tivoli Software Distribution, it is possible to

distribute Global Sign-On applications file packages. The Plus modules must
be installed on the TMR server, on the Tivoli Enterprise Console server and
on all Managed Nodes that are going to be Global Sign-On servers or
database servers.
The Tivoli Global Sign-On Plus Module provides some predefined monitors,
event filters, and correlation rules. The monitors can be used with Tivoli
Distributed Monitoring, which allows the management of vital Global Sign-On
components, such as process and log files. The Tivoli Enterprise Console can
be used with the filters and rules to automate the response to specific events.
Tivoli Global Sign-On Server
When the Global Sign-On Server is installed in a Managed Node in a Tivoli
environment, it transforms the node into a Global Sign-On server. The
primary functions of a centralized server are user authentication and user
configuration management.
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.
The Global Sign-On Client is composed of the following core pieces:

User Interface
This, not surprisingly, is responsible for all interactions with the user.
These interactions can be performed by the use of GUI or a CLI.
Authentication Service
This is responsible for the user authentication. It interacts with the Global
Sign-On server to verify the users ID and password and to collect
additional user information.
Management Service
This service allows the user to perform administration activities, for
example, password changes, changing target definitions, and so forth. It
interacts with the Global Sign-On server to store or change the user
definitions.
Logon Coordinator
The function of this is to actually perform the logons to the various targets
as well as getting the users target information from the Global Sign-On
server.
Communication Service
This service is responsible for the communication between the Global
Sign-On server and the clients. This is achieved via secure encryption
methods (Data Encryption Standard).
38
The Global Sign-On client is supported on the following platforms:

Microsoft Windows NT 4.0
Microsoft Windows 95 (All)
Microsoft Windows 98 (All)
Tivoli Global Sign-On Database Server (Optional)
The Global Sign-On Database Server component is used to assure that
Global Sign-On database clients have authenticated access to an underlying
RDBMS. It is recommended that the Global Sign-On Database Server
component is installed on the same physical machine as the RDBMS itself.
The Global Sign-On Database Server component supports the following

databases:
DB2/6000 2.1.1.2
Oracle 7.X
Sybase 10.X
Informix 7.X
Microsoft SQL Server 6.X
Tivoli Global Sign-On Database Client (Optional)
The Global Sign-On Database Client component is installed on a normal
Global Sign-On Client so that database user authentication can be performed
with the RDBMS running on the Global Sign-On Database Server. This
component varies depending on the RDBMS that is being used. With this
component installed, the workstation is also classed as a Global Sign-On
database client.
Tivoli Global Sign-On User Administration
The Global Sign-On User Administration component adds Global Sign-On
user properties to Tivoli Management Framework. It provides a single point of
control for managing Global Sign-On information for existing Tivoli UNIX,
Windows NT, and NetWare user accounts. The Tivoli Global Sign-On User
Administration component can be installed from any managed node in the
TMR. It should be installed on the TMR server where the current Tivoli User
Administration component is installed and also on any Managed Nodes that
are required to be Global Sign-On servers or database servers.
The Global Sign-On User Administration component upgrades Tivoli User

Administration by including new catergories, subcategories, and attributes.
These allow the management of several segments of the Global Sign-On user
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:
AIX 4.2.X, 4.3.1

Sun Solaris 2.5.1
Microsoft Windows NT 4.0 (Service Pack 3)
Hewlett Packard 10.20 (for the Global Sign-On User Administration and
Plus Modules only)
1.11.14 Tivoli Security Management (Lockdown Module)

Tivoli Security Management provides maximum flexibility and improvements
in administrator reliability and efficiency. Tivoli Security Management
achieves this by abstracting from the security model of individual platforms. It
still manages the platform specific security data; however, it achieves cross
platform security modelling through role-based security. There are significant
benefits to this form of abstraction, but it makes the implementation of the
security module more difficult. An ideal Tivoli Security Management
implementation design would include the identification of all job tasks in an
organization as well as the IT resource access requirements to fulfill each of
those tasks. This data would then form the basis of Tivoli Security
Management roles and resource data. This would require that all personnel
also be defined in Tivoli Security Management groups. In a large
organization, this can take a long time.
Tivoli Security Management was the first security product that was designed
from the ground up to manage access control in a consistent fashion in a
distributed environment using a role-based security model. With role-based
security, it is possible to determine what resources people have access to
based on the job tasks or roles that they need to perform. In Tivoli Security
Management, these resources can be of different types including files,
printers, programs, or TCP services. They can also reside on different
platform types, such as Windows NT, different flavours of UNIX, and on
OS/390 systems protected by the OS/390 Security Resource Access Control
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
Figure 12. Example of security groups and roles
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
Locking down applications with Tivoli Security Management should be one

part of a coordinated security policy. Tivoli Security Management greatly
enhances access control management and consistency; however, it is of
little use if other aspects, such as physical access ti servers or password
controls, are not considered.
The goal of using a Lockdown Module is to make Tivoli Security Management
simpler, whether by developing your own, or obtaining the ready-made Tivoli
versions. They also allow and encourage the exchange of knowledge and
experience. For further information on lockdown modules, please refer to the
redbook Securing Applications with Tivoli Security Management Lockdown
Modules , SG24-5140.
1.11.15 Tivoli Storage Manager (Tivoli ADSM)

Tivoli Storage Manager is a full-function storage software set that manages
the complete range of information needs, by providing business continuity for
planned and unplanned outages, and delivering "one-touch" control over the
entire "info-structure". Built upon the solid, award-winning foundation of IBMs
ADSTAR Distributed Storage Manager (ADSM), Tivoli Storage Manager set is
a new standard in information management and protection.
Tivoli Storage Manager (Tivoli ADSM) is Tivolis enterprise backup/restore
and archive/retrieve solution that is available on a wide range of platforms.
Tivoli Storage Manager provides integration of several databases and
applications, such as DB/2, Oracle, Lotus Notes, SAP R/3, and so forth.
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.
1.11.16 Tivoli Output Manager

Tivoli Output Manager, formerly known as Destiny, is the Tivoli product for
enterprise-wide output control. The output environment is an ever changing
and diverse environment containing different printing devices (Postscript,
PCL, encapsulated PostScript, plotters, line printers), different printer
cartridge fonts in printing devices, facsimile machines, Web servers, different
mail gateways (X400, PROFS, cc:Mail, Lotus Notes, Microsoft Exchange,
Microsoft MS Mail, Microsoft OutLook, SMTP), and the global differences in
paper sizes in the distribution centers. Companies are starting to look at
enterprise output managers for coordination, routing paths, delivery, and
above all, security of documents. The Tivoli Output Manager is positioned to
do this with an easy-to-use user interface and rule engine to deliver
documents reliably across the enterprise.
Enterprise applications, such as SAP R/3, rely on the output environment to
deliver the critical daily, weekly, and month-end reports to a single end user or
groups of management teams. It is the responsibility of the enterprise output
manager to orchestrate and deliver these reports according to the business
rules that have been defined by the process engineers. The following figure
shows a typical output environment.
Introduction
43
Fax
Print
Engineering
Web
Manufacturing
Executive
Product
Requirements
Web
Revenue
Forecast
Marketing
Mix
Email
Marketing
Sales
Figure 13. Typical output environment
Tivoli Output Manager provides the following:

Centralize output management
Controlled access of output resources
Routed output resources
Reliable and secure output channels
Automated delivery channels
1.11.16.1 Centralized Output Management
Tivoli Output Manager provides administrators the option of fully centralized
administration, fully distributed administration, or a mix of both environments.
The consoles that the administrators used are based on Java. Two types of
consoles are available. One console manipulates the structure of the
environment, and the other console performs the operation of the
environment. The console that manipulates the environment logs on to the
enterprise component of Tivoli Output Manager and can cause WAN network
traffic. The console manipulates the operational structure, logs on to the
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.
Just like administrators, users also have to go through the authorization

layers to use the output network. This provides user-to-user notifications and
reliable access control of the resources in the output network.
1.11.16.3 Routed Output Resources
Tivoli Output Manager is structured around a rule-based foundation. When
certain resources are down, fault tolerant routing rules can still deliver and
notify the appropriate people of the different path that was used. This is very
useful for mission critical reports.
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
1.11.16.5 Automated Delivery Channels

This option of the 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.
This attribute, at first glance, seems inappropriate, but when it comes to

enterprise security and re-routing of output devices, it makes sense. With
automated delivery channels, you can track headers and apply audit rules to
all, or some, of the channels.
1.11.17 Tivoli NetView

Tivoli NetView is Tivolis network management solution that is focused on
managing IP-based networks. NetView displays the nodes in the network on
a map representing the network topology and the status of the network
nodes.
In the case of something happening in the network, NetView generates
Simple Network Management Protocol (SNMP) traps that are displayed in a
central event window and that can trigger actions or correlations. In that
regard, NetView is similar to the Tivoli Enterprise Console. However, NetView
is exclusively focused on processing SNMP events, usually events related to
the network. However, NetView alerts can be forwarded onto the Tivoli
Enterprise Console by the application of simple filter rules.
NetView can also receive events created by external sources, such as the
servers it is monitoring. These are received in the form of SNMP traps
formatted for display in the NetView event window.
The following figure shows an environment displayed on a NetView map, with
the Control Desk attached at the bottom of screen to display SNMP alerts.
46
Figure 14. Example of a NetView display
Introduction
47
48
Chapter 2. What is new: Tivoli Manager for R/3 Version 2.0

Tivoli Manager for R/3 is the foundation of Tivoli's comprehensive, reliable,
and cost-effective R/3 management solution. It seamlessly integrates the
management of R/3 with the rest of the enterprise by monitoring R/3
resources, managing R/3 alerts, automating routine tasks, and deploying
software for R/3 desktops. Tivoli Manager for R/3 maximizes your R/3
investment by building on the Tivoli Enterprise environment. Together they
provide a common management infrastructure and comprehensive set of
management tools for enterprise R/3 management.
Version 2.0 of Tivoli Manager for R/3 improves its management ability
dramatically. It provides more reliable, flexible, and scalable SAP R/3
management, and it allows you to manage multiple R/3 systems efficiently
and easily even if it is in a large-scale environment.
In this chapter, we introduce the overview and highlights of Version 2.0 of
Tivoli Manager for R/3 and what is new in Version 2.0 of the Tivoli Manager
for R/3.
Note
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.
2.1 Tivoli Manager for R/3 packaging

Tivoli Manager series products are complicated products, especially R/3
Manager because it consists of a variety Tivoli core product facilities. In other
words, R/3 Manager is a complex package for managing R/3 systems using
Tivoli products or features. R/3 Manager consists of the following facilities:
Policy Region
Profile Manager
Sentry Monitor
Indicator
Task
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
Tivoli Manager for R/3

Figure 15. Tivoli Manager for R/3 components
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
Tivoli Enterprise Console
Other Products
Tivoli Management Framework

Figure 16. The relationship between Tivoli Core Applications and R/3 Manager
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
An Introduction to Tivolis TME 10, SG24-4948

Tivoli Enterprise Internals and Problem Determination, SG24-2034
2.2 Overview of the Tivoli Manager for R/3

Tivoli Manager for R/3 consolidates the management of multiple R/3 systems
that use different version of the R/3 application. It is capable of managing the
monitoring and operational tasks for R/3 testing, development, and
production from a centralized location. It captures and reports events from all
R/3 systems and has the ability to forward these onto the Tivoli Enterprise
Console. The Manager for R/3 enables the integration of information
regarding R/3 availability with information about the operating system,
network, database, and other R/3 related components. It provides an overall
What is new: Tivoli Manager for R/3 Version 2.0
51
picture of how the R/3 environment is performing and helps operators quickly
identify and resolve the cause of any availability problems.
2.2.1 Brief overview of new features and improvements

The new release of the Tivoli Manager for R/3 has many improvements and
additions over the old version. What follows is a brief overview of each of
these new features, which will be covered in greater depth later on in the
chapter.
2.2.1.1 Product Restructure
As the title suggests, the product has been largely restructured. This includes
a new object structure, a new configuration policy subregion, and the ability to
monitor the current status of an application server indicated by its icon on the
Tivoli Desktop. The new object structure means that each R/3 system is
configured as a policy subregion that contains the application servers and the
database server that define the R/3 system. The new configuration policy
subregion contains new configuration and list maintenance tasks specific to
SAP R/3.
2.2.1.2 Common Tasks and Monitors
These enable the distribution of tasks and monitors to all servers across the
R/3 systems managed by the Tivoli Management Region (TMR) server. New
Tivoli Distributed Monitoring collections provide a wide range of internal and
external R/3 monitors, such as the monitoring of performance statistics from
the R/3 SysMan or monitoring internal R/3 buffer statistics by using the R/3
Remote Function Call (RFC) interface. All of these include configurable
thresholds and responses, which enable effective monitoring and automatic
creation of differing severity levels of Tivoli Enterprise Console events.
2.2.1.3 Integration of Common R/3 Resource Roles
The Tivoli Manager for R/3 now uses three resource roles that can be
assigned to Tivoli Administrators. These roles allow the control of access to
R/3 systems and tasks. These resource roles are common across R/3
systems.
2.2.1.4 New R/3 Specific Tasks
There are now three new tasks that can perform the following actions:
Configure automatic discovery of R/3 systems and servers

Manage R/3 batch jobs
Manage work processes
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).
This is a new and significant function. Tivoli-provided filtering capabilities can

be applied to these events. Please refer to 5.3.3, Syslog Adapter on page
189 for more detailed information about the Syslog Event Adapter.
2.2.1.7 Improved Event Filtering
It is now possible to filter events at the Event Adapters so that only particular
events are forwarded onto the Tivoli Enterprise Console.
2.2.1.8 Miscellaneous Improvements and Features
The following is a list of the other improvements or new features that have
been added to this version of the Tivoli Manager for R/3:
The wr3rfc command line interface (CLI) now supports multi-column,

heterogeneous tables.
Improved interconnected TMR support.
Support for Tivoli Management Agent (TMA) endpoints.
Support for the Tivoli Global Enterprise Manager.
The remainder of this chapter explains all of the new features and
improvements listed in this section in much greater detail. The first of these is
the new product structure.
53
2.3 New functions in Version 2.0 of Tivoli Manager for R/3

Version 2.0 of Tivoli Manager for R/3 provides significant new functions and
usability enhancements over the previous release. The following are new
functions and features of Version 2.0 of R/3 Manager:
Restructure of Tivoli Manager for R/3 to improve scalability, usability, and
maintainability.
Tivoli Management Agent (TMA) support.
Tivoli Global Enterprise Manager (GEM) support.
Automatic Discovery of R/3 servers.
Improved R/3 application server status reporting on both the Tivoli and
GEM consoles.
Extensibility improvements in the RFC API tool.
R/3 syslog adapter.
New batch and process tasks and monitors.
Migration tools for migrating to Tivoli Manager for R/3 V2.0 from release
1.5 and 1.5.1 only.
Improved interconnected TMR support for TEC.
De-installation tools.
Delivery of ABAP programs using J class instead of Z class.
Event filtering for both alert and syslog event adapters.
In the following sections, we introduce each new function in detail and explain
how each works.
2.3.1 Restructure of Tivoli Manager for R/3

In Version 2.0 of Tivoli Manager for R/3, the restructure of R/3 Manager is
applied to several aspects. As a result, the user interface or configuration
methods are a little different from the previous version of R/3 Manager.
Basically, Version 2.0 of R/3 Manager becomes much simpler than the
previous version of R/3 Manager in improving scalability, usability, and
maintainability.
In this section, we introduce the restructure of the following aspects and show
the differences and changes between Version 2.0 of R/3 Manager and the
previous version of R/3 Manager.
New icons and nesting level
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.
After completing installation of R/3 Manager, the Manager for R3 policy

region appears with a new icon on Tivoli Desktop. The following figure (Figure
17) shows this new icon.
Figure 17. Tivoli Manager for R3 icon on Tivoli Desktop
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)
Figure 18. Contents of manager for R/3 Policy Region
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
R3 Internal Tasks (Task Library)

R3 List Maintenance Tasks (Task Library)
As you can see, it reduces the hierarchy from five levels to two levels
compared to the previous version of R/3 Manager. It enables you to reach the
appropriate managed resource icon easily and quickly.
Once you complete the managed R/3 resources configuration, the R/3
objects are created in the Manager for R/3 policy region (refer to Figure 19).
Figure 19. R/3 System on policy region: Manager for R3
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
Figure 20. Application server and database server in R/3 System
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.
A large-scale environment of R/3 systems could contain many R/3 servers.

Version 2.0 of R/3 Manager use the R/3 system System Identifier (SID), but
does not have SID-specific code. Basically, it simplifies R/3 management
operations greatly.
SID is a three-character identifier (ID) for an R/3 system. In the prior version
of R/3 Manager, you need to define R/3 systems depending upon each SID,
and there is a copy of the task libraries and monitoring collections for each
SID. In Version 2.0 of R/3 Manager, you only need one copy of them for all
SIDs. This means that you can distribute a single task or monitor to all R/3
systems. In other words, you do not need to define tasks or monitors for each
SID. Since you need to maintain only one copy, it improves your
maintainability.
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
2.3.1.3 New Resource Roles of Tivoli Manager for R/3

Restructure of R/3 Manager simplifies the security model as well. In the
previous version of R/3 Manager, you have authorization roles for each SID.
In Version 2.0 of R/3 Manager, three new roles are used for all SIDs. These
roles allow you to utilize Tivoli global and resource-specific permissions
effectively.
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
Figure 23. New TMR roles of manager for R/3
To use an R/3 Manager task, at least one of these authorization roles is

necessary. In addition to the R/3 authorization, basic Tivoli authorization
roles, such as user, admin, or senior, are required when the task is executed.
Table 5 shows the relationship between the R/3 authorization role, the basic
Tivoli authorization role, and the granted authority for each roles.
Table 5. The Relationship between R/3 Roles and Tivoli Basic Roles
R/3
Authorization
Role
Basic Tivoli
Authorization
Role
Authority
r3_user
user
-Tasks in the R/3 System Task Library

-Tasks in the R/3 APP Server Task Library
-Tasks in the R/3 DB Server Task Library
r3_admin
admin
-Tasks in the R/3 Configuration Task Library except

for the Configuration Remote Function Call
-Create New Subscriber List task in the R/3 List
Maintenance Task Library
r3_senior
senior
-Configure Remote Function Call task in the R/3

Configuration Task Library
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
2.3.2 Tivoli Management Agent (TMA) support

Version 2.0 of R/3 Manager supports Tivoli Management Agent (TMA). In the
prior version of R/3 Manager, the R/3 application server and database server
must be configured on Managed Node; however, in Version 2.0 of R/3
Manager, the R/3 application server and database server can be configured
on TMA. It will reduce the number of Managed Nodes in your TMR and helps
to lighten the load of the TMR server. TMA is highly configurable and flexible.
The TMA support of Version 2.0 of R/3 Manager allows you to perform
reliable and extensible SAP R/3 management.
To support TMA, Tivoli Application Proxy plays a vital role in your SAP R/3
management environment. The next section introduces Tivoli Application
Proxy and how it works in your management environment.
2.3.2.1 What is Tivoli Application Proxy?
Version 2.0 of Tivoli Manager for R/3 requires several Tivoli core applications as
the prerequisite, for example, Tivoli Management Framework, Distributed
Monitoring, Tivoli Enterprise Console, and Software Distribution. In addition to
these prerequisite products, Version 2.0 of R/3 Manager requires one more
product, Tivoli Application Proxy.
Application Proxy is an extension of the Tivoli Framework that provides a

common set of services that are used by the Manager for R/3. Application
Proxy enables the R/3 Manager to run on Tivoli Management Agent (TMA).
Application Proxy provides the interface function between the R/3 Manager
and TMA. Application Proxy is independent of the R/3 Manager. This means
that the R/3 Manager does not need to care about whether its object is
created on a TMA or Managed Node, and Application Proxy handles each
request that is related to TMA.
As we mentioned, Application Proxy is independent of R/3 Manager.
Therefore, in the near future, Application Proxy will be used by other Tivoli
Manager series products, such as Tivoli Manager for Domino, and will provide
the interface function between other Tivoli Manager series products and TMA.
In other words, several Tivoli Manager series products will support TMA in the
near future as well.
62
Note
Application Proxy must be installed on the following nodes in your TMR.

TMR server
TEC server
Managed Node (that runs an R/3 application server)
Endpoint Gateway (if the R/3 application server runs on a TMA)
Please refer to the Chapter 4, Planning and implementation on page 119
for more information about Application Proxy installation.
2.3.2.2 How Tivoli Application Proxy Works
To support TMA in R/3 Manager, the R/3 Manager has to manage the
relationship between its R/3 objects and each TMA. In other words, the R/3
Manager must understand which TMA contains the R/3 objects in the TMR.
This object information is stored in a Tivoli object database; however, TMA
does not have its own object database. Therefore, Application Proxy handles
this information instead of the R/3 Manager and performs the following
processes:
Handling the requests from TMA by issuing upcalls.

Redirecting the requests from R/3 Manager to TMA.
The following figure (Figure 24) shows a typical example of the Application
Proxy behavior.
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
Figure 24. The example of application proxy behavior
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
Tivoli Application Proxy is not a customer product; so, Tivoli Application

Proxy is always shipped with Tivoli Manager series products. Tivoli
Application Proxy is contained in Version 2.0 of Tivoli Manager for R/3
CD-ROM media.
2.3.3 The Tivoli Global Enterprise Manager support

It is optional, but it is possible to manage R/3 resources by using the Tivoli
Global Enterprise Manager (GEM) console in Version 2.0 of R/3 Manager.
Tivoli GEM unifies the management of cross-platform business applications.
The advantage of GEM is that the user can see information graphically; so, by
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.
Figure 25. Tivoli Global Enterprise Manager Console
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
2.3.4 Automatic Discovery

Automatic discovery is a new function that dynamically discovers the R/3
systems and servers to create Tivoli R/3 objects.
In the previous version of R/3 Manager, each R/3 object is defined by using
SID-specific indication. Version 2.0 of R/3 Manager does not implement
SID-specific indication, and it enables the R/3 Manager to perform automatic
discovery operations. The automatic discovery function provides scalability
and reliability in your SAP R/3 management.
2.3.4.1 When is Automatic Discovery used?
Normally, the automatic discovery function is useful when you initially set up
the R/3 management environment, especially in a large-scale management
environment. If you attempt to create each R/3 object manually in a
large-scale environment, it might be difficult.
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
Figure 26. Schedule setting for automatic discovery
In this example, the automatic discovery is scheduled to run every Tuesday at

5 pm.
If you would like to stop running the automatic discovery, simply run the
predefined task called Remove Autodiscovery. You need to run the task on
the target that the automatic discovery is scheduled to run regularly. The
schedule list is maintained by the operating system. Instead of logging into
each server to change the schedule, this task allows you to disable automatic
discovery by using the Tivoli Desktop.
Automatic discovery is also useful when you migrate the R/3 Manager from
Version 1.5 to Version 2.0. Using the automatic discovery function to find the
R/3 application server and database server, it can also automatically migrate
RFC (Remote Function Call) configuration data and the TEC adapter if R/3
Manager has been already installed.
2.3.4.2 Results after Running Automatic Discovery
After running the automatic discovery function, new R/3 objects are created
and an R/3 system icon shows up on the Manager for R3 policy region
automatically. You will be able to find the R/3 application server and database
server (if a database server exists) icons under the R/3 system icon. The
67
following figure (Figure 27) shows the R/3 system icon that is automatically
created by the automatic discovery function.
Figure 27. R/3 System on policy region:Manager for R3
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
Figure 28. R/3 System properties
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.
2.3.5 Improvement of status report

In Version 2.0 of R/3 Manager, we can see the status of the application server
graphically by checking the status icons. To see the status of the application
server, you simply run the Application Server Status monitor on each target.
To show the status graphically, there are four types of icons. The following
figure (Figure 29) shows each status icon that shows the status of the
application server.
69
Icon Status
Description
Icon without any indicator on the lower right corner.
R/3 application server is up and accepting logons.
Icon with ( ! ) indicator on the lower right corner.

R/3 application server is up but not accepting logons.
Icon with ( ? ) indicator on the lower right corner.

R/3 application server is in unknown status.
Icon with ( - ) indicator on the lower right corner.

R/3 application server is down.
Figure 29. The status icons of application server
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
You must distribute a monitor profile containing the Application Server

Status Monitor in order to get the icon status. This monitor is in the
standard AutoDiscovery Monitors profile but not in the R3 Server Remote
Monitors profile.
2.3.6 Extensive Improvement in RFC API Tool

In Version 2.0 of Tivoli Manager for R/3, the wr3rfc command line interface
can support a multiple column table. In the previous version of R/3 Manager,
the table is able to have only one column.
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.
2.3.7 New tasks of Version 2.0 of Tivoli Manager for R/3

Tivoli Manager for R/3 provides many predefined tasks that enable you to
manage your SAP R/3 systems easily. In Version 2.0 of R/3 Manager, three
new predefined tasks are added:
Configure Automatic Discovery
Manage R/3 Batch Job
Manage Work Processes
The following sections introduce each task in detail.
2.3.7.1 Configure Automatic Discovery
In Version 2.0 of R/3 Manager, there are four tasks related to the configure
automatic discovery tasks:
Configure Autodiscovery for NT

Configure Autodiscovery for UNIX
Remove Autodiscovery for NT
Remove Autodiscovery for UNIX
As you can see, each configuration task is provided to the specific platform
(UNIX or Windows NT). To use the automatic discovery function, run the
following predefined tasks that are located in the R3 Configuration Tasks task
library (refer to Figure 30).
71
Figure 30. Task library: R3 configuration tasks
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:
Display Batch Jobs
72
Cancel Batch Jobs

Release Batch Jobs
To use R/3 batch jobs functions, run the following tasks defined in the R3 App
Server Tasks task library. The following figure (Figure 31) shows the R3 App
Server Tasks library.
Figure 31. Task library: R3 App Server tasks
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.
Figure 32. Display batch jobs output
The following figure (Figure 33) shows the information that is obtained by the
R/3 transaction code sm37 at SAPGUI.
74
Figure 33. Job overview alphabetic on SAPGUI
Cancel Batch Job

The Cancel Batch Job task cancels an active batch job. To execute this task,
enter the job ID and job name that you want to cancel (refer to Figure 34). We
recommend you run the Display Batch Jobs task first to make sure of the
appropriate job ID and job name.
Figure 34. Cancel batch job
Release Batch Job

The Release Batch Job task releases and starts a scheduled task. To execute
this task, enter the job ID and job name that you want to release (refer to
Figure 35). We recommend you run the Display Batch Jobs task first to make
sure of the appropriate job ID and job name.
75
Figure 35. Release batch job
2.3.7.3 Work Processes

In Version 2.0 of R/3 Manager, two types of tasks related to work processes
are added:
Display Work Processes

Cancel Work Process
To use the work processes function, run the above two tasks that are defined
in the R3 App Server Tasks task library (refer to Figure 31).
Display Work Processes
The Display Work Processes task displays information about the R/3
processes running on a certain application server. In this information, you can
find the process type, process ID, status, and reason. If you also want to know
information about the CPU time, enable the CPU time option (refer to Figure
36).
Figure 36. Display work process
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.
Figure 37. Work processes output after running the task
The following figure (Figure 38) shows the information that is obtained by the
R/3 transaction code sm50 at SAPGUI.
77
Figure 38. Process overview on SAPGUI
Cancel Work Process

The Cancel Work Process task cancels an R/3 process. To execute this task,
enter the process ID. If you also want to check a core dump, enable the core
dump option (refer to Figure 39). We recommend you run Display Work
Processes task first to make sure of the appropriate process ID.
Figure 39. Cancel work process
2.3.8 New monitors of Version 2.0 of Tivoli Manager for R/3

Tivoli Manager for R/3 provides a set of monitoring collections that monitor
the R/3 application server. These monitors run on the Distributed Monitoring
engine (Sentry engine).
Version 2.0 of R/3 Manager adds three new monitors:
Long Running Work Process
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
Figure 41. Add monitor to Sentry profile (work process)
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
2.3.9 Improvement of interconnected TMR support

This enhancement provides various ways in which one or more TEC event
servers can be configured in relationship to one or more TMRs. For each
configuration, the R/3 Manager alert event adapter and the syslog event
adapter always send their events to the default TEC server regardless of the
TMR in which it is located. For the alert adapter, additional drill-down
processing is performed. Drill-down processing sends events using either
Tivoli object calls or the wpostemsg command depending on the type of
Endpoint originating the event.
This enhancement allows you to configure TEC event servers in several ways.
One TMR and one TEC event server
In this configuration, the TEC event server is defined in the TMR, and the
TEC server receives all events.
Multiple TMRs and multiple TEC event servers
In this configuration, each TMR is assumed to have its own TEC event server.
Each TEC event server receives all events from its local TMR. Optionally, you
can configure a TEC event server to automatically forward events to another
TEC event server in another TMR.
Multiple TMRs and one TEC event server
In this configuration, one TEC event server receives events from all TMRs.
Support for this configuration depends on the type of Endpoints sending
events to the TEC server:
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
In Version 2.0 of the R/3 Manager configuration, collecting R/3 Manager

events to a single TMR from both Managed Nodes and TMAs is not
supported.
2.3.10 User-Configurable Syslog Event Adapter

Tivoli Manager for R/3 provides a TEC Event Adapter that processes the
syslog and converts new entries into TEC events. Tivoli-provided filtering
capabilities can be applied to these events.
As a result, in Version 2.0 of R/3 Manager, you can configure the syslog
adapter yourself to process the syslog and convert new entries into the TEC
events. The syslog adapter supports user-defined event classes and servers
on a per message basis. The syslog event adapter is very powerful and
flexible feature. Please refer to 5.3.3, Syslog Adapter on page 189 for more
detailed information.
2.3.11 Filtering events

In the prior version of the R/3 Manager environment, you might have some
kinds of R/3 events that you do not like to display on the TEC console
because these events are unnecessary for further action or considered as
harmless events. In this case, to avoid displaying some particular events on
the TEC console you usually filter the events by using the TEC rule base
function.
In Version 2.0 of R/3 Manager, you can use the following configuration files to
filter the events on the TEC console.
Alert Event Adapter
Use the r3mibIID.conf configuration file.
Syslog Event Adapter
Use the r3slogIID.cl and r3slogIID.conf

configuration files.
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
$LCF_BINDIR/../../generic_unix/TME/SAP directory (on the TMA). The

following table (Table 6) summarizes the de-install script information.
Table 6. Description and Location of two De-install Scripts
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
As you can see in the following list, the $BINDIR/../generic_unix/TME/SAP

directory on the TMR server contains two de-install scripts,
R3Mgr_tmr_deinstall.2.0 and R3Mgr_tmr_deinstall.2.0.
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
Once you have completed the de-installation processes by using the

R3Mgr_tmr_deinstall20 script on the TMR server and R3Mgr_mn_deinstall20
script on all Managed Nodes and TMAs, the Manager for R3 policy region and
the objects that are contained in the Manager for R/3 policy region will be
deleted as well. Therefore, all objects and files related to the R/3 Manager,
r3mib and r3slog services or processes, will be removed or stopped as well.
When the de-install script completes the de-installation processes on a
Managed Node successfully, the following messages are logged into the log
file of the de-install script:
-------BEGINNING OF THE DEINSTALLING_MN LOG FILE -------Your INTERP is aix4-r1 and TMP is /tmp
---Your BINDIR is /usr/local/Tivoli/bin/aix4-r1.
---YOU ARE IN THE PROCESS OF DELETING ALL "Manager for R3" FILES!
---ARE YOU SURE YOU WANT TO DELETE ALL "Manager for R3" ?
86
---TYPE "y" TO CONTINUE, OR "n" to exit.

---+Your input is yes
---Continuing ...
---NOW DELETING FILES...
---THIS IS YOUR LAST CHANCE TO STOP DELETING "Manager for R3"
---PLEASE TYPE "y" TO CONTINUE, "n" TO EXIT.
---+Your input is yes
---Continuing ...
---The present managed node is wwdn07.
+wlookup ServerManagedNode
1533820760.1.348#TMF_ManagedNode::Managed_Node#
+idlcall 1533820760.1.348#TMF_ManagedNode::Managed_Node# _get_label
"pokibmxtmrb20.pok.ibm.com"+ps -ef |grep [r]3mib |grep -v vi
---The tecad processes are:
+ps -ef |grep [r]3slog |grep -v vi
---1.) DELETING YOUR Manager for R3 files at location
/usr/local/Tivoli/bin/aix4-r1/TME/SAP
+rm -rf /usr/local/Tivoli/bin/aix4-r1/TME/SAP
/usr/local/Tivoli/bin/aix4-r1/TME/TEC/adapters/bin/SAP
+rm -rf /usr/local/Tivoli/bin/aix4-r1/TME/TEC/adapters/bin/SAP
/usr/local/Tivoli/bin/aix4-r1/TME/TEC/adapters/etc/SAP
+rm -rf /usr/local/Tivoli/bin/aix4-r1/TME/TEC/adapters/etc/SAP
/usr/local/Tivoli/bin/aix4-r1/../generic_unix/TME/SAP
+rm -rf /usr/local/Tivoli/bin/aix4-r1/../generic_unix/TME/SAP
/usr/local/Tivoli/bin/aix4-r1/../lcf_bundle/bin/generic_unix/TME/SAP
+rm -rf /usr/local/Tivoli/bin/aix4-r1/../lcf_bundle/bin/generic_unix/TME/SAP
/usr/local/Tivoli/bin/aix4-r1/../lcf_bundle/bin/aix4-r1/TME/SAP
+rm -rf /usr/local/Tivoli/bin/aix4-r1/../lcf_bundle/bin/aix4-r1/TME/SAP
/usr/local/Tivoli/bin/aix4-r1/../lcf_bundle/bin/hpux10/TME/SAP
+rm -rf /usr/local/Tivoli/bin/aix4-r1/../lcf_bundle/bin/hpux10/TME/SAP
/usr/local/Tivoli/bin/aix4-r1/../lcf_bundle/bin/solaris2/TME/SAP
+rm -rf /usr/local/Tivoli/bin/aix4-r1/../lcf_bundle/bin/solaris2/TME/SAP
/usr/local/Tivoli/bin/aix4-r1/../lcf_bundle/bin/w32-ix86/TME/SAP
+rm -rf /usr/local/Tivoli/bin/aix4-r1/../lcf_bundle/bin/w32-ix86/TME/SAP
87
---10.)DELETING YOUR SAP tag files at location

/usr/local/Tivoli/bin/aix4-r1/../lcf_bundle/.installed/
+rm -rf /usr/local/Tivoli/bin/aix4-r1/../lcf_bundle/.installed/*SAP*
---11.)DELETING YOUR Manager for R3 tag files at location
/usr/local/Tivoli/bin/aix4-r1/.installed/
+rm -rf /usr/local/Tivoli/bin/aix4-r1/.installed/*SAP*BIN
+rm -rf /usr/local/Tivoli/bin/aix4-r1/*SAP*BIN
/usr/local/Tivoli/bin/aix4-r1/../../lib/aix4-r1/.installed/
+rm -rf /usr/local/Tivoli/bin/aix4-r1/../../lib/aix4-r1/.installed/*SAP*LIB
+rm -rf /usr/local/Tivoli/bin/aix4-r1/../../lib/aix4-r1/*SAP*LIB
+rm -rf /usr/local/Tivoli/bin/aix4-r1/../../lib/aix4-r1/libSapInstance*
/usr/local/Tivoli/bin/aix4-r1/../generic_unix/.installed/
+rm -rf '/usr/local/Tivoli/bin/aix4-r1'/../generic_unix/.installed/*SAP*GBIN
+rm -rf '/usr/local/Tivoli/bin/aix4-r1'/../generic_unix/*SAP*GBIN
/var/spool/Tivoli/wwdn07.pok.ibm.com.db/.installed/
+rm -rf '/var/spool/Tivoli/wwdn07.pok.ibm.com.db'/.installed/*SAP*DB
+rm -rf '/var/spool/Tivoli/wwdn07.pok.ibm.com.db'/*SAP*DB
/usr/local/Tivoli/bin/aix4-r1/../../man/aix4-r1/.installed/
+rm -rf '/usr/local/Tivoli/bin/aix4-r1'/../../man/'aix4-r1'/.installed/*SAP*MAN
+rm -rf '/usr/local/Tivoli/bin/aix4-r1'/../../man/'aix4-r1'/*SAP*MAN
/usr/local/Tivoli/bin/aix4-r1/../../msg_cat/.installed/
+rm -rf '/usr/local/Tivoli/bin/aix4-r1'/../../msg_cat/.installed/*SAP*CAT
+rm -rf '/usr/local/Tivoli/bin/aix4-r1'/../../msg_cat/*SAP*CAT
---Your deinstall is now complete
For more information about the de-installation processes, please refer to the
appropriate R3 Manager manuals.
2.3.14 Delivery of ABAP program using J class

In an SAP R/3 systems environment, the Y and Z classes are reserved for
customers use. In the previous version of the R/3 Manager, the Z class is for
your own use. However, in Version 2.0 of the R/3 Manager, the J class (J8C1)
is for your own use.
The following are the function modules in the new J (J8C1) development
class:
J_8C1_ALERT_CONTROL
J_8C1_ALERT_READER
J_8C1_BUFFER_INFO
J_8C1_BUFFER_NAMES
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:
Distribute the R3 ABAP file package by using Tivoli Desktop.

Copy the transport files manually by using ftp to servers.
R/3 ABAP file package distribution is provided by Version 2.0 of R/3 Manager,
and it is useful if you have a large-scale SAP R/3 environment and a lot of
subscribers. In the case of using the R/3 ABAP file package distribution, you
do not need to copy the transport files one by one manually.
Once Version 2.0 of the R/3 Manager installation is completed successfully in
your TMR, the R3 Transport profile manager is created in the Manager for R3
policy region. In the R3 Transport profile manager, the R3 ABAP file package
has already been created. Then, you just need to define the subscribers and
distribute the file package to the appropriate targets. For more information
about importing R/3 transports, please refer to Chapter 4, Planning and
implementation on page 119.
2.3.15 New R/3 specific event sources

After configuring the TEC event console, you will find new event source group
icons called WR3MIB and WRSLOG. These two event source groups inform
you which event source generates the events efficiently. The following figure
(Figure 43) shows the icons of these new event sources.
89
Figure 43. New TEC event source icons
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.
2.4 Advanced knowledge of Tivoli Manager for R/3

In this section, we introduce some advanced knowledge and undocumented
information about Tivoli Manager for R/3. This information can be helpful
when using R/3 Manager or when performing problem resolution.
2.4.1 R/3 Manager Endpoint methods

As we mentioned, Tivoli Manager for R/3 supports TMA. To support TMA, the
R/3 Manager provides Endpoint methods as well as other Tivoli Management
Applications. These new Endpoint methods are managed by the dependency
90
manager. The following sections introduce the R/3 Manager methods,

dependency sets, and how it works in your R/3 management environment.
2.4.1.1 Endpoint Method Cache Management
The Endpoint method cache management is very important in understanding
the R/3 Manager implementation on TMA. The TMA gives you the Framework
functions that are necessary to perform management operations, such as
those performed by Tivoli Manager for R/3, and these management
operations are processed by calling a method on a managed resource. In the
TMA environment, this design has not changed: The TMA invokes an
Endpoint method for performing management operations on the TMA
platform.
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
Method Cache Synchronize

(wgateway gw_name dbcheck)
Endpoint Gateway
Method
Downcall
Endpoint
(SAP Server)
Endpoint Method Cache
Figure 44. Endpoint method cache management
By default, the Endpoint method cache exists under the

C:\Tivoli\lcf\dat\1\cache (for Windows NT) or /opt/Tivoli/lcf/dat/1/cache (for
UNIX) directory. The Endpoint Gateway stores the Endpoint methods under
the /usr/local/Tivoli/bin/lcf_bundle directory and also stores Endpoint method
information in the Endpoint Gateway database ($DBDIR/gwdb.bdb file). This
information can be synchronized with the information on the Endpoint
Manager ($DBDIR/imdb.bdb file) by using the wgateway gw_label dbcheck
command.
The following summary describes how the Endpoint manages the Endpoint
method cache.
Once the Endpoint method is stored in the Endpoint method cache, the
Endpoint uses it even if the system is rebooted.
92
Once the Endpoint method is downloaded to the Endpoint method cache,

the Endpoint does not download the same version of the Endpoint method.
If the Endpoint detects the available version is greater than the current
version of the Endpoint method, the Endpoint downloads the newer
method automatically.
When the Endpoint downloads the Endpoint method, the related methods
that are defined in the dependency set are also downloaded at the same
time. The dependency set is a list of other files, modules, or commands
that are required for the correct operation of the method.
2.4.1.2 Endpoint Method and R/3 Manager
Tivoli Manager for R/3 invokes methods by using upcalls and downcalls to
perform its management functions as well as other Tivoli Management
Applications. Which method will be used by the R/3 Manager? The
dependency manager handles the methods for each Tivoli Management
Application. The dependency manager exists as a class object in the Tivoli
object database and plays a very important role in implementing the LCF
architecture. We can understand the relationship between the Endpoint
method and R/3 Manager by checking the dependency manager.
2.4.1.3 Dependency Sets for R/3 Manager
Normally, the dependency set is added to the dependency manager when
installing the Tivoli Management Application (but it is not mandatory; it
depends on the application design).
When R/3 Manager is installed completely, and the R3AppServer object is

created, the following three dependency sets will be added into the
dependency manager:
sap_dep
sap_lib_dep
sap_tool_dep
You can see these dependency sets by using the wlookup command as
follows:
wlookup -ar DependencyMgr
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
1533820760.1.970 is the object ID of the sap_dep dependency set in our

environment. For example, in our environment, the following Endpoint
methods are defined in the sap_dep dependency set.
# wdepset -v 1533820760.1.970
w32-ix86:
bin/w32-ix86/TME/SAP/2.2C/wr3mib.exe,../../bin/w32-ix86/TME/SAP/2.2C,8
bin/w32-ix86/TME/SAP/2.2C/tecad_wr3mib.exe,../../bin/w32-ix86/TME/SAP/2.2C,8
bin/w32-ix86/TME/SAP/2.2C/tecad_wr3mib.conf,../../bin/w32-ix86/TME/SAP/2.2C,8
bin/w32-ix86/TME/SAP/2.2C/wr3slog.exe,../../bin/w32-ix86/TME/SAP/2.2C,8
bin/w32-ix86/TME/SAP/2.2C/tecad_wr3slog.conf,../../bin/w32-ix86/TME/SAP/2.2C,8
bin/w32-ix86/TME/SAP/2.2C/tecad_wr3slog.cl,../../bin/w32-ix86/TME/SAP/2.2C,8
bin/w32-ix86/TME/SAP/2.2C/wr3rfc.exe,../../bin/w32-ix86/TME/SAP/2.2C,8
bin/w32-ix86/TME/SAP/2.2C/wbindmsg.exe,../../bin/w32-ix86/TME/SAP/2.2C,8
bin/w32-ix86/tools/bash.exe,%TOOLS%,8
bin/w32-ix86/tools/sh.exe,%TOOLS%,8
bin/w32-ix86/tools/echo.exe,%TOOLS%,8
bin/w32-ix86/tools/expr.exe,%TOOLS%,8
bin/w32-ix86/tools/win32gnu.dll,%TOOLS%,8
bin/w32-ix86/tools/sed.exe,%TOOLS%,8
bin/w32-ix86/tools/tr.exe,%TOOLS%,8
hpux10:
bin/hpux10/TME/SAP/2.2C/wr3mib,../../bin/hpux10/TME/SAP/2.2C,8
bin/hpux10/TME/SAP/2.2C/tecad_wr3mib,../../bin/hpux10/TME/SAP/2.2C,8
bin/hpux10/TME/SAP/2.2C/tecad_wr3mib.conf,../../bin/hpux10/TME/SAP/2.2C,8
bin/hpux10/TME/SAP/2.2C/wr3slog,../../bin/hpux10/TME/SAP/2.2C,8
bin/hpux10/TME/SAP/2.2C/tecad_wr3slog.conf,../../bin/hpux10/TME/SAP/2.2C,8
bin/hpux10/TME/SAP/2.2C/tecad_wr3slog.cl,../../bin/hpux10/TME/SAP/2.2C,8
bin/hpux10/TME/SAP/2.2C/wr3rfc,../../bin/hpux10/TME/SAP/2.2C,8
bin/hpux10/TME/SAP/2.2C/wbindmsg,../../bin/hpux10/TME/SAP/2.2C,8
solaris2:
bin/solaris2/TME/SAP/2.2C/wr3mib,../../bin/solaris2/TME/SAP/2.2C,8
bin/solaris2/TME/SAP/2.2C/tecad_wr3mib,../../bin/solaris2/TME/SAP/2.2C,8
bin/solaris2/TME/SAP/2.2C/tecad_wr3mib.conf,../../bin/solaris2/TME/SAP/2.2C,8
bin/solaris2/TME/SAP/2.2C/wr3slog,../../bin/solaris2/TME/SAP/2.2C,8
bin/solaris2/TME/SAP/2.2C/tecad_wr3slog.conf,../../bin/solaris2/TME/SAP/2.2C,8
bin/solaris2/TME/SAP/2.2C/tecad_wr3slog.cl,../../bin/solaris2/TME/SAP/2.2C,8
bin/solaris2/TME/SAP/2.2C/wr3rfc,../../bin/solaris2/TME/SAP/2.2C,8
bin/solaris2/TME/SAP/2.2C/wbindmsg,../../bin/solaris2/TME/SAP/2.2C,8
aix4-r1:
bin/aix4-r1/TME/SAP/2.2C/wr3mib,../../bin/aix4-r1/TME/SAP/2.2C,8
bin/aix4-r1/TME/SAP/2.2C/tecad_wr3mib,../../bin/aix4-r1/TME/SAP/2.2C,8
bin/aix4-r1/TME/SAP/2.2C/tecad_wr3mib.conf,../../bin/aix4-r1/TME/SAP/2.2C,8
bin/aix4-r1/TME/SAP/2.2C/wr3slog,../../bin/aix4-r1/TME/SAP/2.2C,8
bin/aix4-r1/TME/SAP/2.2C/tecad_wr3slog.conf,../../bin/aix4-r1/TME/SAP/2.2C,8
bin/aix4-r1/TME/SAP/2.2C/tecad_wr3slog.cl,../../bin/aix4-r1/TME/SAP/2.2C,8
bin/aix4-r1/TME/SAP/2.2C/wr3rfc,../../bin/aix4-r1/TME/SAP/2.2C,8
bin/aix4-r1/TME/SAP/2.2C/wbindmsg,../../bin/aix4-r1/TME/SAP/2.2C,8
generic:
bin/generic_unix/TME/SAP/sh/sap_common.sh,../../bin/generic_unix/TME/SAP/sh,8
bin/generic_unix/TME/SAP/sh/sap_adapter_common.sh,../../bin/generic_unix/TME/SAP/sh,8
bin/generic_unix/TME/SAP/2.2C/sh/sap_start.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8
bin/generic_unix/TME/SAP/2.2C/sh/sap_start_db.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,
8
bin/generic_unix/TME/SAP/2.2C/sh/sap_start_dbaccess.sh,../../bin/generic_unix/TME/SAP/2.
2C/sh,8
bin/generic_unix/TME/SAP/2.2C/sh/sap_start_sapgui.sh,../../bin/generic_unix/TME/SAP/2.2C
/sh,8
bin/generic_unix/TME/SAP/2.2C/sh/sap_start_server.sh,../../bin/generic_unix/TME/SAP/2.2C
/sh,8
bin/generic_unix/TME/SAP/2.2C/sh/sap_start_adapter.sh,../../bin/generic_unix/TME/SAP/2.2
C/sh,8
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#
R/3 Configuration Task
EP Gateway
1
Discover/Define
/usr/local/Tivoli/bin/lcf_bundle
Download
SAP Server (Endpoint)
Method Cache
Figure 45. R/3 Manager Endpoint methods handling
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
3. The R/3 Configuration Task that is executed on the Endpoint is completed

and discovers and defines the SAP application server on the Endpoint.
Endpoint methods are highly flexible. The software installation process is
unnecessary for an Endpoint because an Endpoint downloads the newest
methods automatically. This means the software upgrade process is also
unnecessary for an Endpoint.
Note
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
Tivoli Manager for R/3 supports Tivoli Management Agent (TMA).

Therefore, when you push a R/3 monitor to Endpoint subscribers, you have
to use the dataless profile manager. It is the same as all other Tivoli
Management Applications.
97
What is the Difference between Dataless and Classic?

As you know, the TMA does not have an object database (.bdb file) locally;
the information in the profile created in the dataless profile manager is not
written to the database associated with the next level even if it is a full
Managed Node (refer to Figure 46). Therefore, if you distribute the profile by
using the dataless profile manager to full Managed Nodes or Endpoints, the
data is applied directly to the system.
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
Classic Profile Manager
Dataless Profile Manager
Local Modification
Object Database
Managed Node
Managed Node
Object Database
Figure 46. The Difference between dataless and classic profile manager
The dataless profile manager is developed for supporting Endpoint

subscribers. However, almost all features, except writing information to the
database, are the same as the classic profile manager, for example, defining
the profile, handling the profile, and so on.
98
2.4.2 R/3 Manager object

Tivoli manages each managed resource as an object, and these objects are
stored in Tivoli object databases (.bdb files). Tivoli also provides Tivoli Name
Registry (TNR), which is a quick lookup table of object labels and object IDs.
All Tivoli Management Applications that are running on Tivoli Management
Framework should use these objects, and each resource can be referred from
an application or program by using an object label or ID. Version 2.0 of R/3
Manager is also one of the Tivoli Management Applications that is running on
the Tivoli Framework. Therefore, R/3 Manager adds some new objects into
the Tivoli object databases. In this section, we introduce an overview of the
Tivoli object and R/3 Manager.
2.4.2.1 New Resource Types for R/3 Manager
When you install and configure R/3 Manager properly, the following new
resource types are added into the Tivoli object databases:
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
# wlookup -ar R3System

is1n05_PD9
1533820760.1.1183#R3::R3System#
wwdn07_IG3
1533820760.1.1156#R3::R3System#
#
2.4.2.2 Attribute of New R/3 Manager Resource

Each object instance of the R/3 Manager resource has attributes as well as
other Tivoli objects. You can check the attributes of each object instance by
using the objcall command as follows.
# objcall 1533820760.1.1183 contents

ATTRIBUTE:ABH_ObjectVersion
ATTRIBUTE:_BOA_id
ATTRIBUTE:app_context
ATTRIBUTE:class_objid
ATTRIBUTE:classes
ATTRIBUTE:collections
ATTRIBUTE:databases
ATTRIBUTE:disable_engineUpdate
ATTRIBUTE:disable_run_task
ATTRIBUTE:disable_system
ATTRIBUTE:endpoint_oid
ATTRIBUTE:label
ATTRIBUTE:last_failed
ATTRIBUTE:members
ATTRIBUTE:pres_object
ATTRIBUTE:pro
ATTRIBUTE:pro_name
ATTRIBUTE:profile_push_order
ATTRIBUTE:push_trans_commit_behavior
ATTRIBUTE:resource_host
ATTRIBUTE:skeleton
ATTRIBUTE:sort_name
ATTRIBUTE:state
ATTRIBUTE:subscriptions
ATTRIBUTE:system_timeout
#
Some of these attribute values cannot be displayed or modified by Tivoli high

level commands. If you need to display or modify an attribute for some
reason, use the idlattr or idlcall command. In this section, we introduce
how to refer to an attribute of R3 System resource object.
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 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
to refer to the system_timeout attribute value of an R3 System object by using

the idlattr command.
# idlattr -tg 1533820760.1.1183 system_timeout long

300
#
You also can use the idlcall command to display the system_timeout
attribute value as follows.
# idlcall 1533820760.10.23 _get_system_timeout

300#
As you can see, by default, the system_timeout attribute is set to 300

seconds.
101
Note
The system_timeout attribute is used by objects related to the R/3

Manager, for example, R3Stsrem, R3AppServer, and R3DBServer. You
have probably experienced a problem in a large-scale environment with
hanging distributions; wherein, the failure of a single Endpoint keeps the
overall distribution from proceeding. Even if the process only hangs on one
of the targets (R/3 object), the overall distribution process never returns. To
avoid this situation, the system_timeout is provided. The system_timeout
sets a client-level timeout value for all requests to the R/3 objects.
On the other hand, the session_timeout is provided by the Endpoint
Gateway and specifies the timeout value for the connection between the
Endpoint Gateway and its Endpoints. During the data transfer from the
Endpoint Gateway to the Endpoint, if the Endpoint stops receiving the data
for a period longer than the value set by the session_timeout parameter,
the Endpoint Gateway terminates the distribution to that Endpoint and
records the timeout error.
The timeout mechanism between the Endpoint Gateway and its Endpoints
is very flexible. You do not need to configure the session_timeout each time
you modify the system_timeout of R/3 objects. The system_timeout
attribute setting overrides the session_timeout setting if the
system_timeout is modified. The session_timeout and system_timeout are
set to 300 seconds by default.
The session_timeout affects each application that runs on the Endpoint
and issues a downcall, for example, Inventory and Software Distribution. In
other words, the session_timeout value is the timeout for a downcall.
Moreover, the session_timeout affects all Endpoints that are managed by
the Endpoint Gateway. Therefore, you do not need to configure the
session_timeout value for each session between the Endpoint Gateway
and Endpoint.
If you need to modify the session_timeout value for some reason, you can
modify this value by using the wgateway command as follows:
wgateway <gw_label> set_session_timeout value
In this part of the section, we introduced an example of an R3 System

resource type. However, you can use the same method to explore the Tivoli
object databases and find other objects related to R/3 Manager.
102
2.4.3 Tivoli Application Proxy internals

To understand R/3 Manager TMA support, understanding the behavior of
Tivoli Application Proxy is very important. Tivoli Application Proxy plays a vital
role in supporting TMA. We introduced the overview of Application Proxy at
the beginning of this chapter; so, this section introduces detailed information
about Application Proxy.
2.4.3.1 How Application Proxy Works
In R/3 Manager configurations, the Application Proxy must be installed on the
TMR server, on the TEC server, and on each Managed Node that runs an R/3
application server or on the Endpoint Gateway if the R/3 application server
runs on an Endpoint (TMA).
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 Appl Server

R/3 Objects
APPLPROXY
Object DB
R/3 Objects
APPLPROXY
Object DB
Managed Node
Endpoint Gateway
R/3 Appl Server
Endpoint
Figure 47. Application Proxy and Tivoli Object Database
Application Proxy provides functionality in the following main areas:

Application Proxy provides an IDL interface to help build new classes.
103
Application Proxy provides an upcall collector and command line programs

to assist in the initial creation and configuration of objects from a task
running on TMA.
Application Proxy provides a simple execution mechanism for running
script on TMA.
The IDL interface plays a vital role in these functions. The IDL interface allows
the R/3 object on a Managed Node to redirect, or proxy, operations that need
to execute on a TMA node.
2.4.3.2 The list of context variables
Application Proxy is used to maintain a list of context variables in the form of
Name=Value. This context is added to the environment for all tasks and
Sentry monitors that run on the TMA node.
The context variables are stored as a StringList attribute called app_context

on each R/3 object. You can refer to these context variables by using the
idlattr or idlcall command as follows.
idlattr -t -g <OID> app_context TMF_Types::StringList
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.
# wlookup -ar R3System

is1n05_PD9
1533820760.1.1183#R3System#
wwdn07_IG3
1533820760.1.1156#R3System#
# idlcall 1533820760.1.1183 _get_app_context
{ 11 "ABH_DBHostName=is1n05" "ABH_R3SID=PD9" "ABH_R3Release=31H" "ABH_DBType=DB6"
"ABH_SystemLabel=is1n05_PD9" "ABH_IRONAME=usn.pokibmxtmrb20.iga" "ABH_Client=" "ABH_Use
ABH_Passwd=" "ABH_Language=" "ABH_DBRelease=" }#
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
2.4.3.3 Future plan of Application Proxy

Application Proxy is developed to support TMA. Application Proxy could be
thought of as code shared between the Tivoli Manager series products
because several functions that would be useful for all the Tivoli Manager
series products can be shared.
Other Tivoli Manager series products will, in the near future, support TMA by
using Application Proxy.
105
106
Chapter 3. Our SAP R/3 System environment

Our environment was created to reflect the problems faced when
commencing a large scale implementation of Tivoli solutions in an SAP R/3
landscape.
Although our environment was not actually large, the results can be
reproduced depending on whether you have ten or one thousand systems.
The theories and practices discovered and explained in this book can be
applied regardless of organization size.
All of the people who co-authored this book have been involved in large
implementations of Tivoli or SAP R/3, and in some cases, both. Therefore, all
are familiar with the problems faced when implementing an effective
monitoring solution for SAP R/3.
This chapter introduces and explains our environment, paying close attention
to the hardware and applications involved. This includes full descriptions of
the system configurations, database configurations, and the Tivoli products
used in this environment.
3.1 Overview of our environment

The following figure illustrates the overall layout of our environment and the
machines involved. This figure only gives a brief overview of the environment.
Each component will be discussed in depth further on in this chapter.
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
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
Figure 48. Overview of our environment
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
Managers, Event Servers and Administrators. The specifications of the

machine were as follows:
Uni Processor
320 Mb RAM
22 Gig HD space
The products installed on POKIBMXTMRB20 were as follows:
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 Manager for R/3, Version 2.0
Tivoli Software Installation Service 3.6
Tivoli Distributed Monitoring 3.6
Tivoli Distributed Monitoring TEC Monitors 3.6
Tivoli Distributed Monitoring TME Monitors 3.6
Tivoli Distributed Monitoring Universal Monitors 3.6
Tivoli Distributed Monitoring Unix Monitors 3.6
Our SAP R/3 System environment
109
Patches Installed on POKIBMXTMRB20

Distributed Monitoring ARM Agent 3.6.1 Maintenance Release
Distributed Monitoring ARM Monitors 3.6.1 Maintenance Release
Distributed Monitoring ARM EndPoint 3.6.1 Maintenance Release
Tivoli Software Distribution Patch 3.6.1-COU-0002
Tivoli Software Distribution Gateway Patch 3.6.1-COU-0003
Tivoli Distributed Monitoring Patch 3.6.1-DMN-0008
TME 10 Distributed Monitoring 3.6.1 Maintenance Release
Tivoli Enterprise Console Patch 3.6.1-TEC-0002 (ACF)
Tivoli Framework Patch 3.6.1-TMF-0004 (build 04/13)
Tivoli Framework Version 3.6.1 Patch 3.6.1-TMF-0029 (build 06/24)
TME 10 Enterprise Console Adapter Configuration Facility 3.6.1
TME 10 Software Distribution Upgrade, Version 3.6 to 3.6.1
TME 10 Software Distribution Gateway, Upgrade Version 3.6 to 3.6.1
Tivoli Framework Version 3.6 patch 3.6-TMF-0034 (3.6 - build 01/24)
Tivoli Management Framework Patch 3.6-TMF-0048 (3.6 - build 03/23)
Tivoli Management Framework 3.6.1 Maintenance Release (build 02/12)
TME 10 Distributed Monitoring TEC Monitors 3.6.1
Tivoli Distributed Monitoring TME Monitors Patch 3.6.1-DMN-0013
Tivoli Distributed Monitoring Universal Monitors Patch 3.6.1-DMN-0013
Tivoli Distributed Monitoring Unix Monitors Patch 3.6.1-DMN-0013
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 GEM Event Enablement 2.2.1
110

Tivoli Enterprise Console EIF 3.6
Tivoli Enterprise Console Event Console 3.6
Tivoli Enterprise Console Server 3.6
Patches Installed on POKIBMXTECB20
TME 10 Enterprise Console Server 3.6.1
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:
Dual Pentium Pro 200 Mhz

288 Mb RAM
7 Gig HD space
111
The software installed on this machine are as follows:

Tivoli GEM Topology Console 2.2.1
Tivoli GEM Topology Server 2.2.1
Patches Installed on POKIBMGEM
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:

Sybase Adaptive Server Enterprise 11.9.2
Tivoli Software Installation Service 3.6
Tivoli Manager for Application Performance Monitor Component
version 1.0
Tivoli Manager for Application Performance Server Component
Tivoli Distributed Monitoring TME Monitors 3.6
Patches Installed on POKIBMTAPM
Tivoli Software Installation Service 3.6.1 Patch (3.6.1-SIS-0001)
TME 10 Software Installation Service upgrade to 3.6.1
TME 10 Distributed Monitoring TME Monitors 3.6.1
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
113
Patches Installed on POKIBMXEGWB21

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:
114

Patches Installed on POKIBMXEGWB22
3.2 Overview of our SAP R/3 environment

Regardless of how many machines an environment has, the problems and
challenges encountered in implementing a robust and controllable
management solution are the same. Therefore, the fact that our SAP R/3
environment only had two SAP application servers was not a problem. Both
machines were IBM System Parallel (SP) nodes, one thin and one wide node.
They were both the database and application server in a single machine and
had no direct connection between them. What follows is a brief description of
the hardware and software of these two machines.
IS1N05
This was the wide node of the two. The hardware configuration was as
follows:
Uni processor
512 Mb RAM
49 Gig HD space
The following list provides the nodes software configuration:
AIX 4.2.1
115
SAP R/3 3.0F

DB2 2.1.2
MQSeries 5.0
Patches Installed on IS1N05
TME 10 Distributed Monitoring Universal Monitors 3.6.1
TME 10 Distributed Monitoring Unix Monitors 3.6.1
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
117
Patches Installed on WWDN07

TME 10 Distributed Monitoring Universal Monitors 3.6.1
TME 10 Distributed Monitoring Unix Monitors 3.6.1
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
Chapter 4. Planning and implementation

In this chapter, we describe how to set up the environment in which we
manage our SAP R/3 installation, that is, the installation and configuration of
the SAP R/3 system itself as well as the necessary Tivoli Enterprise
components.
We describe in detail how to set up the SAP R/3 systems and Version 2.0 of
Tivoli Manager for R/3. For other R/3 system management products
information, such as Global Enterprise Manager or Tivoli Application
Performance Manager, please refer to the Chapter 7, Examples of new
features in SAP R/3 Management on page 271.
Note
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
4.1 Overview and objective

The environment is implemented to reflect a typical business design, that is,
more than one SAP R/3 system per TMR with the possibility to have SAPGUI
clients inside or outside TMR. We performed the following steps to set up our
environment:
Installing Version 2.0 of Tivoli Manager for R/3
Configuring SAP R/3 for use with Version 2.0 of Tivoli Manager for R/3
Configuring Version 2.0 of Tivoli Manager for R/3
Configuring Tivoli Enterprise Console
Configuring the R/3 client using Version 2.0 of Tivoli Manager for R/3
For information on installing the dependent platform for Tivoli Manager for
R/3, such as Tivoli Management Framework, Tivoli Enterprise Console, Tivoli
Software Distribution, and Tivoli Distributed Monitoring, refer to the
appropriate product manuals or documents.
119
4.2 Installation planning

As we mentioned before, there are many dependencies or prerequisites for
Tivoli Manager for R/3 products, and each dependent or prerequisite product
also has some prerequisites or patches that should be installed properly.
Before installing Version 2.0 of Tivoli Manager for R/3, you must look into
these prerequisites including patches.
Normally, the latest patches should be applied to your TMR. To obtain the
latest patch information and download a patch, the following Web site can be
a information source:
http://www.support.tivoli.com
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
4.2.1 Installation Summary

The following table (Table 7) shows the installation summary in our
environment. You can also refer to Chapter 3, Our SAP R/3 System
environment on page 107 for more information about our systems
environment.
Table 7. Installation Summary
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
R/3 Appl Proxy

V1.1
TMA1
SAP
3.0F
TMA2
SAP4.0
B
4.3 Installing and configuring Tivoli Manager for R/3

In this section, we explain in detail how to prepare the R/3 systems and how
to install and configure Tivoli Manager for R/3.
Planning and implementation
121
4.3.1 Installing Tivoli Manager for R/3

In Version 2.0 of Tivoli Manager for R/3 configurations, you need to install the
Tivoli Application Proxy before you install Version 2.0 of R/3 Manager. We
explain Application Proxy installation first, then we explain Version 2.0 of R/3
Manager installation and configurations.
4.3.1.1 Installing Tivoli Application Proxy
Tivoli Application Proxy must be installed on the TMR server, the TEC server,
each Managed Node that runs an R/3 application server, and on the Endpoint
Gateway if the application server runs on a TMA Endpoint.
Note
The following patch is available for Tivoli Application Proxy and it is

contained on Version 2.0 of Tivoli Manager for R/3 CD-ROM.
Tivoli Application Proxy Patch 1.1-APX-0001
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
122
Figure 49. Installing Application Proxy
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
Optionally, if the database server is not running on the same machine as an

R/3 application server, install the Manager for R/3 on database server as well.
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.
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 Install Product window, select the Tivoli Manager for R/3,
Version 2.0, entry from the Select Product to Install section as shown in
Figure 50. Also select the clients on which the code must be installed.
Remember that clients are the TMR server, the TEC server, each
Gateway if the application server runs on a TMA Endpoint. Optionally,
install the Manager for R/3 on the database server as well if an application
server is not running on the same machine.
124
Figure 50. Installing Tivoli Manager for R/3
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
Figure 51. New Manager for R3 icon on the desktop
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
Figure 52. Policy region: Manager for R3
The policy region, R3 Configuration, contains three task libraries: R3

Configuration Tasks, R3 Internal Tasks, and R3 List Maintenance Tasks. The
R3 Configuration Tasks library provides the product-wide configuration tasks
(refer to Figure 53).
Figure 53. R/3 Configuration task libraries
127
4.3.2 Configuring Tivoli Manager for R/3

After installing the code on appropriate the TMR server, TEC server, each
Gateway if the application server runs on a TMA Endpoint, some
configuration must be performed before customizing and using the product.
The configuration consists of the following steps:
1. Configuring each R/3 system
Creating an SAP user
Moving the transports
Importing the function modules
Configuring a RFC user
Configuring an R/3 system for alerts
2. Configuring the Tivoli Manager for R/3 for each R/3 system
Configuring Tivoli roles
Creating R/3 system
Creating R/3 application server
Creating R/3 database server
Creating R/3 objects with Automatic Discovery
Configuring the RFC
Configure the environment
3. Configuring event handling
Configuring an TEC event server
Configuring the TEC event console
Configuring the Event Adapter
The following sections will explain each configuration step highlighting points.
We advise here for the reader to have the users guide and the release notes
of Tivoli Manager for R/3 at hand for further complementary investigation.
4.3.3 Configuring each SAP R/3 System

Some actions have to be performed on each R/3 system in order to allow
Tivoli to interact and communicate with the SAP systems. These actions
should be performed by the SAP administrators of the different systems, but
128
we document them here briefly in order to allow a Tivoli administrator with

only basic SAP knowledge to perform them.
The following steps must be repeated for each R/3 system that is to be
managed.
4.3.3.1 Creating an SAP User
In the case that you do not already have an SAP user who has the authority
to create a development class, you have to create one. The default SAP users
SAP* and DDIC do not have this authority. We recommend creating a new
user named TIVOLI (for example) who is a copy of the SAP* user. This dialog
user could be used later by the Tivoli administrator for other actions, such as
checking the import or configuring other R/3-related Tivoli products (Tivoli
Workload Scheduler, for example).
Note
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
/usr/sap/trans/data and /usr/sap/trans/cofiles, respectively. The cofiles files

contain the configuration parameters for the transport, and the data file
contains the real data that is imported.
If the application server is on TMA, the product is not resident on the TMA
application server machine. You cannot just copy from one directory to
another. You have to perform an ftp from another machine to the TMA
application server machine. The transport profile manager removes the need
of ftp.
Distributing the R/3 ABAP File Package
Version 2.0 of Manager for R/3 provides a new function that distributes the
R/3 ABAP file package to the appropriate R/3 application directories. It is
useful when you have a large environment containing a number of application
servers. You can create a profile manager that contains several application
servers with same SID, and you can distribute a file package to the profile
manager in one application. Therefore, you do not have to copy the transport
files to each application server one by one.
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
Figure 54. R3 Profile Manager: R3 Transports
To distribute the R/3 ABAP file package, follow these steps:

From the Manager for R3 policy region, open the R3 Transports profile
manager.
First, you must change the profile managers mode into a dataless profile
manager if your application server is at TMA.
From the R3 Transports Profile Manager window, select Edit -> Profile
Manager... then the Edit Profile Manager window shows up.
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.
Figure 55. Change to the dataless profile
Define the subscriber. From the R3 Transports Profile Managers window,

select Profile Manager -> Subscriber... Then, the Subscribers window
shows up. Choose the appropriate Managed Node or TMA Endpoints as
subscriber.
When you finish with the selection, click the Set Subscription and Close
button to complete.
Edit the file package properties. Right click on the R3 ABAP FilePackage
icon and select properties. The File Package Properties window shows
up.
From the File Package Properties window, choose the appropriate
platform. For UNIX, select Edit -> Platform-Specific Options -> Unix
Options... (Figure 56). Then File Package Properties shows up.
132
Figure 56. Edit File Package properties
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
Figure 57. Unix Package Unix options
Finally, distribute the transports. In the Profile Manager: R3 Transports

window, right-click the R3 ABAP FilePackage icon and select
Distribute... to display the Distribute File Package window.
Complete the window with the appropriate subscriber or other setting and
distribute the file package.
You need to define tsidadm and tsid. Be sure that the files are owned by
tsidadm, and tsid is the system ID of the target R/3 system. You need to
create different file packages if you are going to distribute to different R/3
systems.
4.3.3.3 Importing the Function Modules
First check if the transport system is already configured and functioning. Go
to the /use/sap/trans/bin directory and verify the existence and content of the
TPPARAM file there (configuration file for transports). If the file is missing, the
transport system is probably not yet configured (newly installed R/3 system).
Locate the sample configuration file, copy it to /usr/sap/trans/bin, rename it to
TPPARAM, and adapt the content.
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
wwdn07:ig3adm 6> tp showbuffer IG3

This is tp version 252.08.05 (release 40B) for DB2commonserver database
IG3 buffer:
BD1K900989|has
BD1K901024|has
BD1K900770|has
PD9K900680|has
BD1K901036|has
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
SAPK001LDE|has already been imported completely
TV1K900057|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.
wwdn07:ig3adm 7> tp addtobuffer TV1K900187 IG3

Addtobuffer successful for TV1K900187
meaning:
Everything OK
Note
In our example, we specified the transport number 187. However, please

refer to the latest Release Notes for the transport numbers.
Verify that it is now in the buffer by entering tp showbuffer <SID>.
135
wwdn07:ig3adm 8> tp showbuffer IG3

IG3 buffer:
BD1K900989|has
BD1K901024|has
BD1K900770|has
PD9K900680|has
BD1K901036|has
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 |
|
|
SAPK001LDE|has already been imported completely
IG3K900105|has already been imported completely
TV1K900187|
4 |
4 |
1 |
|
|
| 10 |
|
8 |
|
that makes 3 transports to be imported.
meaning:
Everything OK
Import the function modules by entering tp import TV1K900187 IG3. If you

need to put in the unconditional mode, the u4 option is only specified for
the R/3 release prior to 4.0A, and for 4.0B, only u1 and u2 are used.
wwdn07:ig3adm 9> tp import TV1K900187

This is tp version 252.08.05 (release
This is R3trans version 6.03 (release
R3trans finished (0004).
sapparam(1c): No Profile used.
This is R3trans version 6.03 (release
R3trans finished (0004).
meaning:
A tool used by tp produced warnings
wwdn07:ig3adm 10>
IG3
40B) for DB2commonserver database
40B - 08.05.98 - 13:03:12).
40B - 08.05.98 - 13:03:12).
Note
In our example, we specified the transport number 187. However, please

refer to the latest Release Notes for the transport numbers.
If needed, you can also check the import log files in the directory
/usr/sap/trans/log.
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.
Figure 58. Checking the development class J8C1
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
Figure 59. Checking active table structure
4.3.3.4 Creating a RFC User

We have chosen to create a new user for the RFC interface access in order to
have a CPIC-only user for this with the minimal set of authorizations.
Therefore, to create the user, log on to the R/3 system via the SAPGUI
(dialog user).
Via a SAPGUI, log on to the system as TIVOLI (or SAP*).

Issue the su01 transaction.
Enter TME10 (for example) in the User field and click on the Create icon.
Enter Tivoli RFC user in the Last name field of the Address folder.
Change from Dialog to CPIC in the Logon data folder and enter a
password.
In the Profiles folder, add the S_A.ADMIN authorization profile.
Save your entries and log off.
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.
Figure 60. User list at SAPGUI
4.3.3.5 Configuring an R/3 System for Alerts

R/3 alerts are transmitted to the Tivoli Manager for R/3 via the R/3 SysMan
interface. These alerts are accessed by the SysMan from the R/3 shared
memory segments. The alerts are contained in the segment with key 13.
Segment key 13 must be allocated in shared memory pool 10 for the alerts to
be accessible through the SysMan. This is the default allocation for R/3. You
can check the allocation of segment key 13 by examining the R/3 application
server instance profile. The instance profile can be displayed and maintained
via transaction rz10. The parameter ipc/shm_psize_13 controls the pool
allocation for segment key 13. This parameter must have a value of -10 to
ensure that it is allocated to shared memory pool 10. This is shown in Figure
61.
139
Figure 61. Display R/3 instance profile
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
Figure 62. Assigning the new TMR roles
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
Figure 63. Create R/3 system from desktop
4.3.4.3 Creating R/3 Application Server

To create an R/3 application server object, follow these steps:
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.
R/3 application server in the R/3 system policy region.
142
Figure 64. Create R/3 application server from desktop
4.3.4.4 Creating R/3 Database Server

To create an R/3 database server object, follow these steps:
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.
R/3 database server in the R/3 system policy region.
143
Figure 65. Create R/3 database server from desktop
4.3.4.5 Creating R/3 object with Automatic Discovery

As introduced as a new function of Version 2.0 of Tivoli Manager for R/3,
Automatic Discovery is used to configure R/3 objects automatically.
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.
Figure 66. Configure Autodiscovery for UNIX
4.3.4.6 Configuring the RFC

The Tivoli Manager for R/3 users RFC to log on to each R/3 managed system
in order to run some tasks and monitors. For this access, it uses the
previously defined RFC user. This user is defined here to the Tivoli Manager
for R/3 though the following task. The corresponding script is located on the
TMR server, and it is named sap_config_rfc.sh.
145
Figure 67. Task Library: R3 Configuration tasks
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
Figure 68. Configure remote function call
Click the Set and Execute button.

Verify in the task status window that you received no errors (Figure 69).
Figure 69. Configure remote function call output
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
J_8C1_BUFFER_NAMES is one of the parameter files that is used by the

called function modules previously imported in the R/3 system.
The result of this command execution (in this case, from the TMR server) is
shown in the following output.
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.
Processing the configuration file.

Processing the cmd file.
Reading the following lines from J_8C1_BUFFER_NAMES.TXT:
COMMAND OPTIONS:
MODULE = J_8C1_BUFFER_NAMES
IMPORT TABLE:
TABLENAME = BUFFERNAMES
NAME = BUFFERNAME
TYPE = TYPC
LENGTH = 5
FILE = stdout
Overriding cfg and cmd file options with command line options.
user
= tme10
client
= 100
language
= E
destination
= IG3
hostname
= wwdn07.pok.ibm.com
sysnr
= 00
Mallocing space required for import parameters.
Preparing to open connection to SAP.
RFC OPTIONS:
destination
connopt
client
user
language
trace
mode
connopt_r3only address
hostname
sysnr
Opening a connection to
Connection successfully
=
=
=
=
=
=
IG3
2003e970
100
tme10
E
0
= RFC_MODE_R3ONLY
= 2003e970
= wwdn07.pok.ibm.com
= 0
SAP.
opened.
Calling the SAP Module J_8C1_BUFFER_NAMES with the following parameters.

Exporting:
Importing:
RFC Call completed.
Listening for RFC Call to complete

Getting the response from SAP.
TTAB
FTAB
SNTAB
IRBD
TABL
TABLP
PXA
CUA
PRES
CALE
wr3rfc complete!
4.3.4.7 Configuring the environment

If your database is running on Windows NT, and if you plan to use the
start/stop database facility of the Tivoli Manager for R/3, you must create two
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
Example of a Stop Exit Routine for an Oracle Database

The following is an example of a stop exit routine for an Oracle database.
#!/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
Figure 70. Tivoli Manager for R3 configuration
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.
4.3.5 Configuring event handling

The Manager for R/3 provides new event classes and rule sets so that you
can view and work with R/3 events at your Tivoli Enterprise Console (TEC). In
order to do so, you must configure the TEC event server, the TEC event
console, and the TEC event adapters. We explain these configurations in the
following section.
151
4.3.5.1 Configuring TEC

Tivoli Manager for R/3 will monitor the R/3 systems through event adapters
running on each application server and a set of Tivoli Distributed Monitoring
monitors distributed to each application and database server (remote
monitors) and to the TMR server (central monitors). The TEC server will
receive events directly from the adapters and from the Tivoli Distributed
Monitoring engines. In order to handle them, new events classes and rules
must be imported into TEC. The following job will import them, thus, creating
a new rule base or extending an already existing one. The script
corresponding to the job that will be used here is located on the TMR server,
and it is named sap_eventserver_config.sh.
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:
Double-click the Configure Event Server job.
152
Figure 71. Task Library: R3 configuration tasks (for Event Server)
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
Figure 72. Configure Event server
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.
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
4.3.5.2 Configuring an Event Console

An event group or an event source consists of a filter on all events contained
in the TEC database. This step creates an event group for each R/3 system
that is to be managed in order to see the events per SAP system. It also
creates an event source for adapter events (WR3MIB or WR3SLOG checked
in the dialog box). The script corresponding to the job that will be used here is
located on the TMR server in $BINDIR/../generic_unix/TME/SAP/2.2C/sh,
and it is named sap_tec_config.sh. Repeat the following procedure for each
R/3 system.
The following steps must be repeated for each R/3 system that is to be
managed.
Figure 73. Task Library: R3 Configuration tasks (for Event Console)
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.
Figure 74. Configure event console

Verify in the task status window that you receive no error (Figure 75).
156
Figure 75. Configure Event console output
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
Figure 76. TME 10 Event server configuration (Event Group)
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
Figure 77. Tivoli Enterprise Console (for Event Source)
4.3.5.3 Configuring Event Adapter

We need to configure the alert event adapter and the syslog event adapter for
each application server. After configuration, each application server can
process R/3 information and generate it into the TEC events. The script
corresponding to the task that will be used here is located on the TMR server,
and it is called sap_config_adapter.sh.
159
Figure 78. Task Library: R3 Configuration Tasks (for Event Adapter)
To configure the event adapter, run the Configure Event Adapter task in the
R3 Configuration task library (Figure 78) and follow these steps:
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
Figure 79. Configure Event Adapter
Verify in the task status window that you received no errors (refer to Figure
80).
161
Figure 80. WR3MIB and WR3SLOG Event on TEC console
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
Chapter 5. Managing SAP R/3 environment

In this chapter, we describe in detail how to use the management
environment for SAP R/3 that we have set up in the Chapter 4, Planning and
implementation on page 119. We also explain and provide background
information on how the management products communicate with the SAP R/3
system and how to use the information provided by CCMS.
For R/3 system management products information, such as Global Enterprise
Manager or Tivoli Application Performance Manager, please refer to the
Chapter 7, Examples of new features in SAP R/3 Management on page 271.
Note
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
5.1 Version 2.0 of Tivoli Manager for R/3

In this section, we explore the different management functions provided by
Version 2.0 of Tivoli Manager for R/3 including:
Using R/3 delivered tasks to manage the SAP R/3 systems
Deploying the SAPGUI using Tivoli Software Distribution
Monitoring SAP R/3 systems using TEC adapters
Monitoring SAP R/3 systems using Distributed Monitoring
5.1.1 SAP R/3 System Management tasks and jobs

In this section, we explain how to control the R/3 environment using Tivoli
tasks, for example, how to take actions on your R/3 system, such as starting
and stopping the system, application servers, database servers, clients, and
monitors, and how to show some performance information of the application
server.
To control your R/3 environment using Tivoli tasks, start by opening the
Manager for R3 policy region from the Tivoli Desktop, which brings you to the
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.
Figure 81. Task Library: R3 App Server Tasks Collection
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
Figure 82. Display Batch Jobs Execute Task Window
Choose an application server as the Task Endpoint to run this task. After
completing, click Execute & Dismiss to start the task.
Managing SAP R/3 environment
165
Figure 83. Display Batch Jobs Window
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
Figure 84. Display Batch Jobs Output Window
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.
Figure 85. Task Library: R3 DB Server Tasks Collection
5.1.2 SAPGUI distribution

In this section, we are going to use the second functionality of Tivoli Manager
for R/3, which is automatic deployment of R/3 SAPGUI clients. In order to
complete the configuration of our environment, we deploy SAPGUI to one of
our workstations in an environment. An R/3 client is a UNIX, Windows 95,
Windows 98 or Windows NT machine running the SAP R/3 presentation
graphical user interface (SAPGUI) code. Once this code is installed on the
target machine, a configuration is needed to define a specific SAPGUI for a
specific R/3 application server. This configuration is a part of the SAP R/3
installation, which we are not going to cover here. For information about it,
refer to the R/3 manuals. Two phases are required to correctly set up a client.
The first one consists of building a file package that contains the R/3 SAPGUI
code and which will be distributed to all the clients. The second phase is the
process of distributing this file package, launched by using Tivoli Software
Distribution. To configure such a file package, two methods are available. The
configuration can be done using either a reference installation or an R/3
native installation. You can create various file packages with different options
and configurations. Each file package is identified by the name you specify
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
Figure 86. Edit Job for a Reference Installation
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
Figure 87. Settings for the Jobs execution
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
Figure 88. Result of the Job Execution
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
5.1.2.2 Configuring a R/3 Client Using a Native R/3 Installation

This method assumes that the R/3 SAPGUI CD-ROM image is available on
the target machine. This image can be the CD-ROM itself, inserted in a target
machine, or a mount of it on all the other target machines. Via this method,
the code is installed directly on the targets from the CD-ROM image using
R/3 install tools and procedures.
Compared to the reference installation method, the R/3 native installation

method avoids copying the SAPGUI code to the TMR server. The second
advantage of such a method is the fully automatic icon customizing for the
SAPGUI on the target machines. First of all, be sure that the SAPGUI
CD-ROM image is available on the target machines. Then, you have to
configure the task that will extract the code from the image and put it into a
Tivoli Software Distribution file package, ready to be distributed to other
machines, whatever the platform of the targets is because the Tivoli Manager
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.
Figure 90. Edit Job for a Native Installation
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.
Figure 91. Native Installation Job Settings
The Configuration Name you 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 fields must be filled in as
explained below. We give the settings only for mandatory fields. For the
optional fields, refer to the R/3 manuals (or the R/3 online help CD-ROM) for
information.
SAPGUI version: Indicates the level of SAPGUI being installed on the
target. For us, we have selected the 4.0B version.
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
Figure 92. Result of the Job Execution
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
5.1.2.3 Distributing Client Software

The file package created during the reference installation and the R/3 native
installation of the R/3 SAPGUI clients, as described in the former sections,
must be distributed to the target machines. Target machines must be defined
as subscribers of the appropriate profile managers according to the type of
installation (reference installation or R/3 native installation) and the platform
of the clients (UNIX, Windows NT, or Windows 95). For clients defined as
Managed Nodes or PC Managed Nodes, you have to subscribe them to the
profile managers and then distribute the profile to these new subscribers. We
assume that the reader is familiar with Tivoli Software Distribution. For
detailed information about Tivoli Software Distribution, refer to the redbooks
New Features in Tivoli Software Distribution 3.6, SG24-2045 and TME 10
Deployment Cookbook: Courier and Friends, SG24-4976.
For clients defined as TMAs (Tivoli Management Agents), you need to

change the profile manager to a dataless profile manager. To do this, edit the
178
profile manager you wish to use and check the Dataless Endpoint Mode as
shown in Figure 94.
Figure 94. Change to Dataless Profile Manager
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
Figure 95. Cloning Profile into Dataless Profile Manager
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
Figure 96. Distributing the SAPGUI Client File Package
For both methods, a reference installation or an R/3 native installation is

used. Once the distribution is completed, the R/3 SAPGUI code is installed on
the client machine, and the SAPGUI icon for the appropriate R/3 system has
automatically been created during the installation because the installation
was performed directly from the CD-ROM image. So, as the sapsetup
program was automatically run with the right parameters, the Start menu of
the PC client has been updated to provide direct access to the R/3 server
indicated during the jobs configuration. An example can be seen of the
desktop of a Windows NT SAPGUI client in Figure 97. From this menu, you
can create other SAPGUI icons for accessing other R/3 servers by clicking on
the SAPicon menu.
181
Figure 97. Example of SAPGUI Access on a Windows NT Client
182
5.2 Log files for troubleshooting

The following table (Table 8) shows the log files that are useful for problem
determination and troubleshooting.
Table 8. Log Files for Troubleshooting
Type
Name
Location
Tasks
name.log: Where name

represents a file name that
includes the name of the task
producing the output.
Example:
wwdn07_IG3_sap_display_buffe
r_info_.log
UNIX: /tmp
Windows NT Managed Node:
$DBDIR/tmp
Windows NT Endpoint:
$LCF_DATDIR/tmp
Monitors
name.log: Where name

represents a file name that
includes the name of the monitor.
Monitor trace must be on.
Example:
wwdn07_IG3_sapsystem_monit
or_.log
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
profile.log: Where profile is the

name of the file package profile.
Managed Node:
$BINDIR/../generic_unix/TME/S
AP/fp/profilemgr, where
profilemgr is the name of the
profile manager.
183
5.3 Monitoring functions of Tivoli Manager for R/3

The R/3 system has a general monitoring tool called Computer Center
Management System (CCMS). It contains a set of alert monitors that monitor
critical elements of the R/3 system and notify administrators of potential
problems. Starting with R/3 version 4, the CCMS offers a Multi-Systems and
Over-the-Landscape monitoring possibility, which is, of course, a big leap
compared to single application server monitoring prior to that version. An
illustration of this new CCMS function, transaction RZ20, is shown in Figure
98. You must click on each tree-leaf you want to see until you reach the
bottom leaf, which then has the threshold value. But you must have
customized this set of alerts first to get this tree-overview with all its
information. This kind of configuration must be done step by step for each
alert, for each threshold value, and for each host you want to include in your
monitoring set. A help window is available to explain all the icons that you
might get as shown in Figure 99.
Figure 98. CCMS Alert Overview (Customized) - Transaction RZ20
184
Figure 99. Explanation for the Alerts and Icons
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.
5.3.1 Alert Event Adapter

The Tivoli Manager for R/3 provides an alert event adapter for each
application server. The alert event adapter polls or queries periodically the
R/3 SysMan or MIB interface for new alert entries and forwards formatted
events to TEC. This is done by the r3mibIID program, where IID represents
the two-digit R/3 instance number. You can find a running process called
r3mibIID on each application server. The alert event adapter can generate
many events as listed in Appendix B, Event classes for Tivoli Manager for
R/3 on page 347. To minimize the number of events that are sent to TEC, you
can filter these events at the alert event adapter. To do this, add filter
statements to the r3mibIID.conf file. This file is created after you run the
Configure Event Adapter task and, therefore, exists only after you have run
this task at least once for the specific R/3 application server. The
r3mibIID.conf file is located in one of the following directories:
Managed Node
TMA Endpoint
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
$BINDIR/../generic_unix/TME/SAP/2.2C/sh or, in case the application server

is running on a TMA, in $LCF_BINDIR/../../generic_unix/TME/SAP/2.2C/sh.
SAP Application Server

TEC Event Server
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
Figure 100. Event Adapters and the Drill-Down Mechanism
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
sap_alert_reader.sh failed <error message>. The script also creates

automatically a log file residing in the /tmp directory (UNIX) or %DBDIR%\tmp
directory (Windows NT) of the application server. The log file is named
<AppServer>_<SID>_sap_alert_reader<IID>.log.
If an error occurs during the execution of the sap_alert_reader_cb.sh script,
an event of class AMS_WR3MIB_PROCESS_ALERT is sent to the TEC
stating sap_alert_reader_cb.sh failed <error message>. The script also
automatically creates a log file contained in the /tmp directory of the TEC
server. The log file is named sap_alert_reader_cb.log.
The following is an example of a drill-down process. The CUA buffer quality
has decreased below the defined level. CCMS will generate an alert on the
MIB notifying that some buffer is having a problem. The alert adapter reads
this alert and formats it into a TEC event of the SAP_ALERT_Buf event class
(see 5.3.6, TEC event classes and rules on page 219). Then it sends this
event to the TEC server. The convert_mib_to_internal_alert rule of the TEC
triggers on this generic event and launches a drill-down process. This rule
also drops the event. The drill-down will get the more detailed information
executing the Alert Reader task. This uses wr3rfc to read the internal alert
table of the SAP system, and then it determines which buffer is having a
problem and sends that message to the TEC server through an event of an
SAP_ALERT_BUFF_CUA class. The TEC server will forward it to the event
consoles.
5.3.2 Alert Control Process

This process can also be launched by rules that come with the Tivoli Manager
for R/3. For example, when an operator closes (on the TEC console) an event
corresponding to an internal alert, a change rule will trigger in order to reset
the corrupting alert in CCMS inside the R/3 system. The process is similar to
the drill-down: When one of these rules triggers, it executes a script named
sap_alert_control_cb.sh located in $BINDIR/TME/TEC/scripts. This script
runs on the TEC event server and launches a task with the application server
as task endpoint. The corresponding script that is run on the application
server is named sap_control_reader.sh and is located in
$BINDIR/../generic_unix/TME/SAP/2.2C/sh or, in case the application server
is running on a TMA, in $LCF_BINDIR/../../generic_unix/TME/SAP/2.2C/sh.
When executing, this script calls the wr3rfc program that logs on to the R/3
application server and runs the J_8C1_ALERT_CONTROL function module
imported in the SAP system during the Tivoli Manager for R/3 configuration.
The function module will reset or acknowledge the alert in CCMS.
188
If an error occurs during the execution of the sap_alert_control.sh script, an

event of class AMS_WR3MIB_PROCESS_ALERT is sent to the TEC stating
sap_alert_control.sh failed <error message>. The script also automatically
creates a log file residing in the /tmp (UNIX) or %DBDIR%\tmp directory
(Windows NT) of the application server. The log file is named
<AppServer>_<SID>_sap_alert_control_IID.log.
If an error occurs during the execution of the sap_alert_control_cb.sh script,
an event of the class AMS_WR3MIB_PROCESS_ALERT is sent to the TEC
stating sap_alert_control_cb.sh failed <error message>. The script also
automatically creates a log file contained in the /tmp directory of the TEC
server. The log file is named sap_alert_control_cb.log.
5.3.3 Syslog Adapter

The Syslog Event Adapter monitors the R/3 syslog file for new entries and
forwards formatted events to the Tivoli Enterprise Console (TEC). The Syslog
Event Adapter uses the same configuration values that were defined for the
Alert Event Adapter. In particular, the Syslog Event Adapter polls R/3 at the
polling interval and this polling interval can be different from the interval
configured for the Alert Event Adapter. To display and change the
configuration values for an Alert Event Adapter, run the Display Event
Adapter Configuration and Configure Event Adapter jobs, respectively. Refer
to 4.3.5, Configuring event handling on page 151 about these jobs.
Because the syslog event adapter obtains syslog messages through the R/3
remote function call (RFC) interface, 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 function. To configure the RFC logon
parameters, refer to 4.3.4.6, Configuring the RFC on page 145. The
Manager for R/3 provides tasks to start and stop the syslog event adapter that
can also be run from the pop-up menu on the application server icon.
The Manager for R/3 provides two configuration files for the syslog event
adapter: r3slogIID.cl and r3slogIID.conf, where IID represents the two-digit
R/3 instance number. These configuration files are created after you run the
Configure Event Adapter task and, therefore, exist only after you have run this
task at least once for the specific R/3 application server. The r3slogIID.cl and
the r3slogIID.conf configuration files are located in one of the following
directories:
Managed Node
TMA Endpoint
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
Is the three-character ID that identifies the syslog message.

The syslog message ID must be specified in upper-case
letters.
Severity
Specifies the event severity and is optional but must be

specified if an event class is specified. This value, if
specified, must be one of the following: 10, 20, 30, 40, 50, or
60. If no value is specified, the default is 30 (warning).
These values correspond to the following severity levels:
10 unknown
20 harmless
30 warning
40 minor
50 critical
60 fatal
Classname
190
Specifies the event class and is optional. If you do not

specify an event class, the default class is
SAP_SYSLOG_msgID, where msgID is the three-character
message ID. You must create a .baroc file and define the
event class similar to the event class definitions in the
tecad_wr3slog.baroc file in the
$BINDIR/../generic_unix/TME/SAP/baroc directory. The
recommended format for defining an event class is

SAP_SYSLOG_msgID.
The r3slogIID.conf file contains TEC event filter statements. By default, all
syslog events that are not specified in the r3slogIID.cl file are class
SAP_SYSLOG_MSG and are filtered out. Only those events that are
specified in the r3slogIID.cl configuration file are sent to the TEC. If you want
to see all syslog events, comment out the Filter statement in the
r3slogIID.conf file.
The following are the w3slogIID.cl and w3slogIID.conf file.
w3slogIID.cl file
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
;
Entries in this file are of the form

MsgID [Severity [ClassName] ]
where
MsgID is the three-character message id for the syslog message of interest
Severity is the numeric representation of the T/EC severity to assign to the generated event
10 "UNKNOWN"
20 "HARMLESS"
30 "WARNING"
40 "MINOR"
50 "CRITICAL"
60 "FATAL"
The severity may be left blank. In this case, it will default to WARNING.
ClassName is the T/EC class name to assign to the generated event. The class name may be left
blank (though only if severity is also left blank). In this case, it will default to
"SAP_SYSLOG_<msgId>" where <msgID> is the three-character message ID.
;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
If you change the tecad_wr3slog.cl file or the tecad_wr3slog.conf file, you

must stop and start the Syslog Event Adapter to incorporate the changes.
5.3.3.1 Examples of customizing Syslog Event Adapter
The new Syslog Event Adapter provides a valuable new way to monitor the
status of your R/3 systems and can be a key component of R/3 event
automation. The R/3 SYSLOG is a valuable source of information about the
the R/3 system because most activity within the R/3 system is reflected in
SYSLOG entries. R/3 administrators typically use the SYSLOG to diagnose
problems and to gain insights into the status and operation of the R/3 system.
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
Example 2: Customizing messages

ABAP programmers sometimes write messages to the SYSLOG to provide
status or diagnostic information about the work being done within that
program. The Syslog Adapter can capture these events and forward them on
to the TEC to aid in monitoring the workflow within the R/3 system. In this
case, the Basis Administrator has added a new syslog identifier to "Z01" to
R/3 (via transaction SE92), and the application has been modified to send
status messages using this "Z01" message class to the R/3 syslog. The
Syslog Adapter will also have to be configured to send "Z01" SYSLOG events
to TEC. An example of the changes to the application code is as follows:
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
EXPORTING
PRE_PARAM_LONG = 'ZSAPDEMO4 Processing 10000 records'
EXCEPTIONS
OTHER_PROBLEM
= 1.
"Simulated work
EXPORTING
PRE_PARAM_LONG = 'ZSAPDEMO4 Processing 20000 records'
EXCEPTIONS
OTHER_PROBLEM
= 1.
"Simulated work
EXPORTING
PRE_PARAM_LONG = 'ZSAPDEMO4 Processing Complete'
EXCEPTIONS
OTHER_PROBLEM
= 1.
5.3.4 Tivoli Distributed Monitoring

Besides getting alerts out of the SAP R/3 System using the event adapter, the
Tivoli Manager for R/3 provides a second way to collect information from
SAP: Tivoli Distributed Monitoring. The interaction between Tivoli Distributed
Monitoring and SAP R/3 works as shown in Figure 101. There are two kinds
of monitors available, the central monitors and the remote monitors. The
remote monitors, running on the SAP application servers, use two interfaces
to access the SAP system, the RFC (wr3rfc), and the MIB (wr3mib). The
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 Application S erver

TEC Event Server
SAP Instance
C CMS
Event Console
Rules Engine
Function
Modules
TMR Server
RFC
MIB
R/3 Manager
wr3rfc
R/3 Manager
wr3rfc
wr3mib
Central
Monitors
Rem ote Monitors
Figure 101. Tivoli Distributed Monitoring in an SAP R/3 System
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
The objective of the Server Central Monitors collection is to run the

monitors on a machine other than the application servers in order to avoid
the consecutive workload on the R/3 machines. But, as the load generated
by the monitors running on an application server is generally negligible
compared to the load generated by the SAP application itself, we
recommend that you use as often as possible the Server Remote Monitors
collection. Moreover, the events coming from central monitors will not
correlate with those coming from remote monitors. However, for database
monitoring and OS/390 monitoring, you must use the Server Central
Monitors collection, as this is the only one that provides this kind of
monitor.
Each time a central or remote monitor is running, the gathered SAP R/3
information is compared to the pre-defined threshold. If the current threshold
is exceeded, a pre-defined action is executed. Typically, an event will be
generated and sent to the TEC event server. Each monitoring source
contained in the monitoring collections has an associated event class. These
event classes are used when a forward an event to the TEC action was
specified as the action. The wr3rfc utility is the tool provided by the Tivoli
Manager for R/3, which communicates with SAP R/3 through the RFC
interface. As described in 4.3.3.4, Creating a RFC User on page 138, there
must be an RFC user defined and a transport job executed before the
communication can happen. This defined user is a CPIC (Common Program
Interface Communication) user, which means that this user can only access
the SAP R/3 system through the RFC. To prohibit unauthorized access to the
SAP R/3 system with this user, they have no authorization to log on using a
SAPGUI. The profile of this user only allows them to run the ABAP
programs/function modules with minimal a set of authorizations. The
transport job imports some function modules that will be executed to get
information from the CCMS. The wr3rfc program can be triggered from the
Tivoli Distributed Monitoring or by the drill-down. The necessary parameters
(for example, user ID, password, client) for the wr3rfc execution are stored in
the TMR database after the configuration step Configure Remote Function
Call. These parameters can also be entered in the wr3rfc_cfg file in the
directory $BINDIR/../generic_unix/TME/SAP/2.2C/rfc on the machine on
which wr3rfc runs. Note that on all platforms the file must be renamed to
.wr3rfc_cfg. This file is only used for troubleshooting the RFC access. The
last argument to wr3rfc is always the rfc_interface file, which contains the
function module to execute and the export/import parameters needed by this
function module.
197
Note
The import and export parameters stanzas of the rfc_interface file

correspond respectively to the export and import parameters of the
function module in the SAP system.
When triggering wr3rfc with an rfc_interface file as the argument, the
specified function module will execute inside the SAP R/3 with the specified
import parameters. The function module will end up by assigning the export
parameters to wr3rfc. The collected information is now available outside the
SAP R/3 system. Depending on which functionality the wr3rfc triggered, the
data will be directly sent to the TEC server (for a drill-down) or will be
compared to thresholds by the Tivoli Distributed Monitoring engine. In this
case, and if a threshold is crossed, the pre-defined consecutive action will be
taken. The following function modules are provided by the Tivoli Manager for
R/3:
J_8C1_ALERT_CONTROL
J_8C1_ALERT_READER
J_8C1_BUFFER_INFO
J_8C1_BUFFER_NAMES
J_8C1_DISPLAY_BATCH
J_8C1_DISPLAY_PROCESS
J_8C1_MODIFY_JOB
J_8C1_MODIFY_PROCESS
J_8C1_PROC_MONITORS
J_8C1_OS_COLLECT
J_8C1_OS390_COLLECT
J_8C1_OS390_DB2
J_8C1_ROLL_PAGE_SIZES
The corresponding rfc_interface files have the same name and are located in
the $BINDIR/../generic_unix/TME/SAP/2.2C/rfc directory of the Managed
Node where the Tivoli Manager for R/3 is installed or, in case of the TMA
Endpoint, on $LCF_BINDIR/../../generic_unix/TME/SAP/2.2C/rfc. Except for
the first two, these function modules are all used by the Tivoli Distributed
Monitoring monitors.
198
5.3.5 Default monitoring

The purpose of this section is to show and explain the default monitoring
capability provided by the Tivoli Manager for R/3, which is based on the Tivoli
Distributed Monitoring concept. Information contained in this section will give
the SAP administrator a view of the capabilities and an understanding of the
monitoring of the R/3 system by the Tivoli Manager for R/3. The configuration
of the Tivoli Manager for R/3, to enable the monitoring functions on one R/3
system, results in an indicator collection, three profile managers, two new
monitoring collections, and two subscription lists. Remember that the
<SAPhost>_<SID> is an alias for one R/3 system. This set of profile
managers and subscription lists is created in the Manger for R3 policy region
in order to monitor separately the three components of an R/3 system. The
two monitoring collections provide a set of specific new monitors that allow
the management of an R/3 system. Monitoring collections are explained in
detail in 5.3.5.2, Monitoring Collections on page 202. Each profile manager
contains a Tivoli Distributed Monitoring profile, in which are added some
predefined monitors in order to provide, by default, a basic monitoring
capability immediately after the initial configuration of the Tivoli Manager for
R/3. These monitors are created, by default, among the list of monitors
provided by the two new monitoring collections. Profile managers and Tivoli
Distributed Monitoring profiles are described in the next section: 5.3.5.1,
Default Profile Managers, Subscription Lists, Profiles on page 199, and the
full list of the available monitors is given in 5.3.5.5, Monitoring Sources
Available from Monitoring Collections on page 217.
5.3.5.1 Default Profile Managers, Subscription Lists, Profiles
For the R/3 System policy region, each profile manager (created by default by
the Tivoli Manager for R/3) contains a Tivoli Distributed Monitoring profile.
There are three different profile managers per R/3 system sub-policy region:
R3 DB Server Monitors, R3 App Server Monitors, and R3 Managed Node
Monitors. And depending on the monitoring method you want to use, there
are two possibilities: Remote monitoring and Central monitoring. The
hierarchy provided by the Tivoli Manager for R/3 is illustrated in Figure 102.
Shown there are all the components created in the Manager for R3 Policy
Region. Then it goes down to the R3 System sub-policy region and then the
R3 App Server profile manager with its monitoring profiles and the
subscription lists. Notice that the R/3 Systems and the profile managers are
on the same region. Also notice that the profile managers and the profiles
contain no SID-specific information, which is really showing us the new
architecture of this Manager for R/3.
199
Manager for R3
R/3 System
sub-policy region
R3_Indicators
Indicator Collection
Profile Manager
R3 DB Server Monitors
R3 App Server Monitors
R3 Managed Node Monitors
Profile
R3 Server Autodiscovery Monitors
R3 Server Remote Monitors
R3 Server Central Monitors
Default subscriber for

Central Monitors
Subscription Lists
App Server List
TMR Server
Figure 102. Default Profile Managers, Subscription Lists and Profiles
The three default profile managers are:

R3 App Server Monitors Profile Manager
The R3 App Server Monitors profile manager contains the following
application server profile:
R3 Server Remote Monitors

R3 Server Autodiscovery Monitors
R3 Server Central Monitors
R3 Server Remote Monitors Profile
200
The R3 Server Remote

Monitors profile contains
monitors for buffer quality
for each of the different
buffers, maximum percent
used for roll and page
areas, R/3 response time
for different user
processes, and application

server status.
R3 Server Autodiscovery Monitors Profile
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
The R3 Server Central

Monitors profile enables
you to use monitors from
the R3 Server Central
Monitors and Distributed
Monitoring collections.
This profile is empty, and
the only valid subscriber is
the TMR server.
Monitoring of remote
machines is performed
from the TMR by
distributing the profile to
this subscriber.The reason
is that, as the TMR server
has the Tivoli Manager for
R/3 installed, it can run the
wr3rfc program to execute
the monitors remotely and
then work as a proxy in the
Central monitoring
process.
201
R3 DB Server Monitors Profile Manager

The R3 DB Server Monitors profile manager contains the R3 DB Server
Central Monitors profile.
R3 DB Server Central Monitors Profile
The R3 DB Server Central

Monitors profile enables
you to use monitors from
the Server Central
monitoring collection, in
particular, the monitors for
OS/390 and for the
database server. This
profile is empty, and the
only valid subscriber is the
TMR server. Monitoring of
remote machines is
performed from the TMR
by distributing the profile
to this subscriber.
R3 Managed Node Monitors Profile Manager

The R3 Managed Nodes Monitors profile manager does not contain any
default profiles and is provided so you can create monitor profiles from
Distributed Monitoring collections. The default subscriber is the TMR server.
Subscribe the appropriate Managed Nodes to this profile manager. Please
refer to the Framework 3.6 User's Guide, GC31-8433 for more information
about creating a profile from a profile manager.
5.3.5.2 Monitoring Collections
Thanks to these two monitoring collections, you get a wide set of internal and
external R/3 monitors, not only for the monitoring of the R/3 application itself,
but also for the operating system it runs on and the database. Monitors are
contained in the R3 Server Remote Monitors monitoring collection and in the
R3 Server Central Monitors monitoring collection. These two monitoring
collections are available for each R/3 system you will manage in your TMR.
The monitoring collections are run against R/3 application servers only. For
R/3 database servers, you have to use monitors provided by the monitoring
collections in the Tivoli database management products, for example, the
Tivoli Manager for Oracle. The following figure shows the two monitoring
collections added by the configuration of the Tivoli Manager for R/3 system.
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
Figure 104. The Default R3 App Server Profile Manager
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
Figure 105. Predefined R3 Server Autodiscovery Monitors
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
Figure 106. Predefined R3 Server Remote Monitors
The R3 Server Central Monitors profile contains, by default, no pre-defined

monitors. Also, the other two profile managers do not have pre-defined
monitors in their profile. For the R3 DB Central Monitors profile, you can use
the monitors for OS/390, for example, and for the database server as well.
This could be using one of the Tivoli module for RDBMS, for example, the
Tivoli Manager for DB2 or Oracle.
5.3.5.4 Distribution of Monitoring Profile
Once you have enabled the default monitors you want to see in your TEC
Event Console, or by creating new monitors on a new profile, you need to
distribute this profile to the subscribers you have defined. This is done by
selecting the profile in the profile manager and selecting the subscribers you
want to distribute to. Then select Profile Manager from the menu bar and
Distribute... from the pull-down menu as shown in Figure 107.
207
Figure 107. Distributing Monitoring Profile
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
Figure 108. Starting Alert Adapter
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
Figure 109. TEC Event Console
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
Figure 110. Modifying a Default Monitor
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
Figure 111. Profile Properties to Add a New Monitor
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
Figure 112. Creating New Monitor
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
Figure 113. Creating New Monitor: Edit Monitor
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
Figure 114. Select Indicator Collection
You can simply choose the default R3 Indicators, or you can create another
one if you want (refer to Figure 115).
215
Figure 115. Indicator Collection List
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
Figure 116. Work Process Monitor Event on TEC
5.3.5.5 Monitoring Sources Available from Monitoring Collections

The purpose of this section is to show what the Tivoli Manager for R/3 can
monitor on a SAP R/3 system using Tivoli Distributed Monitoring monitors,
coming from the two monitoring collections provided by the module. Tivoli
Manager for R/3 provides 24 monitoring sources that monitor the R/3
application itself, the operating system the R/3 application runs on, and the
database. For the R/3 application, the module offers the capability to monitor
the memory allocations, such as the different R/3 buffers, the space
allocations, such as the pages, the response time performance, and the
availability of a SAP system. There are also several new monitoring sources
in this new version of R/3 Manager, such as: work process, long running
process, and cancelled job. For the operating system, monitoring sources are
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
Server Remote Collection
Server Central Collection
Roll Area
Page Area
Work Process
Work Process Dispatch

Queues
Long Running Process
CUA Menu and Text

Buffer
PRES Screen and

Dynpro Buffer
TTAB Table Description

Buffer
FTAB Field Catalog

Buffer
SNTAB Short NameTab

Buffer
IRBD Initial Records

Buffer
TABL Generic Key

Buffer
TABLP Single Key

Buffer
PXA Program Buffer
Monitor Sources
Server Remote Collection
Server Central Collection
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
5.3.6 TEC event classes and rules

In SAP R/3 monitoring, each event will be processed by using TEC event
classes and TEC rules. In this chapter, we introduce these TEC event classes
and rules as related to SAP R/3 monitoring.
5.3.6.1 TEC Event Classes and Event Sources
During the configuration of the TEC event server for the Tivoli Manager for
R/3, new event classes defined in three baroc files are imported in the new or
extended rule base:
sap_tecad.baroc
Defines event classes used by the alert

event adapter for R/3.
sap_server_monitor_35.baroc
Defines the event classes used by the

Tivoli Distributed Monitoring monitors for
R/3. The name of this file depends on the
version of Tivoli Distributed Monitoring
that is used; sap_server_monitor.baroc is
used for versions prior to 3.5.
tecad_wr3slog.baroc
Defines the event classes used by the

syslog event adapter for R/3.
219
These baroc files reside, by default, in the

$BINDIR/TME/TEC/<RuleBaseDir>/TEC_CLASSES directory of the TEC
server. Figure 117 shows the hierarchy of these event classes. A complete list
of the event classes of the super classes SAP_Internal_Alert,
SAP_MIB_Unique_Alert, SAP_MIB_Generic_Alert, and
SAP_Server_Monitors can be found in Appendix B, Event classes for Tivoli
Manager for R/3 on page 347.
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
Figure 117. Event Classes
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
There is no description for the event classes SAP_ALERT_GenP5 to

GENP14 because they map to R/3 Alert Classes that SAP has reserved for
future use but that are not used at the moment.
All the events previously described (directly sent by the adapter, resulting
from drill-down and resulting from reader or control routine error) are sent to
the TEC server with WR3MIB as the event source.
For reading the syslog, there is a separate r3slog adapter. All syslog alerts
detected by the adapter are forwarded to the TEC server with the
corresponding event class under SAP_SYSLOG_MSG. The event source for
this syslog event is WR3SLOG.
All alerts detected through the R/3 Remote or Central monitors are forwarded
by the Tivoli Distributed Monitoring engine to the TEC server with the
corresponding event class defined under SAP_Server_Monitors,
SAP_Status_Monitors, and SAP_Cancelled_Job_Monitors. The Batch,
Dialog, Spool, and Update Performance monitors mapping, respectively, to
the BATCH_SERVICE_MONITOR, DIALOG_SERVICE_MONITOR,
SPOOL_SERVICE_MONITOR, and UPDATE_SERVICE_MONITOR event
classes use wr3mib to get the information from the SAP system. The SAP
Availability monitor is now becoming one of the special event class:
APSRVR_STATUS_MONITOR (SAP_Status_Monitors class), and also uses
wr3mib. Events of the AMS_R3MONITOR_ALERT class are generated when
a Tivoli Manager for R/3 Distributed Monitoring monitor encounters an error.
All other R/3 monitors use wr3rfc. All the events described above (generated
through Tivoli Distributed Monitoring) are sent to the TEC server with
SENTRY as the Event Source.
5.3.6.2 TEC Rules
During the configuration of the TEC event server for the Tivoli Manager for
R/3, new rules defined in three rules set files are imported in the new or
extended rule base. The following are the overview of each rules set:
221
sap_tecad.rls
For rules acting on events arising from the event adapter

(events source = WR3MIB).
sap_monitor.rls
For rules acting on events generated from Tivoli

Distributed Monitoring (monitors for R/3, event source =
SENTRY).
sap_default.rls
For rules acting on events that need to be correlated

across these two different sources.
The sap_tecad.rls rule file provides the following functions:

1. Handling harmless events. Harmless events of a few select classes are
displayed for 60 seconds, then closed; internal harmless events are
closed immediately. There are three rules that support harmless
processing:
harmless_set_timer
drop_new_harmless
harmless_still_open
2. Check for and remove duplicate events. There is one rule that supports
duplicate event removal:
dup_sap_event
3. Performing drill-down processing. Drill-down is performed when
high-level generic events are received from the MIB. Drill-down goes
back into R/3 to get more detailed event information. In doing so, the
original event is dropped, and only the drill-down event is presented on
the TEC console (exception: No drill-down for harmless syslog events).
There is one rule that supports drill-down processing:
convert_mib_to_internal_alert
4. Coordinating TEC event acknowledgment/closure with R/3 alert
acknowledgment/closure. This ensures that event/alert states are
coordinated across the two environments. This makes Tivoli behave
more like SAP when dealing with SAP events. There are two rules that
support event coordination using alert control processing:
ack_sap_alert
close_sap_alert
5. Coordinate events with the R/3 application server in a way that, when
the application servers status changes from down to up, it will be going
out to get all existing alerts in that application server. This is done by
the rule:
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
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_event_on_statechange
Note
Please refer to Appendix D, TEC Rules and Events on page 373 for more
detailed information about TEC rules and events.
225
226
Chapter 6. SAP R/3 Management scenarios

In this chapter, we present a number of management scenarios. These
scenarios cover areas, such as Availability and Performance, to name but
two. What follows is a detailed section on each scenario. Each section deals
with the problems faced in that particular area, the Tivoli solutions that can be
used to build a robust and workable solution, and an explanation, or
suggestion, of how best to implement these solutions.
6.1 Tivoli SAP R/3 Management solutions

As stated previously in this book, Tivoli software is designed for the
management of a whole enterprise structure. Tivoli achieves this by providing
an array of products tailored to managing a specific part of the enterprise, but
which integrate to provide a single solution however they are used. More and
more products are being added to the Tivoli solutions as time moves on, and
new features are being added to the current solutions as they are constantly
developed and upgraded.
In todays world, organizations need a management solution capable of
managing everything in an enterprise, something capable of managing the
entire enterprise stack from network to application level. The following
diagram shows an example of the components that comprise an enterprise
stack.
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
Figure 118. An example of the enterprise stack
The problem with this vision of enterprise management is that it is not

integrated. Each level of the stack is managed using a different solution (an
island solution) and, therefore, different software. The gaps between the
levels means that problems that arise can be difficult to spot. For example, a
problem on the network level may cause an effect to the availability of the
application level. However, this can only be seen by examining both levels to
decide where the problem lies. If this was an integrated solution, then this
step would be unnecessary.
Tivoli products and solutions overcome this visibility problem by providing an
integrated solution for any organizations needs. Tivoli takes a different
approach to enterprise management, one that makes it easier to manage and
control enterprise resources. The following figure illustrates Tivolis model of
enterprise management. This gives some indication of how Tivoli products fit
into different solution designs.
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
Figure 119. Tivoli Enterprise Management Approach
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
SAP R/3 Management scenarios
229
to enable Tivoli to monitor and manage an enterprise. The final level

represents all the physical resources of the enterprise that Tivoli is designed
to monitor and control.
6.2 SAP R/3 Management scenarios

The management scenarios presented in the remainder of this chapter will
demonstrate some possible solutions of Tivoli products when applied to
different areas of an enterprise. The problems facing any organization that
wishes to use Tivoli products are how best to use them and which ones to
use. The following three management scenarios will be presented;
Operations
Availability and Performance
Security and Resources
Each scenario will include a explanation of the scope of the subject, a
detailed scenario description, a suggested software solution for that
particular scenario, suggestions on how and why to implement the chosen
software, and a scenario summary of the most salient points.
6.3 Operations scenario

This section focuses on the creation and implementation of a solution for daily
operations of the systems and applications within an organization.
6.3.1 What are operations?

Once a system is built and running correctly, the day-to-day management of it
is usually turned over to an Operations group of some description. Operations
is an important department in any large organization. They are the first line of
defence against system failure and, therefore, against revenue loss. For an
operations group to work efficiently, they need to have reliable and easy to
use tools. Operations can usually be split into several key sections. These are
as follows:
Network Monitoring and Problem Determination (PD)
Hardware Monitoring and PD
Operating System Monitoring and PD
Application Monitoring and PD
Batch Scheduling, Monitoring, and PD
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.
6.3.2 Detailed scenario

As listed previously, there are five main areas of operations. All of these need
to provide adequate monitoring and management to prevent problems from
being missed or not correctly addressed. The five sections can be expanded
on, and more, precisely defined as follows.
6.3.2.1 Network monitoring and problem determination
This means the monitoring of the devices that form the network infrastructure
of an organization. A network is not just a collection of cables connecting
machines, it also includes components, such as:
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.
Whether an organization is running mostly RS/6000s, AS/400s, or PC

Servers, they are all made up of a number of components that the machine
internally monitors during normal operations. The problem is that if an
organization has a lot of machines, it is impossible to check each one
individually. This means that centralized methods of problem alerting and
logging are required in order to manage the hardware correctly.
For example, if a server has a SCSI disk array and one fails, the operations
group needs to know about this. Ideally, they need to know which disk it was
and a probable reason for the failure. With this information, the correct
support personnel can be contacted to solve the problem or replace the disk.
However, if this kind of advanced alerting is not available, then a central
method of logon is required to allow quick access and PD procedures to be
carried out.
6.3.2.3 Operating System Monitoring and Problem Determination
Every server in an organization has some form of operating system installed
on it. This needs to be monitored, and where necessary, reconfigured or
tuned to meet the demands an application or users make of it.
At the operating system level, several things need to be monitored. The

following is a list of possible monitoring point; however, this will differ in length
and composition depending on the operating system:
File systems
Native Operating System Applications
Error Logs
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. Typical SAP R/3 Implementation
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
A batch monitoring solution needs to be able to show the following things:

Which job has failed.
Possible or actual cause of failure.
Any jobs that are dependent on this job.
Ideally, a good solution also needs to attempt some basic recovery actions
before reporting the failure of the job to the operations group. A good solution
needs to monitor the execution and progress of the schedule as well as the
individual jobs that make up that schedule.
Certain organizations use cross-platform batch schedules, for example, when
particular batch jobs on an SAP R/3 system complete they could transfer files
to an MVS system where processing continues. In this case, the organization
would also require a solution capable of monitoring and, more importantly,
understanding these cross-platform schedules.
If an organization has only one or two systems that actually run batch
schedules, then it is not really cost effective to implement an industry made
monitoring solution. Instead, it is easier and more efficient to monitor
manually. However, how many organizations in present times actually have
only one or two systems? The answer is not many. Most have several
systems that perform batch processing and require the constant attention of a
number of operators. Therefore, any monitoring solution needs to be able to
monitor multiple schedules on multiple systems and platforms as well.
The final part of the equation is that any monitoring solution must also provide
an easy to use interface, and screens and panels that enable an operator to
gain an overview of the situation with a glance.
6.3.3 Operations software solution

Having defined the roles and tasks faced by an operations department, this
section will suggest the Tivoli solutions that should be implemented to enable
the smooth and efficient running of an operations department. For the
purposes of this scenario, the following software should be implemented:
Tivoli Distributed Monitoring
Tivoli NetView
Tivoli Workload Scheduler
Tivoli Database Manager Products
236
6.3.4 Solution implementation

Having defined the Tivoli solutions to be used for this scenario, the next step
is to explain, or suggest, the best ways to implement them to provide an
effective operations monitoring solution. What follows is a product by product
description of how each piece of software would slot in to the overall solution.
6.3.4.1 Tivoli Distributed Monitoring
This is a core piece of the solution, as it enables the distribution of all the
monitoring profiles to all the servers within the organization. Distributed
Monitoring allows the monitoring of the hardware and operating systems
involved in any enterprise. System errors and events are forwarded to the
Tivoli Enterprise Console for the appropriate operator action. The explanation
for this piece of software is purposefully brief. It is merely included because
without it some of the other components of the solution would not function.
6.3.4.2 Tivoli NetView
This product performs a number of functions. Most importantly, it provides a
way of graphically modeling the environment. This includes both the servers
and the network components. NetView enables the servers and network state
to be reviewed at a glance. The icons representing servers and network
components change color depending on the status. This enables an operator
to quickly see problems as they arise. If NetViews Management Information
Base (MIB) Browser ability is configured correctly, this allows the operator to
quickly gain vast amounts of information about a system that has indicated a
problem without the need for logging onto it. NetView also provides a native
telnet option for access to UNIX servers at the operating system level.
Because NetView exclusively handles Simple Network Management Protocol
(SNMP) events and traps, it does limit its function as a tool for application
monitoring. This is because specific scripts have to be written and installed
on a local system in order for NetView to receive application alerts. These
alerts have to be correctly formatted locally before forwarding onto the
NetView focal point. However, this failing is a minor one, and when NetView is
combined with other Tivoli solutions, an insignificant one. NetView is
unsurpassed in its network management ability.
6.3.4.3 Tivoli Manager for R/3
This component is explained in much greater detail in Chapter 2, What is
new: Tivoli Manager for R/3 Version 2.0 on page 49. The benefits in an SAP
environment are enormous. Like all the other components, events can be
forwarded onto the Tivoli Enterprise Console. Because it also monitors the
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
The benefits of Tivoli Workload Scheduler to the stability and reliability of an

organizations batch processing are many. When configured correctly, it has
the ability to remove operator error from batch processing. Failed batch jobs
can no longer be accidentally overlooked, as they are alerted on when they
fail. This means that prompt corrective action can be taken. Multiple
schedules can be monitored and controlled at once. Jobs can be deleted and
added to schedules without the need to actually log onto SAP to do this. From
an operations point of view, Tivoli Workload Scheduler is a great asset and
gives peace of mind to both the operations department and organization
managers.
6.3.4.5 Tivoli Database Manager Products
As demonstrated in Figure 120 on page 234, there are two parts that
traditionally make up an SAP R/3 system. These are the SAP application
itself and the RDBMS that is used by the application. Like the SAP
application, the database also needs to be monitored for problems and errors.
When the number of SAP systems is small, this can be performed manually,
but even this monitoring is not performed in real-time and has to be requested
by the system administrator. Tivoli Database Management Products enable
the SAP R/3 application database to be monitored in real-time. When a
problem occurs, the Tivoli module detects this and issues an appropriate
alert. This means that problems can quickly be identified and solved. The
module enables the monitoring of databases logs, log archiving, tablespace
size and capacity, deadlocks, and conflicts, to name some of the features it
provides. Sometimes, when problems occur within the SAP application, it can
be traced to a problem in the database system and not the application itself.
The Tivoli Database Manager identifies a lot of these problems before they
become visible to users. This means that the problems can be caught quicker
and solved before they cause an interruption of service to the application.
6.3.4.6 Tivoli Enterprise Console
The Tivoli Enterprise Console is the product that brings all of the previously
described products together. It provides a single point where all the events,
problems, and information from the other products eventually end up. The
strength of the Tivoli Enterprise Console is that it is truly a focal point for the
whole enterprise. All the events in an enterprise are filtered by the individual
Tivoli products and then forwarded onto the Tivoli Enterprise Console. These
individual levels of filtering mean that if an alert actually reaches the Tivoli
Enterprise Console, then it should be genuine and not a false alarm.
6.3.4.7 Tivoli Global Enterprise Manager
The Tivoli Global Enterprise Manager enables all the different sections to be
viewed as a complete business system, whether this means the
239
representation of the components in a single system or all the systems in an

enterprise. The Global Enterprise Manager provides an easy to use and
effective GUI that operators can utilize to monitor and control the entire
enterprise. Coupled with the Tivoli Enterprise Console, the Global Enterprise
Manager can provide a single solution for an operations department.
Because of the way it displays system and component information, it helps
any operator understand how the systems work and interact. It also helps
remove the need for in-depth training in individual components, as the
differences between all of these are hidden from the operator by the Tivoli
products and solutions.
6.3.5 Scenario summary

Hopefully, this scenario has demonstrated how Tivoli solutions and products
can be employed to provide a robust and workable Operations monitoring and
PD solution. In any organization, Operations is the first line of defence
against system failure and revenue loss. Most organizations these days
employ some form of operations group to look after their systems. Therefore,
most organizations also have some form of Operations monitoring and PD
solution. Tivoli products enable the Operations solution in any company to be
combined with other solutions, for example the Help Desk, to provide an
integrated environment for the management of all systems. The installation of
an Operations solution can be the starting point for the integration of other
Tivoli products to enable the management of the whole enterprise.
6.4 Availability and performance scenario

Today, business applications are critical elements of practically every
business and organization. Determining whether these applications are
functioning properly is the single most important issue for systems
management. But applications management is not merely the application
itself; it consist all the components that make the applications run.
6.4.1 What is meant by availability and performance?

Because applications are at the core of your enterprise, their availability and
health are critical to every aspect of efficient operations. Because of this, the
question should be asked: How can you understand what exists in your
enterprise to efficiently and effectively keep applications updated and
available? In this context, availability and performance management is the
process of monitoring an application and its environment while the application
is running and automatically taking preventive or corrective actions.
240

As an example scenario, a result of monitoring implementation will be given in
this and the following sections. Prior to every implementation process, a lot of
requirement analysis should be done first to be able to collect all
requirements and to be able to define the scope of the implementation. This
can include, but is not limited to: Business process, systems management
process, and functional requirement. The output of these requirement
analysis should then be used as an input for the architecture and design
phase before entering the actual implementation phase.
In this scenario, a systems management infrastructure is built and
implemented that enables a Service Delivery organization to monitor and
control the following resources from one central point of control:
All SAP R/3 Systems
All SP2 and stand-alone RS/6000 systems running AIX
ADSM servers (backup and restore) and TMR servers
Lotus Notes servers running Windows NT
File and Print servers running Windows NT
Check of critical network components for problem determination
6.4.3 Availability and performance software solution

Ensuring the availability and the performance of your applications requires
that you have the ability to quickly and easily view and understand the health
of your enterprise. Depending on the systems management organization and
their need for certain functions, these software solutions should be
considered for the availability solution:
Tivoli Distributed Monitoring
Tivoli NetView
Tivoli Manager for R/3 and other application modules
Tivoli Database Manager Products
Tivoli Decision Support
241

For availability and performance management, the key process is monitoring.
Periodically checking an application and the infrastructure on which it
depends is a good way to detect problems as they occur or as they develop.
For monitoring purposes, the Tivoli Enterprise Console and the Tivoli
Distributed Monitoring are considered the base of the solution. Remember
that the R/3 Manager, if considered only by the event-sources, is adding the
Distributed Monitoring type and two TEC event adapter types of monitoring
collections.
In the monitoring process, just like a common communication process, there
are senders and collectors. Now consider all elements in your infrastructure
environment that could have generated TEC events from an event source, the
senders. Try to collect all of them and see how many events could have been
possibly generated from a specific event source. The result could be
interesting. An example of the amount of possible events out of some event
sources is as follows:
NT Event Log
More than 4,000 events.
SAP Syslog
More than 1,000 events.
AIX Error Report
More than 600 events.
Some Network Device
More than 300 events.
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
Element List: All Applications
Event Source
SAP R/3
DM (remote collections)
SAP R/3
r3mib
SAP R/3
ccms (v1.5), r3slog (v2.0)
SAP R/3
user-defined script
Notes Domino Server
notes_log
Notes Domino Server
event_reporter
Notes Domino Server
DM (notes domain remote)
Notes Domino Server
nt_event_log
MQ Series
mq_adapter
Element List: All Applications
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
ATM Campus Manager
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
Element List: Network Devices
Event Source
IBM 8224 Ethernet Hub
8224_snmp_MIB
IBM 8260 ATM Switch
8260_snmp_MIB
IBM 8265 ATM Switch
8265_snmp_MIB
IBM 8274 MP Switch
8274_snmp_MIB
Access routers
2503_snmp_MIB
3-com ethernet hub
fsms100_snmp_MIB
3-com switch-3000
3000_snmp_mib
3-com switch-1000
2000_snmp_MIB
Cisco router 2503
2503_snmp_MIB
The following table (Table 12) shows event sources related to other systems
and devices.
Table 12. Element List: All Systems
244
Element List: All Systems
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
3494 Tape Library and Magstar drives
errpt
snmp_MIB
adsm
Magstar Tape drive
nt_event_log
External Tape unit
errpt
Element List: All Systems
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
Netfinity Server Disks
nt_event_log
Internal Storage
nt_event_log
Internal Storage
errpt
SP Power Supply
SP_snmp_MIB
RS Power Supply
errpt
SSA Power Supply
errpt
Netfinity Server UPS
nt_event_log
Network Interfaces
DM (unix)
Security
logfile
Security
nt_event_log
WINS
nt_event_log
DHCP
nt_event_log
Oracle for TEC
DM (oracle)
Oracle for Inventory
DM (oracle)
Oracle for SAP
DM (oracle)
Oracle for SAP
ccms
Tivoli object database
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.
This method provides a step-by-step approach to prepare and configure the

Tivoli environment to receive, display, correlate, and perform actions on
filtered events from event sources as data is gathered in the EMD/MD
worksheets, an event relationships network including all the customization for
the agent adapters, a distributed manager, and TEC. The stages are as
follows:
Selecting, Integrating, and Customizing the Event Sources: Once an event
source is selected for integration and analysis into the framework, the
EMD/MD and implementation methods begin being executed in parallel.
The event source is integrated into the framework by installing and
configuring any required TEC adapters and modules. The event source is
also analyzed to determine the repertoire of events it is capable of
providing. This information is used to code the baroc class definitions
within TEC and is also used for the filtering analysis in EMD/MD. At this
point, the event source(s) is fully configured to send selective events up
through any respective distributed managers or directly to the TEC. The
TEC is receiving only events deemed to be enterprise significant based on
established policies.
246
Customizing the TEC rules (dup-detection, correlation, and automation):

The TEC rules writer uses a pre-defined rules template and rule logic
flowcharts to create a number of custom templates, one for each type of
event.
Outputs (Deliverable): Customized event adapters and event sources,
baroc class definitions implemented in TEC, and event rules for each
enterprise significant event (implemented in TEC).
6.4.4.2 The Next Steps
Basically, the method offers two ways to come towards the monitoring
solutions. The first one is filtering, which should be done at the event source
wherever possible. Then try to correlate the resulting events that will be sent
to the TEC that has different event consoles for different groups in the
organization. This is illustrated in the following figure.
Rules for
automatic actions
& filtering
systems
Helpdesk
Operations
network
events
applications
Level 2
Event Server
Level 3
Figure 121. Illustration of Event Management Design and Monitoring Design
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
Every five minutes
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
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
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
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
Every five minutes
Available swap
space
Threshold monitor
on UNIX swap
space:
<20 Mb WARNING
<10 Mb CRITICAL
>40 Mb
HARMLESS to
reset
N/A
Every five minutes
Available swap
space
Collect monitor on
UNIX swap space
N/A
Every hour
UNIX monitoring collection (specific monitoring).
Table 16. UNIX Monitoring Collection: Specific
Monitor
Description
Parameters
Timing
Daemon Status
on UNIX daemon
for ADSM:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Daemon:
dsmserv, dsmadmc
Every five minutes
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
for SP/2 CWS
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Daemons:
hardmon, hbd, hrd,
kerberos, sdrd,
splogd
Every five minutes
Daemon Status
for SP/2 nodes
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Daemon:
Fault_service_
Worm_RTG_SP
Every five minutes
251
Monitor
Description
Parameters
Timing
Daemon Status
for all SP/2 nodes
and CWS:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Daemons:
haemd, hagsd,
hagsglsmd, hatsd,
xntpd, sp_configd
Every five minutes
Daemon Status
for HACMP:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Daemons:
clstrmgr, clsmuxpd
Every five minutes
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
All TME servers in

the environment
are monitored from
the TMR server
Every 10 minutes
Remote Oserv
status
Threshold monitor
distributed to all
TME servers in the
environment:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
All servers in the

network local to the
TME server are
monitored by this
TME server.
Every 10 minutes
Monitor
Description
Parameters
Timing
Application status
Becomes
unavailable:
CRITICAL
(including a Sentry
notice)
Becomes available:
HARMLESS to
reset
Applications:
All oracle-daemons
Every 15 minutes
Application status
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
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
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
Logical Disk C: and

D:
Every 10 minutes
Percent Free
Space
Collect monitor on
Logical Disk
Logical Disk C: and

D:
Every hour
Monitor
Description
Parameters
Timing
NT Service Status
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
Every five minutes
Paging File Percent

Usage
Threshold monitor
on Windows-NT
paging file:
>80% WARNING
>90% CRITICAL
<60% HARMLESS
to reset
Paging file
C:\pagefile.sys
Every five minutes
Paging File Percent

Usage
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
Disk Queue Length
Collect monitor
Logical Disk C: and

D:
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
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
on Windows-NT
ADSM service on
ADSM servers:
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
Service:
ADSM Server
Every five minutes
NT Service Status
on Windows-NT
services on:
AccountBDCs
ResourceBDCs
Services:
KiXtart RPC
Service, Directory
Replicator
Every five minutes
Becomes
unavailable:
CRITICAL
Becomes available:
HARMLESS to
reset
256
Monitor
Description
Parameters
Timing
NT Service Status
on Windows/NT
services on:
AccountPDCs
ResourcePDCs
Services:
Spooler, Netfinity
Support Program,
Quota Manager
Every five minutes
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
Figure 122. Example of a Worksheet for Event Source: AIX errlog

The scenario that we introduced is based on the event management by using
Distributed Monitoring and the Tivoli Enterprise Console. The following is the
summary of this scenario for each Tivoli application.
258
6.4.5.1 Tivoli Distributed Monitoring

Distributed Monitoring allows remote system resources to be monitored. A
range of key measurements can be tested by using Tivoli Distributed
Monitoring including measurements from user-provided scripts. The result of
these measurements are tested against user-specified criteria. Based on the
results of the test, automation scripts can be invoked, operations notified, or
events forwarded to the Tivoli Enterprise Console. Control of all these
measurements and responses can be accomplished from a central console.
Distributed Monitoring may also be used to collect performance information
from remote systems. This information can then be read into a suitable
application to provide reports, graphs, and analysis of key system metrics.
6.4.5.2 Tivoli Enterprise Console
TEC provides an interface to the central event repository. A server portion
acts as the collection point for events within the enterprise, which includes
events generated by the distributed monitoring components. As events arrive
at the server, they are subjected to a rule based analysis to determine what
action, if any, should be taken. This action may, for example, include starting
an automated response, merging events due to a single failure, and basing an
action on a timed result. Events are stored in a RDBMS event repository. TEC
uses event adapters to reside on the local machine whose resources are
being monitored. Various (specialized) adapters are available for resources,
such as UNIX (including AIX), Windows NT, SAP, Lotus Notes, and log files
(for example, text files). A graphical user interface provides a view into the
event repository. The view can be customized for a user or group of users to
allow the current status of an enterprise to be viewed easily and efficiently.
6.5 Security and resource management scenario

This scenario deals with the creation and provision of a solution to enable the
efficient management of both security and resources within an organization.
6.5.1 What is meant by security and resources?

Many organizations today spend a considerable amount of time and money
worrying about security. Applications and, more importantly, data need to be
protected from unauthorized, and possibly illegal, access. However, what
organizations sometimes over look is that unauthorized access can come
from internal sources as well as external. There is concern about hackers
accessing data or systems, and to prevent this, complex security measures
are established to foil unauthorized external access. Meanwhile, internal
access is merely handled by the issuing the correct user IDs and passwords.
Sometimes, these User IDs are issued from different departments, each one
259
responsible for a particular section or application, or from a single

department, which is not fully aware of how the organization fits together.
Any organization today should implement security policies and procedures
that aim to control security enterprise wide, on all levels, from the network
through applications to the end user. Tivoli solutions goes a long way in
providing enterprise wide management of security and resources, or more
importantly, the security of resources.
In computing terms, an organizations resources include:
Hardware
Software
Data
All of these need be controlled and made secure in any organization. They
need to be allocated correctly, and access to them needs to be checked and
controlled at an enterprise level, not at a departmental level. This is difficult to
achieve in any organization; however, Tivoli provides a number of products
and solutions to make these necessary tasks easier and, most importantly,
centralized. When designing any solution, the goals and targets must be
defined in advance. This means that the resources to be controlled must be
identified while at the same time identifying the security measures each one
requires. This is paramount; otherwise, any solution will not work effectively,
and gaps and loopholes will be left, which can be exploited by internal and
external sources.

As stated in the previous section, an organizations resources can be divided
into three areas. Security in each of these areas needs to be addressed
enterprise wide. The following are detailed descriptions of each area and
some of the problems faced in each one.
6.5.2.1 Hardware
The computing hardware in an organization can be split into different groups
that can include both the computers themselves and the output devices and
peripherals associated with them. For example, the following components can
be counted as computing hardware:
260
Servers
RS/6000, OS/390, PC Servers
Workstations
Dumb Terminals, X Stations, Power PCs, PCs
Printers
All types and models
Security of an organizations hardware has to be physical, whether it involves

locking machines in secure rooms, securing workstations to the floor, or
inserting anti-theft devices, such as dye markers, into smaller components
and peripherals. Therefore, a software security and resource management
solution is not going to be of any use in actually preventing the theft of
hardware. However, if a security solution could prevent unauthorized access
to an organizations data after it was stolen, by means of encryption, for
example, then it does make a software security solution a viable deterrent
against the theft of hardware, at least in certain ways.
6.5.2.2 Software
Software resources can be anything from word processing applications, such
as Microsoft Word, right up to, and including, large ERP applications, such as
SAP R/3. Most organizations standardize their software solutions on
particular vendors, for example, Microsoft, where all e-mail, data processing,
database, and office solutions are based on Microsoft products. Alternatively,
an organization can choose to use SAP R/3 for much (if not all) of their data
processing and management needs. Usually, though, a solution will fall
somewhere between the two. Day-to-day running of the core processes of the
operation will be handled by SAP R/3, but letters and e-mail will still be
handled by solutions, such as those provided by Microsoft. The reason, of
course, is simple. No single application or suite of applications can do
everything.
Access to an organizations software resources are controlled at a number of

different levels, such as the following:
Network level
Machine level
Application level
Control at all of the above levels is achieved by the issuing of user IDs and
passwords that allow the relevant access to the required resources. Usually,
these user IDs are issued from different departments, each responsible for
the control of a particular level. The IDs then have to be combined to provide
access to the required resources. Sometimes, when logging on, users will
have to provide a user ID and relevant password to unlock the machine, then
the same again to access the network and, finally, once more to access the
application they need to work with.
This is not only time consuming, but sometimes difficult to manage. It can
also take a long time to correct when something goes wrong, which means
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.
Organizations rely on data stored in various applications and formats to run

their business and keep them ahead of their competition. This information
needs to be secure, and, for the most part, all of the measures put in place to
ensure the security of software. This also ensures the security of the data.
However, this data is only secure and controlled as long as it stays in the
application it was created in and locked in behind a wall of native security. As
soon as that data is removed or copied from the application, for printing a
hard copy, for example, then it is no longer secure. At this point, it can be
intercepted or printed in the wrong place and, therefore, be seen by people
who should not see it or simply be lost in the network never to be seen again.
If data is intercepted on a network, perhaps via a packet sniffing program,
and if this data is not encrypted, then it can be read by anyone. Also, if an
organizations network routing is not very reliable, then a document can be
printed in the wrong place. For example, if someone in Human Resources
was to print confidential information, and it ended up being printed in the
Accounts department, then it could be disaterous. The other problem that
plagues networks is data disappearing altogether. It doesnt get printed for
some reason; however there is no way of telling why until it is not in the
printer when someone goes to look for it.
For data to be secure at all times while it is inside the computer network, then
secure and controllable output channels need to be created; and again, these
need to be centrally managed for the solution to be successful.
262
6.5.3 Security and Resource Management Software solution

Now that the types of resources and the security they need have been
identified, this section suggests which Tivoli solutions and products should be
implemented to provide the best security solution possible. What follows is a
list of which Tivoli products should be implemented:
Tivoli Security Management (Lockdown Modules)
Tivoli User Administration
Tivoli Global Sign-On
Tivoli Output Manager

The list in the previous section shows which Tivoli products and solutions are
particularly suited in providing a security and resource management scenario
for SAP R/3. The aim of this section is to explain, or suggest, the best ways to
implement them to provide an effective enterprise wide solution. The
following is a description of the functions and benefits each piece of software
would bring to the overall solution.
6.5.4.1 Tivoli Global Enterprise Manager
Tivoli Global Enterprise Manager is Tivolis solution for managing applications
and systems from a business perspective. Once an application is
instrumented from Tivoli Global Enterprise Manager, Tivoli allows
management of this component in the wider context of a business system.
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
role-based security, it is possible to determine what resources people have

access to based on the job tasks, or roles, that they need to perform. In Tivoli
Security Management, these resources can be of different types including
files, printers, applications, or TCP services. They can also reside on different
platforms. This is useful, as SAP R/3 is naturally distributed across one or
more platform and involves a number of different components, all of which
need identifying and then controlling. Resources can even reside on OS/390
systems protected by the OS/390 RACF. This is especially useful in
implementations of SAP R/3 that use an OS/390 database system. Tivoli
Security Management enables the identification of all resources in the
enterprise that are required to complete a particular task. Once this process
has been completed, the resources can be listed in a role and the relevant
access rights given. It even means that individual files can be secured to
prevent unauthorized access even if the machine that the file resides on is
removed from the network. Once roles have been identified, Tivoli security
groups can be formed based around a job title. These groups can then be
given all the roles they need in that position.
This solution provides centralized management of both security and
resources once it is configured. An administrator does not have to be
concerned with granting access to a user or resources of many different types
on many different systems. Instead, the administrator just adds the user to
the Tivoli Security group, and all the access rights are granted during the next
security profile distribution. This is useful when an organization has a number
of SAP systems, as the correct access to each can be granted easily.
This solution means that the enterprise is better secured because loopholes
are less likely to appear, and users will only get the resource access they
need and no more, therefore, reducing the chances of data being accessed
by the wrong people.
6.5.4.3 Lockdown Modules
The purpose of a lockdown module is to provide a way of defining a security
profile that can be easily altered, expanded, and, most importantly, be reused
in another location. Some lockdown modules are available ready-made for
products, such as Windows NT, Lotus Domino, and SAP R/3. A lockdown
module includes the definition of roles that provide the required level of
access to perform different tasks with the subject application or operating
system.
Lockdown modules enable the easy, enterprise wide management of systems

and applications. They provide specific Tivoli Security Profiles that can be
easily modified to match an environment, applied to an endpoint, and then
264
tested to lockdown a specific system or application. This again reduces the

time an administrator needs to manage a security solution and reduces the
risk of loopholes and unauthorized access.
Lockdown Modules make Tivoli Security Management simpler and faster to
use, whether the are developed within the organization or obtained
ready-made. Tivoli Security Management address a number of the issues that
arise in a security management solution. It is centralized, covers a wide range
of resources and platforms, and is an effective way of preventing
unauthorized access, therefore, controlling day-to-day access to all types of
resources.
6.5.4.4 Tivoli User Administration
Tivoli User Administration extends the capabilities of the Tivoli environment to
allow the management of user accounts on a number different platforms and
applications including SAP R/3.
Tivoli User Administration provides a network computing environment with a

number of features:
Centralized and GUI-based control of administration tasks.
Consistent administrative policy definition.
Automation of repetitive administration tasks.
Parallel operations performed on many users and systems.
Delegation of administrative tasks to other administrators.
Configuration error reduction via profile based methodology.
Single action user management to synchronize logins and passwords.
The most important things it provides are centralized control and a consistent
approach to administrative policy definition. As said before, this reduces the
risk of loopholes and makes the management of the security in a whole
enterprise a lot easier.
6.5.4.5 Tivoli Global-Sign On
Tivoli Global Sign-On is a very useful product in large enterprises. It provides
a secure and easy-to-use solution that grants users access to the computing
resources they are authorized to use with just one logon. Much like Tivoli
Output Manager, only Tivoli Global Sign-On deals primarily with applications
and systems. It is designed for use in large organizations, which consist of
multiple applications and systems, within heterogeneous, distributed
computing environments. Global Sign-On removes the need for end-users to
manage multiple user IDs and passwords.
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.
As stated previously, enterprise applications, such as SAP R/3, rely on the

output environment to deliver critical reports to single users and management
teams. Usually, an enterprise output manager is responsible for orchestrating
the delivery of these reports according to the business rules that have been
defined. Tivoli Output Manager can perform the following tasks and provide
the following benefits:
Centralized Output Management
This is very important. As stated previously, by centralizing all operations of
this type, the chances of loopholes are reduced, and the overall solution
should be more robust and coherent across the enterprise. The structure and
operation of the environment can be easily manipulated from a central point.
Output activity can be monitored and tracked closely and, more importantly,
pro-actively. This reduces the likely hood of data disappearing in the network
or being printed to the wrong location.
Controlled Access of Output Resources
Both administrators and users are defined across all 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 necessary security profile.
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.
Although, at first glance, this attribute seems inappropriate, when it comes to

enterprise security and rerouting of output devices, it make sense. With
automated delivery channels, you can track headers and apply audit rules to
all or some of the output channels.

This scenario has hopefully demonstrated some important ways in which
Tivoli solutions can be implemented to provide centralized and reliable
security and resource management. Security is a major issue in any
organization and should never be overlooked or placed low down the list of
priorities. However, this can happen sometimes, as solutions can be
expensive and difficult to implement and even more difficult to administer and
keep consistent after implementation. This need not be the case if Tivoli
solutions are used and implemented correctly to manage the security of an
267
enterprise and its resources as a whole. It provides centralized control and

administration, support over a wide range of platforms and applications, and
the ability to secure all forms of data from unauthorized external or internal
access.
268
269
270
Chapter 7. Examples of new features in SAP R/3 Management

Tivoli releases a variety of SAP R/3 management products to manage a
large-scale and complicated SAP R/3 systems environment efficiently. Tivoli
SAP R/3 management solutions are not only Tivoli Manager for R/3, but also
other Tivoli products. This means that a customer can implement a variety of
SAP R/3 management solutions by using Tivoli for each specific systems
environment. Tivoli products line can be a powerful solution to manage SAP
R/3 systems for all customers.
In Chapter 1, Introduction on page 1, we introduced the overview of each
Tivoli product that manages the SAP R/3 environment. In this chapter, we
focus on the following new Tivoli products for managing SAP R/3 systems and
introduce more detailed information.
Tivoli Decision Support for SAP R/3
Tivoli User Administration
These new Tivoli products provide excellent SAP R/3 management abilities.
Each Tivoli product works interactively, and these are integrated; therefore, it
enables you to perform seamless management and operations.
7.1 Tivoli Application Performance Manager

The following sections detail the installation and configuration of the Tivoli
Application Performance Manager (TAPM). TAPM was installed on a Windows
NT 4.0 server running an evaluation version of Sybase Adaptive Server
Enterprise 11.9.2. For more information on machine specifications and
required Tivoli software, please refer to Chapter 3, Our SAP R/3 System
environment on page 107.
Note
The version of Tivoli Application Performance Manager used during the

course of this redbook was a beta code version. Functions, features, and
supported environments for this product are subject to change without
notice any time before or after general release.
TAPM consists of five main components, each of which needs to be installed
or configured individually. The components are as follows:
271
Graphical User Interface (GUI)

This is integrated into the Tivoli Desktop and can be launched and operated
from any machine that has the Tivoli Desktop installed. All setup and control
of the data gathering session is performed via the GUI. Selections and control
actions made at the GUI are checked for completeness and validity before
being translated automatically into system commands for local execution at
the Tivoli Management Server or for transmission to specified Endpoints or
the Endpoint Gateway.
TAPM Front-End
This is located on the Tivoli Management Server and achieves the actual
implementation of the operations that are performed through the GUI. In
addition, it implements a CLI to accomplish administrative tasks. CLIs are an
alternative method of controlling TAPM.
TAPM Back-End
The TAPM Back-End resides in each active remote Endpoint that is to be
managed by the TAPM application. The back-end relies and depends on the
services of the Tivoli Management Agent, and it is responsible for receiving
requests that are passed on to the TAPM engine. The back-end also carries
communication from the engine to the Tivoli Management Server and the
Endpoint Gateway.
TAPM Engine
This is the actual collector of application performance data. An engine
resides on each Endpoint where the application performance must be
measured. The engine receives data directly from the application through the
application response measurement (ARM) interface. Data is then gathered
and aggregated in order to produce valuable information. The engine also
receives requests to perform management tasks from the TAPM back-end
component as a result of administrative operations issued at the management
server.
Upcall Collector
This resides at the Endpoint Gateway. It acts as a collector of data produced
by the TAPM engines and is responsible for storing them in a centralized
database.
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
Figure 123. Tivoli Application Performance Manager Components
7.2 Installation and configuration of TAPM components

In our scenario, each product required for TAPM was installed and configured
when needed. The following sections detail the installation of TAPM and its
other components. The order of installation of the components is not inflexible
and can be changed a lot. However, for the purpose of our installation, the
tasks were completed in the following order:
1. Installed and Configured Windows NT 4.0 Server
2. Installed Tivoli Framework 3.6
3. Installed Tivoli Framework Maintenance Release 3.6.1
4. Installed Tivoli Distributed Monitoring 3.6
5. Installed Tivoli Distributed Monitoring Maintenance Release 3.6.1
6. Installed TAPM Server Component 1.0
7. Installed TAPM Monitor Component 1.0
8. Added TAPM Notice Class to the Administrator
Examples of new features in SAP R/3 Management
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.
7.2.1 Installation and configuration of TAPM

Once the installation of the Tivoli Management Framework and Distributed
Monitoring had been completed on the POKIBMTAPM machine, the following
TAPM components were then installed using the Software Installation Service
(SIS):
Tivoli Manager for Application Performance Monitor Component
Version 1.0
Tivoli Manager for Application Performance Server Component
7.2.1.1 Adding the Notice Group to the Administrator
The first task is to add the TAPM Notice Group to the Tivoli Administrator so
that notices will be received and viewable if anything goes wrong in the
following configuration steps or when TAPM is fully configuring and running
under normal operation. The following figure briefly shows how to add the
Notice Group to the Tivoli Administrator:
274
Figure 124. Adding the TAPM Notice Group to the Administrator
7.2.1.2 Adding the new monitoring profile to the policy region

The next important task is to add the new monitoring profile, known as the
MarProfile, to the managed resources of any existing policy regions. The
following figure shows how to do this.
275
Figure 125. Adding Marprofile to the pokibmtapm Policy Region
Once this task is completed, it is suggested that a separate Policy Region is

created to hold all the TAPM profile managers. We created one called TAPM,
which can be seen on the Tivoli Desktop in Figure 125. This policy region also
needs to have MarProfile added to its managed resources.
The next step is to create a Profile Manager in the new Policy Region. The
following figure shows how to achieve this.
276
Figure 126. Creating a TAPM Profile Manager
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:
1. At the command line, type the following command:

wmarregapp -a application_name
The application_name must be that of an executable program or a batch

file. For example, to register the SAPGUI application, we typed the
command line:
wmarregapp -a sapgui.exe
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]
A confirmation message is displayed that identifies the items that have

been registered.
7.2.1.4 Creating monitoring profiles
After all the applications have been registered, the next step is to create a
monitoring profile for any applications that need to be monitored. The
following figure shows how to create the blank monitoring profile.
Figure 127. Creating a Blank Monitoring Profile
278
When creating a TAPM profile, the MarProfile must be selected, assuming it

has been added to the Managed Resources of the Policy Region as shown in
Figure 125 on page 276.
The profile has now been created and is identified by the special TAPM profile
icon.
It is now necessary to add into the profile which applications are to

be monitored before it is distributed to the relevant Endpoints. The following
figure illustrates how to do this:
Figure 128. Adding Applications to a Profile
Before an application can actually be added for monitoring, it must first be

given a schedule of when to run and collect data. This is achieved by
279
selecting the application required and clicking the Schedule button. This will
give a dialog box as follows:
Figure 129. The Schedule Dialog Box
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
Figure 130. Adding a Monitoring Rule to a Schedule
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
Figure 131. Database Settings Dialog
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
Figure 132. Application Added to Application Availability Profile
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
Figure 133. Adding Subscribers to the Profile
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
Click this button to

distribute the profile
Figure 134. Distributing the Monitoring Profile
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
Therefore, the format of our wrcrtrim command was:

wcrtrim -i -v Sybase -h pokibmtapm -d tapm_db -u sa -H d:\Sybase -s
pokibmtapm 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:
Figure 135. Tables Created by Create Database Script
7.2.1.7 Installation and configuration of Winrunner

Winrunner-Quicktest for R/3 is a software testing tool optimized for testing
R/3 systems. Quicktest for R/3 launches the SAPGUI and records the user
interaction with the client. It allows the recording of interaction with the R/3
client software. This can then be played back with many sets of data to verify
the business logic.
287
Installation of Winrunner-Quicktest for R/3 is straightforward. Run the setup

program from the TAPM CD-ROM. Once installed, start the program by
selecting it from the Windows Start Menu. It should start with a user interface
that looks as follows:
Figure 136. Initial Screen of Winrunner-Quicktest for R/3
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:
Figure 137. Adding an SAP Connect Step to a Business Process
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
Figure 138. sm37 Step From Winrunner Testcase
The processes detailed previously has to be repeated for each business

process that needs to be recorded for the test case that is being constructed.
The test case must end with a logoff step. This needs to be recorded like all
the other steps in the test case.
For the complete test case used for this project, please see Appendix A,
Winrunner-Quicktest for R/3 test case on page 345.
The final step is to register the Virtual User Script (VUS) file created with
Winrunner to the TAPM application. This is achieved by using the wmarreg.sh
script. To register the script, we typed the following command:
wmarreg.sh sapgui d:\TAPM_Testcase\Testcases\TAPM_Testcase.usr -v
The TAPM_Testcase.usr file is created automatically by Winrunner when the

test case is saved. This registered the VUS and meant that it could then be
added to a TAPM profile for distribution to the Endpoints. When adding a
simulation script to a profile by the process shown in Figure 128 on page 279,
the Simulation Settings button will become available. Clicking this button will
produce a dialog box as follows:
291
Figure 139. Simulation Settings Dialog Box
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
7.3 Tivoli Decision Support for SAP R/3

Tivoli Decision Support (TDS) provides a powerful mechanism to aid its users
to dive into complex database structures and to explore them in different
scopes, levels of details, and from different perspectives. It also allows its
users related data in multiple dimensions. Collectively, these features enable
them to gain a deeper understanding of, and insight into, the relationship
between the data stored in different systems that affect the business
operation and performance of an organization.
Because of its flexibility in handling data in different scopes, levels of details,
perspectives, and dimensions, Tivoli Decision Support addresses the
information needs of different users for conducting analyses and decision
making from technical analysts through line managers to executives.
Finally, Tivoli Decision Support handles the delivery of, and access to, the
data. It facilitates knowledge discovery and user access to information. Data
collected can be shared with others in the organization using delivery
mechanisms including hard-copy printouts, files, and push content. In the
latter case, content that has been collected by one user can be sent to a
central repository on a companys intranet from which other users can gain
access to the content.
7.3.1 Tivoli Decision Support components

Tivoli Decision Support can be categorized into two main parts:
Tivoli Decision Support Base Product
Tivoli Decision Support Discovery Guides
The base product provides functions that are necessary to configure,
administer, and operate Tivoli Decision Support, all being prerequisites for
using the TDS Discovery Guides. The base product is composed by the
following components:
TDS Discovery Administrator
TDS Server component
TDS Discovery Interface
Cognos PowerPlay
Crystal Reports
A TDS Discovery Guide is a TDS module that groups the enterprise data into
specialized categories. Each category contains a series of topics that
293
correspond to the different aspects of that category. Each topic contains a

number of views that are associated with the data elements being examined.
Tivoli Decision Support uses the TDS Discovery Guides to aid in discovering
key information. With this information, Decision Support becomes a powerful
end-user solution. This solution provides users with a comprehensive set of
views into their enterprises data.
Figure 140 shows the relationship between the Tivoli Decision Support Base
Product and Tivoli Decision Support Discovery Guides.
Tivoli Decision Support Discovery Guides:
Figure 140. Tivoli Decision Support Components
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
for the latest information of Discovery Guide availability. In this redbook, we

will describe in more detail the Tivoli Decision Support for SAP R/3.
7.3.2 Supported platforms

The following are the platforms supported by Tivoli Decision Support:
294
Operating Systems
Windows NT 4.0
Windows 95
Database Management Systems
Oracle
Sybase
SQL Server 6.5
Informix
DB2
7.3.3 Tivoli Decision Support architecture

Typically, Tivoli Decision Support is implemented in network mode. A network
mode installation makes it possible for multiple users to access TDS in the
various areas of the enterprise.
TDS Discovery Interface and Cognos PowerPlay are installed on the client
machines. The client also requires the installation of both the Client Database
and the ODBC Driver in order to have access to the data stored in the
database server.
The TDS Server component is installed on a file server that the client
machines have access to a shared drive that will contain all the information
needed to retrieve the reports.
A separate machine is used as the administrator system where the TDS
Discovery Administrator module is installed along with Cognos PowerPlay.
The Administrator system should access the shared drive in the TDS File
Server. In addition, it also requires the database client and the ODBC driver
in order to have a connection to the database. The Discovery Administrator
has access to the database in order to gather and maintain all the data used
by Decision Support. The Discover Administrator can be customized to
automatically gather the data, which are stored into special files called Cubes
(that is, populates this special file with current data from your organizations
databases), at pre-defined intervals or enables you to perform such
operations manually. The Cube files created by the Discovery Administrator
are stored on the TDS File server.
The diagram in Figure 141 shows the Tivoli Decision Support Architecture in
the network mode.
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
Shared File Access
File server running

server components
including guides,
cubes and models
System running
Administrator and client
Figure 141. TDS Architecture Diagram
7.3.4 Tivoli Decision Support work flow

We can generalize the TDS functionality in three basic steps:
Data Collection
In this step, TDS Discovery Administrator performs a pre-defined set of SQL
queries against the Tivoli product database collecting the data. It is done
through an ODBC connection. The resulting data is exported and stored into
comma separated value (csv) files. Exporting may also include calculation to
add value to the data.
Cube Building
In this step, TDS Discovery Administrator calls the Cognos PowerPlay
Transformer to calculate and aggregate the values according to the
Transformer model and build the Powerplay Cube. Each Discovery Guide
installs its Transformer model(s) to the TDS File Server during installation.
Transformer loads the model from the TDS File Server while building the
Cubes. The Cube building process may be scheduled to off hours, especially
working with large databases, since it may take considerable workload to
complete.
Data Presentation
The data is presented through a topic-specific navigation aid by means of
relevant business questions on the TDS Discovery Interface. The user can do
296
multi-dimensional interactive analysis, such as slice, dice, drill up/down, or

filter, as well as other functions on the presented data. An important point to
consider is that the data can be historical or online. For historical data, TDS
uses the Cubes to present the data while, for online data, Crystal Reports is
used. Therefore, the database client and an ODBC connection is required to
exist in the TDS Discovery Interface workstations.
7.3.5 Tivoli Decision Support for SAP R/3

The Tivoli Decision Support for SAP R/3 allows data collected from the R/3
servers and R/3 system activity to be displayed into reports responding to a
customers need to identify trends and predict future demands on a systems
resources and by helping them to make decisions on their SAP R/3
environment. This corresponds to the need of a customer and service
provider to be able to monitor the systems performance against a Service
Level Agreement (SLA).
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
Presenting transaction and dialog information.

Automated data gathering.
7.3.6 TDS for SAP R/3 Cubes and Related Reports

A PowerCube contains data organized in dimensions and measures. The
TDS for SAP R/3 provides cubes which contain queries (refer to the Figure
142). Each query creates a comma separated value (.csv) data file for the
Cognos Transformer, and the resulting .cvs files are used by the Cognos
model to build a PowerCube. Each of the queries extracts data from the
relational database through an ODBC driver. R/3 Guide cubes includes the
following information.
Figure 142. Cubes and related reports
298
R/3 Performance Trends
Provides information to identify

trends in system performance,
including drill-downs to servers
in a system and transactions
processed on the servers.
R/3 Load Balance Analysis
Provides information about how

much load is placed on each
system. This cube helps
determine which users are
consuming the most resources
and what transactions they are

processing.
R/3 Capacity Planning Analysis
Provides information to assist in

capacity planning. The cube
allows drill-down into server and
transaction values to identify
trends in dialog volumes. This
cube allows administrators to
determine if additional capacity
is needed for increased user
demand.
R/3 Workload Type Analysis
Provides information about

dialog performance over time.
R/3 Transaction Performance

transaction and program
performance.
R/3 Transaction Response Components Provides a breakdown of

transaction response time into
base components of CPU time,
database time, and other time.
The cube provides information
on transactions that are well
balanced, or are database or
CPU intensive.
R/3 Service Level Agreement

whether the Service Level
Agreement is met or missed.
7.3.7 Examples of using TDS for SAP R/3 Analysis

In this section, we introduce some examples of using Tivoli Decision Support
for SAP R/3.
Example 1
The following chart (Figure 143) shows R/3 load balance analysis. This is a
helpful view for determining which systems and servers are busy.
299
Figure 143. Example 1: R/3 load balance analysis
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
Figure 144. Example 2: R/3 Service Level Agreement
Example 3
The following report (Figure 145) shows each transaction code by average
response time.
301
Figure 145. Example 3: R/3 response time
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
7.4 Tivoli Global Enterprise Manager

Tivoli Global Enterprise Manager (GEM) plays a vital role in Tivoli solutions
for application management, for example, SAP R/3 or database. Tivoli GEM
not only provides application management ability for the specific application,
but also a user friendly GUI, a managed resource topology map, and so on.
Therefore, Tivoli GEM will be a powerful application management tool and will
improve your application management dramatically, especially SAP R/3
management.
In this section, we introduce the overview of Tivoli GEM, how to configure
Tivoli GEM for managing SAP R/3 systems, and how Tivoli GEM works with
SAP R/3 managed resources.
304
7.4.1 Overview of Tivoli GEM

Tivoli GEM consists of at least four different components, and each Tivoli
GEM component plays the following role:
Tivoli GEM Console
Enables you to monitor, manage, and control

your business systems and applications. Tivoli
GEM Console GUI is based on Java interface,
and it is user-friendly.
Tivoli GEM Server
Interacts with instrumented business

components, for example, SAP R/3, for the
distributed environment through Tivoli
Management Framework. It provides
information for display on the Tivoli GEM
Console. The Tivoli GEM Server receives
heartbeat events from instrumented business
components and determines the business
system in which a component belongs. It also
queries the instrumented business
components for related business components
and for the status of its monitors.
Tivoli GEM Instrumentation Provides information about the specific

applications (for example, SAP R/3), system
software, or components to a management
system, such as Tivoli GEM. You can
instrument either a business system or
stand-alone application.
Event Enablement
Is installed on the TEC server. It enables TEC

to forward events to, and receive events from,
the server. Event enablement defines event
classes and rules for handling Tivoli
GEM-related events.
These Tivoli GEM components work interactively (refer to Figure 148).
305
Tivoli GEM
Console
Tivoli GEM
Server
TEC Server
Events
Tivoli GEM
Console
Tasks
Events
Tivoli GEM
Console
SAP R/3 Server

Figure 148. The Interactions between Tivoli GEM Components
In the following sections, we introduce the installation and configuration

processes for each Tivoli GEM component and how it works.
7.4.2 Installing Tivoli GEM for SAP R/3 management

The installation processes of Tivoli GEM are complicated because Tivoli GEM
consists of many components, and Tivoli GEM GUI is based on a Java
interface. Before installing Tivoli GEM components, you need to install the
Java Developer Tool Kit (JDK) on the appropriate Tivoli GEM components.
The following section introduces the installation processes of Tivoli GEM.
7.4.2.1 Tivoli GEM installation planning
The installation procedures of Tivoli GEM depend on whether your R/3
system is configured on TMA or not. In this redbook, we introduce the Tivoli
GEM configurations with TMA. In case of configuring your R/3 system with
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
+
+
Framework
Tivoli GEM
Event Enablement
+
TEC Server
+
+
Framework
Events
TEC Server
Tivoli GEM
Console
Tivoli GEM
Server
Managed Node
(Endpoint Gateway)
Events
Tasks
downcall
upcall
TMR Server
Java
+
TEC ACF
+
(Gateway Module)
+
+
Framework
Endpoint
Java
SAP R/3 Server

Figure 149. Software Configurations on Each Tivoli GEM Component
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
Tivoli GEM Console
Tivoli GEM Server
Required Software
Versio
n
Tivoli GEM Topology Console
2.2.1
Java Development Kit
1.1.7
Tivoli GEM Topology Server
2.2.1
Tivoli Framework
3.6.1
307
Tivoli
Component
GEM
TEC Event Server
Endpoint Gateway
Endpoint
TMR Server
Required Software
Versio
n
Tivoli GEM Event Enablement
2.2.1
TEC Event Server
3.6.1
3.6.1
Tivoli Framework
3.6.1
1.1.7
TEC Adapter Configuration Facility
3.6.1
3.6.1
3.6.1
Tivoli Framework
3.6.1
1.1.7
Tivoli Management Agent (lcfd daemon)
3.6.1
Tivoli GEM Instrumentation for Manager for R/3
2.0
TEC Adapter Configuration Facility
3.6.1
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:
Tivoli GEM Console

Endpoint Gateway (if you configure the R/3 system on TMA)
Endpoint (if you configure the R/3 system on TMA)
Managed Node (if you configure the R/3 system on a Managed Node)
There are several ways to download JDK. In our case, we downloaded JDK
from the following Web site:
http://ncc.hursley.ibm.com/javainfo
In this Web site, you will be able to find the following download page (refer to
Figure 150):
309
Figure 150. Downloading Java Development Kit
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
Perform installp format installation by using SMIT.
Windows NT V4
Perform InstallShield installation by running setup.exe.
7.4.2.3 Tivoli GEM Topology Server installation

The Tivoli GEM Topology Server provides the main engine of Tivoli GEM. As
we mentioned, the Tivoli GEM Server is required to be installed in the
following Tivoli GEM component.
310
Tivoli GEM Topology Server

The Tivoli GEM Server must be a Managed Node. In this project, we
configured the Tivoli GEM Server on the Windows NT Managed Node. The
installation process is quite simple. You install the Tivoli GEM Topology
Server module by using Tivoli desktop as follows (refer to Figure 151):
Figure 151. Tivoli GEM Topology Server Installation
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
Figure 152. Tivoli GEM Topology Server Installation Completion
7.4.2.4 Tivoli GEM Event Enablement installation

To communicate with the TEC server, Tivoli GEM provides the Tivoli GEM
Event Enablement module. As we mentioned, the Tivoli GEM Event
Enablement is required to be installed in the following Tivoli GEM component:
Tivoli Event Console Event Server

You can find the Tivoli GEM Event Enablement V2.2.1 module in the Tivoli
GEM installation CD-ROM. The Tivoli GEM Event Enablement can also be
installed by using Tivoli Desktop as follows (refer to Figure 153):
312
Figure 153. Tivoli GEM Event Enablement Installation
If you complete the installation successfully, the following messages are

displayed (refer to Figure 154):
313
Figure 154. Tivoli GEM Event Enablement Installation Completion
7.4.2.5 Tivoli GEM Topology Console installation

To display or control your SAP R/3 systems environment, Tivoli GEM provides
a Java based GUI (Tivoli GEM Topology Console module). It is a rather
sophisticated and user-friendly GUI. As we mentioned, you can configure the
Tivoli GEM Console on the following platforms even if the system does not
join the TMR.
AIX 4.1.5 or later

HP-UX 10.20
OS/2 Warp 4
Windows 95
Windows 98
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.
Figure 155. Tivoli GEM Topology Console Installation

315
Figure 156. Tivoli GEM Topology Console Installation Completion
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
Figure 157. Tivoli GEM Topology Console Icon
7.4.2.6 Tivoli GEM Instrumentation for R/3 Manager installation

Tivoli GEM Instrumentation for R/3 Manager provides information about SAP
R/3 applications. Tivoli GEM Instrumentation plays a vital role in SAP R/3
application management. As we mentioned, the Tivoli GEM Instrumentation
for R/3 Manager module is required to be installed in the following Tivoli GEM
component:
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
Figure 158. Tivoli GEM Instrumentation for R/3 Manager Installation

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
Figure 160. Instrumentation Task Libraries
These task libraries are used for Tivoli GEM operations. The following
sections introduce the configuration processes of Tivoli GEM.
7.4.3 Configuring Tivoli GEM for SAP R/3 management

To perform SAP R/3 systems management operations by using Tivoli GEM,
you need to configure both the Tivoli Manager for R/3 and Tivoli GEM.
Therefore, the configuration processes of Tivoli GEM are also a little
complicated. In this project, we configured the Tivoli GEM environment in the
following order:
320
1. Configure the TEC Event Server.

2. Configure Event Enablement.
3. Set up the Tivoli GEM Console user accounts.
4. Configure the Tivoli GEM Server to run as an NT Service.
5. Import the BDF, CDF, and Icon files.
6. Set up the Tivoli GEM heartbeat.
Note
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
Figure 161. Configuring TEC Event Console
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:
tsadmn (administrator) group

tsuser (user) group
If the user ID belongs to the administrator group, you can log in with
administrator access. If the user ID belongs to the user group, you cannot log
in with administrator access.
In this project, we configured the Tivoli GEM Server on the Windows NT
machine; therefore, we created and configured the tsadmn and tsuser user
group on Tivoli GEM Server by using the Windows NT User Manager utility as
follows:
1. Create the Tivoli GEM user groups:
tsadmn
tsuser
Figure 162. Creating Tivoli GEM Console User Group
323
2. Create users for Tivoli GEM Console operations.

3. Add the users to the tsadnm and tsuser user groups.
Note
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
where, the syntax of the service command is as follows:

account_name
An account name in the form DomainName\UserName. If

the account belongs to the local domain, you can specify
.\UserName.
password
The corresponding password for the specified

account_name.
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
7.4.3.5 Importing the BDF, CDF and Icon files

At this point, you will be able to open the Tivoli GEM Console on each
machine that the Tivoli GEM Topology Console is set up on. Tivoli Manager
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
Figure 163. Importing Application Management Package File
7.4.3.6 Setting up the Tivoli GEM heartbeat

To monitor up-to-date status of your SAP R/3 systems, you need to set up the
Tivoli GEM heartbeat. To set up the Tivoli GEM heartbeat, you need to run
the Send GEM Heartbeat task (refer to Figure 164) that is provided by Tivoli
Manager for R/3.
325
Figure 164. Send GEM Heartbeat Task
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
Figure 165. Executing the Send GEM Heartbeat Task
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
Figure 166. The Send GEM Heartbeat Task Completion
You can also confirm the setting of the Tivoli GEM heartbeat on the TEC
console as follows (refer to Figure 167).
328
Figure 167. TEC Events of the Send GEM Heartbeat Tasks
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.
7.4.4 Using Tivoli GEM for SAP R/3 management

At this point, your Tivoli GEM environment should work fine. Therefore, in this
section, we introduce some tips on the SAP R/3 management by using Tivoli
GEM.
329
7.4.4.1 Starting Tivoli GEM Console

First of all, you need to start the Tivoli GEM Console on the machine that the
Tivoli GEM Topology Console is installed. When you start the Tivoli GEM
Console, the following Tivoli GEM sign on screen will be displayed (refer to
Figure 168).
Figure 168. Tivoli GEM Console Sign On Screen
Therefore, you need to enter the appropriate information (user ID and

password) that you defined in the Tivoli GEM configuration processes. Then,
the following screen (refer to Figure 169) will be displayed if the user ID and
password are correct.
330
Figure 169. Tivoli GEM Console Initial Screen
As you can see, the life cycle toolbar shows four different functions as follows:
Plan
This function helps you create a high-level view of a project

business system prior to instrumentation. It also enables you to
access the Tivoli Module Designer.
Build
This function enables you to access the Tivoli Module Builder.
Verify
After completing the instrumentation of your business system, you

can use this verify function to view your business system and
determine whether it has been defined properly and meets your
expectations.
Control
This function enables you to view and manage the business

system.
The screens of each function are as follows:
331
Plan Mode Screen

The following figure (Figure 170) shows the screen that appears when you
choose the plan mode in the life cycle toolbar.
Figure 170. The Plan Mode Screen of Tivoli GEM Console
Verify Mode Screen

choose the verify mode in the life cycle toolbar.
332
Figure 171. The Verify Mode Screen of Tivoli GEM Console
Control Mode Screen

choose the control mode in the life cycle toolbar.
333
Figure 172. The Control Mode Screen of Tivoli GEM Console
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
Figure 173. SAP R/3 Managed Resources Topology Information
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
Figure 174. Displaying SAP R/3 Resource Properties
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
7.4.4.4 Displaying Event information

In the Tivoli GEM Console, you can display the events related to your SAP
R/3 systems or the specific SAP R/3 system easily. For example, if you would
like to check the events related to the specific R/3 system, you can display
these events by selecting the Event Viewer menu on the pull-down menu of
the R/3 system icon. The following figure (Figure 176) shows all the events
related to the R/3 system (wwdn07_IG3_00).
338
Figure 176. Tivoli GEM Console Event Viewer Screen
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
Figure 177. The Tivoli GEM Event Viewer Properties
7.4.4.5 Executing Tivoli Tasks

In the Tivoli GEM Console, you can also run some tasks by using the
pull-down menu bar. On the pull-down menu bar, you just need to select the
appropriate task and click the menu . Then, the specified task will be
executed. To see the result of the task execution, open the Tivoli GEM log
(Options -> Tear Away Log). The following figure (Figure 178) shows how to
display the Tivoli GEM log and the result of the Display_Buffer_Info task
execution.
340
Figure 178. The Result of the Display_Buffer_Info Task Execution
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
In this example, we displayed all running monitors on the R/3 application

server (wwdn07_IG3). As you can see, the status of all running monitors are
displayed.
7.4.4.7 R/3 Server unknown status considerations
In the Tivoli GEM configurations sections, we introduced the Send GEM
Heartbeat task. To monitor the up-to-date status of each R/3 server, this task
plays a vital role. Basically, Tivoli GEM sends a heartbeat to each SAP R/3
managed resource and detects its status.
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
Figure 180. The Unknown Status SAP R/3 Objects
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
Appendix A. Winrunner-Quicktest for R/3 test case

The following (Figure 181 and Figure 182) is a snapshot of the complete test
case that was used for testing TAPM.
Figure 181. Winrunner-Quicktest for R/3 test case (1/2)
345
Figure 182. Winrunner-Quicktest for R/3 test case (2/2)
346
Appendix B. Event classes for Tivoli Manager for R/3

The Manager for R/3 provides a set of TEC event classes. These event
classes are categorized according to where events originate from and how
they are used. The event classes that are provided are:
R/3 Alert Event Classes
These event classes arise from

alerts placed by R/3 onto its
SysMan interface. Events for these
classes are generated by the
wr3mib program.
R/3 Operational Event Classes
These event classes represent all

the events that result from R/3
SysMan events after drill-down
processing is performed.
R/3 Syslog Event Classes
These event classes represent

events that result from monitoring
the R/3 syslog file.
Distributed Monitoring Event Classes
These event classes are

associated with the Manager for
R/3 monitors.
Special Event Classes
These event classes support

internal Manager for R/3
processing.
The following sections show all event classes for R/3 Manager.
B.1 R3 alert event classes

The following table (Table 24) shows all R/3 Alert Event Classes.
Table 24. R/3 Alert Event Classes
Event Class
Description
SAP_ALERT_StateChange
A change occurred in the operation mode of the R/3

system.
SAP_ALERT_SAPsysUp
The R/3 application server has been started.
SAP_ALERT_SAPsysDown
The R/3 application server has been stopped.
SAP_ALERT_SlogId
An alertable syslog message has been generated.
347
348
Event Class
Description
SAP_ALERT_SlogFreq
An excessive number of events have been written to the

R/3 syslog.
SAP_ALERT_Buf
An R/3 buffer problem has been detected.
SAP_ALERT_Enqueue
The enqueue table or its name directory is filling up.
SAP_ALERT_Rollpag
Either the paging or roll area is overflowing to disk.
SAP_ALERT_Trace
Either an SQL or ABAP trace has

been turned on.
SAP_ALERT_DpQueue
The length of a dispatch queue has

been exceeded.
SAP_ALERT_PerfDia
A dialog work process has experienced excessive

response time or excessive wait time.
SAP_ALERT_PerfUpd
An update work process has experienced excessive

SAP_ALERT_PerfBtc
A batch work process has experienced excessive

SAP_ALERT_PerfSpo
A spool work process has experienced excessive

SAP_ALERT_AbapUpd
An error has occurred in an ABAP update process.
SAP_ALERT_AbapErr
An error has occurred in an ABAP dialog or background

process.
SAP_ALERT_AbapSql
An SQL error has occurred in an ABAP program,

possibly indicating a database problem.
SAP_ALERT_DbIndcs
A required index is missing in the database. This is

triggered when a discrepancy is detected during
periodic comparison of the physical database with the
logical model stored in R/3.
SAP_ALERT_DbFreSp
The database is filling up. This is triggered based on a

periodic check and forecast of the growth rate.
SAP_ALERT_DbArcSt
There is not enough space in the database archive

directory.
SAP_ALERT_DbBckup
Database backup alert.
SAP_ALERT_Spo
Spool alert.
SAP_ALERT_Arch
Archive alert.
Event Class
Description
SAP_ALERT_GenP3
Background task is off.
SAP_ALERT_GenP4
The application server profile in the profiles directory

does not match the profile in the database.
SAP_ALERT_GenP5
General alert class. No specific meaning identified.
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
For Oracle databases, optimizing statistics are being

collected.
B.2 R/3 operational event classes

The following table (Table 25) shows all R/3 Operational Event Classes.
Table 25. R/3 Operational Event Classes
Event Class
Description
SAP_ALERT_ABAP_ERR
This event results from drill-down of

SAP_ALERT_AbapErr.
SAP_ALERT_ABAP_SQL

SAP_ALERT_AbapSql.
SAP_ALERT_ABAP_VB

SAP_ALERT_AbapUpd.
SAP_ALERT_BUFF_CUA

SAP_ALERT_Buf.
SAP_ALERT_BUFF_DBST

SAP_ALERT_Buf.
Event classes for Tivoli Manager for R/3
349
350
Event Class
Description
SAP_ALERT_BUFF_FTAB

SAP_ALERT_Buf.
SAP_ALERT_BUFF_IRBD

SAP_ALERT_Buf.
SAP_ALERT_BUFF_PRES

SAP_ALERT_Buf.
SAP_ALERT_BUFF_PXA

SAP_ALERT_Buf.
SAP_ALERT_BUFF_SNTAB

SAP_ALERT_Buf.
SAP_ALERT_BUFF_TABL

SAP_ALERT_Buf.
SAP_ALERT_BUFF_TABLP

SAP_ALERT_Buf.
SAP_ALERT_BUFF_TTAB

SAP_ALERT_Buf.
SAP_ALERT_DB_ARCSTUCK

SAP_ALERT_DbArcSt.
SAP_ALERT_DB_BACKUP

SAP_ALERT_DbBckup.
SAP_ALERT_DB_FREESPC

SAP_ALERT_DbFreSp.
SAP_ALERT_DB_INDICES

SAP_ALERT_DbIndcs.
SAP_ALERT_DB_OPTMSTAT

SAP_ALERT_GenP15.
SAP_ALERT_DPQU_BTC

SAP_ALERT_DpQueue.
SAP_ALERT_DPQU_DIA

SAP_ALERT_DpQueue.
SAP_ALERT_DPQU_ENQ

SAP_ALERT_DpQueue.
SAP_ALERT_DPQU_SPO

SAP_ALERT_DpQueue.
Event Class
Description
SAP_ALERT_DPQU_V2

SAP_ALERT_DpQueue.
SAP_ALERT_DPQU_VB

SAP_ALERT_DpQueue.
SAP_ALERT_ENQU_ENQ

SAP_ALERT_Enqueue.
SAP_ALERT_GENP_03

SAP_ALERT_GenP3. This event usually indicates
that SAPMSSYS_RSALSUP5 was disabled.
SAP_ALERT_GENP_04

SAP_ALERT_GenP4. This event usually indicates
that a profile was not maintained.
SAP_ALERT_GENP_05

SAP_ALERT_GenP5.
SAP_ALERT_GENP_06

SAP_ALERT_GenP6.
SAP_ALERT_GENP_07

SAP_ALERT_GenP7.
SAP_ALERT_GENP_08

SAP_ALERT_GenP8.
SAP_ALERT_GENP_09

SAP_ALERT_GenP9.
SAP_ALERT_GENP_10

SAP_ALERT_GenP10.
SAP_ALERT_GENP_11

SAP_ALERT_GenP11.
SAP_ALERT_GENP_12

SAP_ALERT_GenP12.
SAP_ALERT_GENP_13

SAP_ALERT_GenP13.
SAP_ALERT_GENP_14

SAP_ALERT_GenP14.
SAP_ALERT_GENP_15

SAP_ALERT_GenP15.
351
352
Event Class
Description
SAP_ALERT_GENP_ARCH

SAP_ALERT_Arch.
SAP_ALERT_GENP_SPO

SAP_ALERT_Spo.
SAP_ALERT_OSCO_FILE
Operating system file space threshold has been

exceeded.
SAP_ALERT_OSCO_LOAD
Operating system load average thresholds have

been exceeded.
SAP_ALERT_OSCO_PAGE
Operating system paging thresholds have been

exceeded.
SAP_ALERT_OSCO_SWAP
Operating system swap thresholds have been

exceeded.
SAP_ALERT_PERF_BTC

SAP_ALERT_PerfBtc.
SAP_ALERT_PERF_DIA

SAP_ALERT_PerfDia.
SAP_ALERT_PERF_ENQ
Performance thresholds for the enqueue process

have been exceeded.
SAP_ALERT_PERF_SPO

SAP_ALERT_PerfSpo.
SAP_ALERT_PERF_V2

SAP_ALERT_PerfUpd.
SAP_ALERT_PERF_VB

SAP_ALERT_PerfUpd.
SAP_ALERT_RLPG_PAG

SAP_ALERT_Rollpag.
SAP_ALERT_RLPG_ROL

SAP_ALERT_Rollpag.
SAP_ALERT_SAPsysDown
This event comes directly from wr3mib.
SAP_ALERT_SAPsysUp
SAP_ALERT_SLOG_FREQ

SAP_ALERT_SlogFreq.
SAP_ALERT_SLOG_ID

SAP_ALERT_SlogId.
Event Class
Description
SAP_ALERT_StateChange
SAP_ALERT_TRSW_TRSW

SAP_ALERT_Trace.
B.3 R/3 Syslog event classes

The following table (Table 26) shows all R/3 Syslog Event Classes.
Table 26. R/3 Syslog Event Classes
Event Class
Syslog Message
SAP_SYSLOG_A05
No memory available.
SAP_SYSLOG_A07
Timeout.
SAP_SYSLOG_A08
Main memory destroyed.
SAP_SYSLOG_AB0
Run time error $$$$.
SAP_SYSLOG_AB1
Short dump $$$$ generated for error $$$$.
SAP_SYSLOG_B15
Memory area too small.
SAP_SYSLOG_B24
No memory available for table $$$$ in the table buffer.
SAP_SYSLOG_B33
Inconsistency in table $$$$ in DB interface.
SAP_SYSLOG_BB2
Inconsistent buffer &5&5.
SAP_SYSLOG_BS2
The synchronization module cannot allocate temporary

auxiliary memory.
SAP_SYSLOG_BV3
SQL error &5 occurred (poss. network pros.?) Work process

is stopped.
SAP_SYSLOG_BV4
Work process is in reconnect status.
SAP_SYSLOG_BY1
DB error &5.
SAP_SYSLOG_BY2
Database &6 for &3.
SAP_SYSLOG_BY3
DB error &6 accessing table &5&5.
SAP_SYSLOG_BY4
DB error &6 at &3 access to table &5&5.
SAP_SYSLOG_BYL
Database error &5 requires intervention by the database

administrator.
353
354
Event Class
Syslog Message
SAP_SYSLOG_BYM
SQL error &5 (possibly a network error); WP in reconnect

status.
SAP_SYSLOG_BYO
Deadlock occurred.
SAP_SYSLOG_BZ7
Storage request (&5&5 bytes) is too small for the record

(&5&5 bytes).
SAP_SYSLOG_BZ8
Output buffer (&5&5 bytes) is too small for the record (&5&5
bytes).
SAP_SYSLOG_BZW
Error &5 during compression/decompression (&5&5).
SAP_SYSLOG_D01
Transaction termination &5 (&a &b &c &d &e &f &g &h &i).
SAP_SYSLOG_E11
Buffer &8 could not be generated.
SAP_SYSLOG_EAA
Failed to open log partition.
SAP_SYSLOG_EAS
Failed to reschedule a periodic job.
SAP_SYSLOG_EAW
Failed to initiate start of job $$$$.
SAP_SYSLOG_EAY
Failed to read status entry for job $$$$.
SAP_SYSLOG_EAZ
Failed to maintain status entry for job $$$$.
SAP_SYSLOG_EB3
Failed to start a subsequent job for job $$$$.
SAP_SYSLOG_EBF
Failed to activate authorization check for user $$$$.
SAP_SYSLOG_EBG
Job $$$$ was not started.
SAP_SYSLOG_EBH
Cause: Preceding job $$$$ was cancelled.
SAP_SYSLOG_EBI
Error scheduling a batch job.
SAP_SYSLOG_ED6
No SAP system is currently active on computer $$$$.
SAP_SYSLOG_F3U
Database I/O error.
SAP_SYSLOG_F4B
Not enough $$$$ memory for $$$$ block.
SAP_SYSLOG_F5O
Unable to connect to database.
SAP_SYSLOG_F6H
Database error: TemSe ->&B(&C)-> for table &D key &a.
SAP_SYSLOG_F7U
Spool: Database access error: db_rsql $$$$ for table $$$$.
SAP_SYSLOG_F7Y
<This event results from syslog message F7Y>: Spool:

Database is inconsistent.
SAP_SYSLOG_F8M
Cannot send data to printer.
Event Class
Syslog Message
SAP_SYSLOG_F8X
Commit to data base failed.
SAP_SYSLOG_FAI
Insufficient main memory.
SAP_SYSLOG_FAJ
Internal error in spool work process.
SAP_SYSLOG_FAP
Spool inconsistency: Field &A does not match field &B.
SAP_SYSLOG_FBA
Version of shared memory is incorrect (Spool

administration).
SAP_SYSLOG_FBB
Spool component is not ready.
SAP_SYSLOG_FBI
Internal error in Spool, Code &A, arg1=&B, arg2=&C,

arg3=&D.
SAP_SYSLOG_FBJ
db_rtab_error at table &A, error &B.
SAP_SYSLOG_FBN
Spool is full.
SAP_SYSLOG_FCC
Inconsistency found in calendar buffer, buffer &5&5 reset.
SAP_SYSLOG_GE0
GC0 ... GDZ reserved for CCMS.
SAP_SYSLOG_GEA
Internal lock administration error.
SAP_SYSLOG_GEG
Lock table overflow.
SAP_SYSLOG_GEI
Enqueue: Initialization error.
SAP_SYSLOG_GH0
Error in central lock handler.
SAP_SYSLOG_GI0
Error calling the central lock handler.
SAP_SYSLOG_GI6
Central lock handler can be accessed again.
SAP_SYSLOG_P00
Failed to open roll file $$$$.
SAP_SYSLOG_P05
Memory request (malloc) failed.
SAP_SYSLOG_P0B
Paging file overflow ($$$$ blocks).
SAP_SYSLOG_Q0E
Signal $$$$ received by operating system.
SAP_SYSLOG_Q0M
Message server disconnected.
SAP_SYSLOG_Q0N
Failed to send a request to the message server.
SAP_SYSLOG_Q18
Work process $$ exclusively locked by user $$$$.
SAP_SYSLOG_R00
Failed to lock semaphore $$$, RC=$$$.
SAP_SYSLOG_R05
No active session available.
355
356
Event Class
Syslog Message
SAP_SYSLOG_R0N
Insufficient dialog work processes for number range buffer.
SAP_SYSLOG_R0O
No active update server available.
SAP_SYSLOG_R0R
The connection was deactivated after a DB error.
SAP_SYSLOG_R0S
The update was manually deactivated.
SAP_SYSLOG_R18
SAP commit failed.
SAP_SYSLOG_R1A
$$$ logon failed.
SAP_SYSLOG_R20
Insufficient shared memory.
SAP_SYSLOG_R22
SAPASRV failed, OP=$$, return code $$$.
SAP_SYSLOG_R29
No shared memory available.
SAP_SYSLOG_R2B
No storage for $$$$.
SAP_SYSLOG_R33
RSTG chain defective, return code $$$.
SAP_SYSLOG_R38
Error at DB commit, return code $$$$.
SAP_SYSLOG_R3C
Maximum no. users $$$$ reached.
SAP_SYSLOG_R44
RSTS: Rollout failed, return code $$$.
SAP_SYSLOG_R45
Shared memory destroyed.
SAP_SYSLOG_R65
Update terminated.
SAP_SYSLOG_S05
Profile error, return code $$$.
SAP_SYSLOG_S07
Failed to create shared tables.
SAP_SYSLOG_S0B
Maximum no. $$$$ of requests per CPI-C connection

reached.
SAP_SYSLOG_S10
Service initialization failed.
SAP_SYSLOG_S1F
Initialization $$$$ failed.
SAP_SYSLOG_S8D
Maximum no. $$$$ of connections reached.
SAP_SYSLOG_SK0
SAPcomm: Error.
SAP_SYSLOG_SK3
Error (&A) at status update (spool open &B &C &D &E).
SAP_SYSLOG_ST0
No free memory available in class $$$$.
SAP_SYSLOG_US1
User $$$$ locked due to incorrect logon.
Event Class
Syslog Message
SAP_SYSLOG_US2
User SAP* was deleted by user $$$$.
SAP_SYSLOG_US3
Logon attempt for locked user $$$$.
SAP_SYSLOG_US4
Maximum number of users reached.
SAP_SYSLOG_US6
User buffer is too small for user $$$$.
B.4 Distributed monitoring event classes

The following table (Table 27) shows all Distributed Monitoring Event Classes.
Table 27. Distributed Monitoring Event Classes
Event Class
Monitoring Source
BATCH_SERVICE_MONITOR
Batch Performance
DIALOG_SERVICE_MONITOR
Dialog Performance
FIELD_DESC_BUFFER_MONITOR
FTAB Field Catalog Buffer
GENERIC_KEY_BUFFER_MONITOR
TABL Generic Key Buffer
INITIAL_RECORDS_BUFFER_MONITOR
IRBD Initial Records Buffer
LONG_RUNNING_PROCESS_MONITOR
Long running process
MENU_BUFFER_MONITOR
CUA Menu and Text Buffer
OS_COLLECT_APSRVR_MONITOR
OS Collect - Application
Server
OS_COLLECT_DBSRVR_MONITOR
OS Collect - Database Server
OS390_COLLECT_MONITOR
OS/390
OS390_DB2_MONITOR
OS/390 DB2
PAGE_AREA_MONITOR
Page Area
PROGRAM_BUFFER_MONITOR
PXA Program Buffer
ROLL_AREA_MONITOR
Roll Area
Cancelled Job
SCREEN_BUFFER_MONITOR
PRES Screen and Dynpro

Buffer
SHORT_NTAB_BUFFER_MONITOR
SNTAB Short NameTab

Buffer
357
Event Class
Monitoring Source
SINGLE_RECORD_BUFFER_MONITOR
TABLP Single Key Buffer
SPOOL_SERVICE_MONITOR
Spool Performance
TABLE_DEF_BUFFER_MONITOR
TTAB Table Description

Buffer
UPDATE_SERVICE_MONITOR
Update Performance
WORK_PROCESS_DISPATCH_QUEUE_MONITOR
Work process dispatch queue
WORK_PROCESS_MONITOR
Work process
B.5 Special event classes

The following table (Table 28) shows all Special Event Classes.
Table 28. Special Event Classes
Event Class
Description
This event generates application server status.
SAP_APM_HEARTBEAT
This event is generated when an R/3 object is

created.
AMS_R3MONITOR_ALERT
This event is generated whenever one of the

Manager for R/3 monitors encounters an error.
This event is generated whenever the alert

control or alert reader routines encounter an
error.
This event results from a communication error

within the wr3slog program to the R/3 system.
B.6 Tivoli GEM event classes

The following table (Table 29) shows all Tivoli GEM Event Classes.
Table 29. Tivoli GEM Event Classes
358
Event Class
Description
APM_HEARTBEAT
This event is generated when an R/3 object is created.
APM_THRESHOLD
This event is generated when a Manager for R/3 monitor

exceeds the threshold.
359
360
Appendix C. Monitor sources and their attributes

This appendix lists all of the monitor sources and their attributes. Each table
heading has the following meanings:
Attribute
Description of the monitor as initially seen when creating a

monitor.
Keyword
Description of the monitor after it has been configured.
R/3 Reference
A mapping of the monitored value to its R/3 equivalent.

The reference is expressed as a transaction name /
grouping name (optional) / field name. If there is no direct
R/3 equivalent, this column explains how the field is
derived or what it means.
The following sections show all monitor sources and attributes.
C.1 OS collect source

The following table (Table 30) shows all OS Collect Sources.
Table 30. OS Collect Source
Attribute
Keyword
R/3 Reference
CPU Utilization user

(%)
USER_CPU_UTIL
st06 / CPU utilization

user %
CPU Utilization
system (%)
SYSTEM_CPU_UTIL

system %
CPU Utilization idle

(%)
IDLE_CPU_UTIL

idle %
System Calls per

second
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
st06 / Load average 1

min (rounded)
Load Average (5
min)
LOAD5_AVG
st06 / Load average 5

min (rounded)
361
362
Attribute
Keyword
R/3 Reference
Load Average (15

min)
LOAD15_AVG
st06 / Load average

15 min (rounded)
Context switches
per second
CONTEXT_SWITCH_SEC
st06 / Context
switches/sec
Physical Memory
PHYSICAL_MEMORY
st06 / Physical mem

avail kb
Physical Memory
Free
FREE_MEMORY
st06 / Physical mem

free kb
Pages in per second
PAGE_INS_SEC
st06 / Pages in/sec
Pages out per

second
PAGE_OUTS_SEC
st06 / Pages out/sec
Kilobytes paged in
per second
KB_PAGED_IN_SEC
st06 / Kb paged
in/sec
Kilobytes paged out

per second
KB_PAGED_OUT_SEC
st06 / Kb paged
out/sec
Configured swap
space size
CONFIG_SWAP
st06 / Configured
swap kb
Free swap space
FREE_SWAP
st06 / Free in
swap-space kb
Maximum swap
space
MAX_SWAP
st06 / Maximum
swap-space kb
Actual swap space

size
SIZE_SWAP
st06 / Actual
swap-space kb
Disk utilization (%)
DISK_UTILIZATION
st06 / Disk Utilization
Disk average wait

time
DISK_WAIT_TIME
st06 / Disk Avg wait

time ms
Disk kilobytes
transferred per
second
DISK_DATA_TRANSFER_SEC
st06 / Disk Kb
transferred/sec
Disk response time
DISK_RESPONSE_TIME
st06 / Disk Response

time ms
Disk average queue

length
DISK_QUEUE_LENGTH
st06 / Disk Queue
Attribute
Keyword
R/3 Reference
Disk average
service time
DISK_SERVICE_TIME
st06 / Disk Avg

service time ms
Disk operations per

second
DISK_OPERATIONS_SEC
st06 / Disk
Operations/sec
LAN packets in per

second
LAN_PACKETS_IN_SEC
LAN Packets in/sec
LAN packets out per

second
LAN_PACKETS_OUT_SEC
LAN Packets out/sec
LAN collisions per

second
LAN_COLLISIONS_SEC
LAN Collisions
LAN packet in errors

per second
LAN_PACKET_IN_ERRORS_SEC
LAN Errors in/sec
LAN packet out

errors per second
LAN_PACKET_OUT_ERRORS_SEC
LAN Errors out/sec
Note: Disk values apply to the disk with the highest response time at the last sampling
period.
C.2 Roll area source

The following table (Table 31) shows all Roll Area Sources.
Table 31. Roll Area Source
Attribute
Keyword
R/3 Reference
Roll Area Free

Space
ROLL_AREA_FREE
Not directly available.

ROLL_AREA_SIZE
minus
ROLL_CURRENTLY_U
SED
Roll Area Percent

Free
ROLL_AREA_PERCENT_FREE

ROLL_AREA_FREE
divided by
ROLL_AREA_SIZE
Roll Area Shared

Memory
ROLL_AREA_SHARED_MEMORY
st02 / Roll area / In

memory (Kb)
Roll Area Size
ROLL_AREA_SIZE

Total size of roll area.
Monitor sources and their attributes
363
Attribute
Keyword
R/3 Reference
Roll Currently Used
ROLL_CURRENTLY_USED
st02 / Roll area / Current

use (Kb)
Roll Area Percent

Used
ROLL_AREA_PERCENT_USED

ROLL_AREA_USED
divided by
ROLL_AREA_SIZE.
Roll File Size
ROLL_FILE_SIZE
st02 / Roll area / On disk

(Kb)
Roll Max Used
ROLL_MAX_USED
st02 / Roll area / Max.

use (Kb)
Roll Max % Used
ROLL_MAX_PERCENT_USED

ROLL_MAX_USED
divided by
ROLL_AREA_SIZE
C.3 Page area source

The following table (Table 32) shows all Page Area Sources.
Table 32. Page Area Source
364
Attribute
Keyword
R/3 Reference
Page Area Free Space
PAGE_AREA_FREE

PAGE_AREA_SIZE minus
PAGE_CURRENTLY_USE
D
Page Area Percent Free
PAGE_AREA_PERCENT_
FREE

PAGE_AREA_FREE
divided by
PAGE_AREA_SIZE
Page Area Shared

Memory
PAGE_AREA_SHARED_
MEMORY
st02 / Paging area / In

memory (Kb)
Page Area Size
PAGE_AREA_SIZE
Not directly available. Total

size of page area.
Page Currently Used
PAGE_CURRENTLY_USE
D
st02 / Page area / Current

use (Kb)
Attribute
Keyword
R/3 Reference
Page Area Percent Used
PAGE_AREA_PERCENT_
USED

PAGE_AREA_USED
divided by
PAGE_AREA_SIZE
Page File Size
PAGING_FILE_SIZE
st02 / Page area / On disk

(Kb)
Page Max Used
PAGE_MAX_USED
st02 / Page area / Max. use

(Kb)
Page Max % Used
PAGE_MAX_PERCENT_
USED

PAGE_MAX_USED
divided by
PAGE_AREA_SIZE
C.4 Work process source

The following tables (Table 33 and Table 34) show all Work Process Sources.
Table 33. Work Process Source (Attribute 1)
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
Table 34. Work Process Source (Attribute 2)
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
C.5 Work process dispatch queue source

The following table (Table 35) shows all Work Process Dispatch Queue
Sources.
Table 35. Work Process Dispatch Queue Source
366
Attribute
Keyword
R/3 Reference
All
All
sm51 / queue information
Dialog
Dialog
Update
Update
Update2
Update2
Batch
Batch
Spool
Spool
Enqueue
Enqueue
Nowp
Nowp
C.6 Long running work process source

The following tables (Table 36 and Table 37) show all Long Running Work
Process Sources.
Table 36. Long Running Work Process Source (Attribute 1)
Attribute 1
Keyword
R/3 Reference
All
All
sm51 / elapsed time
Dialog
Dialog
sm51 / elapsed time
Update
Update
sm51 / elapsed time
Update2
Update2
sm51 / elapsed time
Batch
Batch
sm51 / elapsed time
Spool
Spool
sm51 / elapsed time
Enqueue
Enqueue
sm51 / elapsed time
Table 37. Long Running Work Process Source (Attribute 2)
Attribute 2
Keyword
R/3 Reference
Threshold in seconds
Specified threshold value
sm51 / elapsed time
C.7 Buffer source

The following table (Table 38) shows all Buffer Sources.
Table 38. Buffer Source
Attribute
Keyword
R/3 Reference
Allocated Memory
ALLOCATED_MEMORY
st02 / Allocated (Kb)
Available Memory
AVAILABLE_MEMORY
st02 / Available (Kb)
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 Directory Entries
FREE_DIR_ENTRIES
st02 / Free directory

(Entries)
367
368
Attribute
Keyword
R/3 Reference
Free Directory Entries

Percent
PERCENT_FREE_DIR_ENTRIES

FREE_DIR_ENTRIES
divided by
MAX_DIR_ENTRIES.
Free Memory
FREE_MEMORY
st02 / Free space (Kb)
Free Memory Percent
PERCENT_FREE_MEMORY

FREE_MEMORY
divided by
AVAILABLE_MEMOR
Y.
Hits
HITS
st02 / Hits
Hit Ratio
HIT_RATIO
st02 / Hit ratio (%)
Last Reset Date
LAST_RESET_DATE
st02 / Startup (Date)
Last Reset Time
LAST_RESET_TIME
st02 / Startup (Time)
Max Directory Entries
MAX_DIR_ENTRIES
st02 / Dir. size Entries
Objects Swapped
OBJECTS_SWAPPED
st02 / Object swaps
Quality
QUALITY
st02 / DB access
quality %
Requests
REQUESTS
st02 / Requests
Total Resets
TOTAL_RESETS
st02 / Resets - Total
Used Directory
Entries
USED_DIR_ENTRIES
st02 / Directory entries

- Used
Used Directory
Entries Percent
PERCENT_USED_DIR_ENTRIES

USED_DIR_ENTRIES
divided by
MAX_DIR_ENTRIES
Used Memory
USED_MEMORY
st02 / Size - Used
Used Memory
Percent
PERCENT_USED_MEMORY

USED_MEMORY
divided by
AVAILABLE_MEMOR
Y
C.8 Performance source

The following table (Table 39) shows all Performance Sources.
Table 39. Performance Source
Attribute
Keyword
R/3 Reference
Frequency per minute
FREQUENCY
al01 / Performance - Count
Response Time in milliseconds
RESPONSE
al01 / Performance - Avg. Resp.
Wait Time in milliseconds
WAIT
al01 / Performance - Avg. Wait
C.9 OS/390 DB2 source

The following table (Table 40) shows all OS/390 DB2 Sources.
Table 40. OS/390 DB2 Source
Attribute
Keyword
R/3 Reference
Active pages of buffer pool

with maximum active
MAX_ACTIVE_BP_PAGE
S
st04 / Max active pages

(%)
Hit ratio of buffer pool with

minimum hit ratio
MIN_BP_HIT_RATIO
st04 / Min hit ratio (%)
Buffer Pool 0 hit ratio
BP0_HIT_RATIO
st04 / Buffer Pool Activity /

BP0 Hit Ratio (%)
BP2_HIT_RATIO

BP2 Hit Ratio (%)
BP3_HIT_RATIO

BP3 Hit Ratio (%)
32K Buffer Pool hit ratio
BP32K_HIT_RATIO

BP32K Hit Ratio (%)
Buffer Pool shortage - any

active pool
BP_SHORTAGE
st04 / Buffer pool shortage
Hiper pool concern - any

active pool
BP_HIPER
st04 / Hiper pool concerns
Buffer Pool 0 maximum

active pages
BP0_MAX_ACTIVE_PAG
ES
Not directly available. Can

be seen as Max active
pages (%) when this buffer
is the one with the highest
active pages.
369
370
Attribute
Keyword
R/3 Reference

active pages
BP2_MAX_ACTIVE_PAG
ES

active pages.

active pages
BP3_MAX_ACTIVE_PAG
ES

active pages.
32K Buffer Pool maximum

active pages
BP32K_MAX_ACTIVE_PA
GES

active pages.
Deadlocks
DEADLOCKS
st04 / Deadlocks
Lock Suspensions
LOCK_SUSPENSIONS
st04 / Suspensions
Lock Timeouts
LOCK_TIMEOUTS
st04 / Timeouts
Failures due to EDM pool

full
EDM_POOL_FULL_FAIL
URES
st04 / EDM pool full
EDM pool utilization (%)
EDM_POOL_IN_USE
st04 / EDM pool / Pages in

use (%)
Dynamic cache hit ratio
DYN_CACHE_HIT_RATIO
st04 / Dynamic Statement

Cache / Hit ratio (%)
Number of times
MAXKEEPD was
exceeded
MAXKEEPD_EXCEEDED
st04 / MAXKEEPD
exceeded
Indication of deferred close

threshold reached
CLOSE_THRESHOLD_R
EACHED
st04 / Deferred close

threshold reached
Commits
COMMITS
st04 / Commits
Rollbacks
ROLLBACKS
st04 / Rollbacks
Checkpoints
CHECKPOINTS
st04 / Checkpoints
C.10 OS/390 source

The following table (Table 41) shows all OS/390 Sources.
Table 41. OS/390 Source
Attribute
Keyword
R/3 Reference
CPU Utilization (%)
CPU_UTIL
os07 / Avg. Processor Utili.
CPU Utilization - system

(%)
SYSTEM_CPU_UTIL
os07 / MVS CPU

Utilization
Paging Rate
PAGING_RATE_SEC
os07 / Avg. System Paging

Rate
Pages In per second
PAGE_INS_SEC
os07 / Pages paged in/sec
Pages Out per second
PAGE_OUTS_SEC
os07 / Pages paged

out/sec
Pages Into Private per

second
PAGE_INS_PRIVATE_SE
C
os07 / Priv. pages paged

in/s
Pages Out of Private per

second
PAGE_OUTS_PRIVATE_S
EC
os07 / Priv. pages paged

out/s
Pages to Expanded
Storage per second
PAGES_TO_EXPSTOR_S
EC
os07 / Pages to exp.

storage
Pages from Expanded

Storage per second
PAGES_FROM_EXPSTO
R_SEC
os07 / Pages from exp.

storage
Blocked pages paged in
BLOCKED_PAGES_PAGE
D_IN
os07 / Blocked pages

paged in
Blocks paged in
BLOCKS_PAGED_IN
os07 / Blocks paged in
Unused interval count
UNUSED_INTERVAL_CO
UNT
os07 / High UIC count
Available frames in
expanded storage
EXPSTOR_AVAILABLE_F
RAMES
os07 / Avail. exp. stor. slots
Migration age
MIGRATION_AGE
os07 / Migration age
Total available frames
TOTAL_AVAILABLE_FRA
MES
os07 / No. of available

frames
371
372
Appendix D. TEC Rules and Events

This appendix shows TEC rules and events that are contained Tivoli Manager
for R/3 products.
D.1 Event Classes: Distributed Monitoring based

This section shows Distributed Monitoring based event classes.
SAP_Status_Monitors
SAP_Server_Monitors
SAP_Cancelled_Job_Monitors
All other Distributed Monitoring monitor events (23)
The following are the description of each event class.

SAP_Status_Monitors
The APSRVR_STATUS_MONITOR is a new event

class. It replaces and enhances the
SAP_SYSTEM_MONITOR class from 1.5.
SAP_Server_Monitors
SAP_Cancelled_Job_Monitors is a new class with

2.0. This class includes additional slot values for
reporting job information. Within the other DM
events under the SAP_Server_Monitors are new
classes for the new Manager for R/3 2.0 work
process monitors. These process classes do not
include any special slots.
The removed event class is SAP_SYSTMEM_MONITOR.
D.2 Event Classes: Alert adapter

This section shows SAP_Alert class hierarchy.
SAP_Alert
SAP_MIB_Alert
SAP_MIB_Unique_Alert (4)
SAP_MIB_Generic_Alert (33)
SAP_Internal_Alert (46)
373
SAP_Alert_Buffer (10)
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_Internal_Alert
SAP_Alert_Buffer
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.
D.3 Event Classes: Syslog adapter

This section shows syslog adapter event classes.
SAP_SYSLOG
SAP_SYSLOG_MSG
SAP_SYSLOG_xxx (98)
SAP_SYSLOG defines all the slot values.

SAP_SYSLOG_MSG is the default event class.
SAP_SYSLOG_xxx represents a small set of actual syslog messages where
xxx corresponds to an R/3 3-character message ID. If customers are adding
374
syslog event classes, it is recommended that they follow this naming

convention.
SAP_SYSLOG_RFC_ERROR is an error event. It defines special slot values
to provide information on the nature of the error. Occurrences of this error
should be investigated for underlying problems.
D.4 Event Classes: GEM

This section shows GEM event classes.
SAP_APM_BASE
SAP_APM_HEARTBEAT
The SAP_APM_HEARTBEAT is essentially a replica of the GEM

APM_HEARTBEAT event. The SAP_APM_HEARTBEAT is used to support
delay processing within the Manager for R/3 processing.
D.5 Correlating events

This describes shows correlating events.
R/3 system uses "system label"
sub_source slot
Application server uses hostname
sub_origin slot
hostname slot
Adapter events set by adapters
Distributed Monitoring events set by rule
Values parsed from "info" slot
Events come from several sources:

Alert adapter (including drill-down scripts)
Syslog adapter
Distributed Monitoring monitors
Events for an R/3 system are correlated by the system label (SID_dbhost).
This value is provided by the event adapters in the sub_source slot. For DM
monitors, the system label is returned in the "info" slot. A rule is provided that
TEC Rules and Events
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)
D.6 Rules: Handling duplicates

This section describes the rules that handle duplicates.
First event counter incremented
New event dropped
First event counter incremented
New event dropped
Other Distributed Monitor monitors
Closed older events
Keep new event
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
The following are rules:

dup_sap_cancelled_job_event (sap_monitor.rls/4)
dup_sap_monitor_event (sap_monitor.rls/5)
dup_sap_system_up (sap_monitor.rls/10)
dup_sap_system_up (sap_monitor.rls/12)
The 1.5 approach should be changed to keep the original event (incrementing
its duplicate counter) and dropping the new event.
D.7 Rules: Handling harmless

This section describes rules that handle harmless.
Show on TEC; close after 60 seconds
SAP_MIB_Unique_Alert (MIB)
SAP_ALERT_Slog_Id (MIB)
SAP_Server_Monitors (DM)
Never on TEC; drop immediately
SAP_Internal_Alert (MIB)
SAP_Alert_Buffer (MIB)
Harmless events apply only to SAP_Alert events. Harmless state is set in an

alert by the R/3 system when a problem clears. Since the problem is going
away, the TEC rules endeavor to either close the harmless in 60 seconds (to
minimize events on the TEC console) or to drop the event immediately.
harmless_set_timer (sap_tecad.rls/2)
drop_new_harmless (sap_tecad.rls/3)
harmless_still_open (sap_tecad.rls/12)
It seems that we should consider keeping the SAP_Internal_Alert and
SAP_Alert_Buffer events on the TEC console for 60 seconds instead of
closing them immediately. The 2.0 approach is the same as the 1.5 approach.
There is no HARMLESS severity in DM. Rules 2 and 12 are incorrect
referencing SAP_Server_Monitors.
377
D.8 Rules: Handling start up

This section describes rules that handle start up.
SAPsysUP
Create events for all R/3 alerts
Create APSRVR_STATUS_MONITOR event for "up"
APSRVR_STATUS_MONITOR "up"
Close SAPsysDown events
Close SAP_SERVER_Monitors events
Close APSRVR_STATUS_MONITOR down
Startup applies to the startup of the application server. When an application

server starts, we essentially want to reset its alert state. This means we want
to close all outstanding events for that application server and refresh its event
state with a new status of "up" and refresh the problem alerts with all alerts
now present in the application server.
sap_system_up (sap_monitor.rls/11)
sapsysup_clone_appstatus_event (sap_tecad.rls/5)
sapsysup_read_all_internal_alerts (sap_tecad.rls/7)
Rule 11 should not close events for cancelled batch jobs. Cancelled jobs are
a problem independent of startup/shutdown.
App Server Up - first 35 minutes
Drop all SAP_Server_Monitor events except for Cancelled Batch
Jobs
Cancelled jobs are a problem whenever they occur
Drop all SAP_Server_Monitors events
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

drop_sentry_events_on_sentry_sysup (sap_monitor.rls/15)
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 is essentially destroying the intent of sap_monitor.rls 15.
Cancelled jobs should not be dropped.
D.9 Rules: Handling mode switch

This section describes rules that handle mode switch.
For 35 minutes after Op Mode switch:
For SAP_Alert_Buffer events
Reset the alert in R/3
Subsequent R/3 alert will be harmless
Close immediate TEC event
For SAP_Server_Monitors events
Drop event
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.
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
D.10 Rules: Handling shutdown

This section describes rules that handle shutdown.
SAPsysDown
Occurs per app server
Create APSRVR_STATUS_MONITOR event for "down"
APSRVR_STATUS_MONITOR "down"
Close SAP_Alert events
Close SAP_SERVER_Monitors events
Close all SAP_SYSLOG_RFC_ERROR
Close APSRVR_STATUS_MONITOR "up"
Shutdown applies to the shutdown of the application server. When an

application server stops, we essentially want to reset its alert state. This
means we want to close all outstanding events for that application server and
refresh its event state with a new status of "down".
sap_system_down (sap_monitor.rls/13)
sapsysdown_clone_appstatus_event (sap_tecad.rls/6)
Rule 13 should not close events for cancelled batch jobs. Cancelled jobs are
a problem independent of startup/shutdown.
D.11 Rules: Handling application server down

This section describes rules that handle application server down.
Application Server Down
Accept
SAP_Status_Monitors
SAP_Alert_Buffer
SAP_SYSLOG
Drop
380
SAP_Server_Monitors
SAP_MIB_Generic_Alert
SAP_Internal_Alert
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.
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.
D.12 Rules: Forwarding events

This section describes rules that forward events.
Forwarding events
Forward all events to another TEC server
Forward operator acknowledged and closed events
Rules are provided to facilitate the forwarding of events to another TEC

server. These rules support the forwarding of all events and the forwarding of
operator acknowledgements and closures. This functionality is essentially
unchanged from 1.5.
381
forward_sap_events (sap_tecad.rls/13)
ack_sap_sentry_alert (sap_monitor.rls/16)
close_sap_sentry_alert (sap_monitor.rls/17)
D.13 Rules: Synchronizing R/3 with TEC

This section describes rules that synchronize R/3 with TEC.
Close/Acknowledge TEC event
Applies to any SAP_Internal_Alert
Applies only when operator initiated
Does not apply to Syslog events
Close TEC event
Reset R/3 alert
Acknowledge TEC event
Acknowledge R/3 alert
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.
Tell me if problem recurs.

Use original thresholds.
Acknowledge
Problem is still there.
Do not tell me unless problem gets worse.

Use current state as new thresholds.
ack_sap_alert (sap_tecad.rls/10)
close_sap_alert (sap_tecad.rls/11)
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.
D.14 Rules: Synchronizing TEC with R/3

This section describes rules that synchronize TEC with R/3.
Reset/Acknowledge R/3 alert
Applies to any SAP_Alert
R/3 action generates "harmless" alert
"Duplicate" rule closes original problem in TEC
New event is closed by "harmless" rule
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.
dup_sap_event (sap_tecad.rls/1)
D.15 Rules: Handling Syslog alerts

This section describes rules that handle Syslog alerts.
Applies to syslog alerts, not to syslog adapter events
Syslog adapter should be used instead of syslog alerts
Reset syslog alert
Done for each syslog alert
Enables new syslog messages
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.
reset_syslog_alert (sap_monitor.rls/9)
D.16 Rules: Drill down

This section describes rules that perform drill down.
Applies to SAP_MIB_Generic_Alert
Generic alert dropped
Drill down task launched to get SAP_Internal_Alert
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.
convert_mib_to_internal_alert (sap_tecad.rls/4)
D.17 Rules: Handling jobs

This section describes rules that handle jobs.
384
Fill Job Name, Job ID, Date slot
The SAP_Cancelled_Job_Monitors event class is a DM-based event class,

but it is extended with three additional slots for Job Name, Job ID, and Job
Date. A rule is provided to extract these values from the "info" slot and place
them in their respective slots. This is to facilitate the customer writing
additional rules that can perform processing based on these slot values. For
example, based on the job name, the customer may want to:
open a trouble ticket
page someone immediately
set different severities
sap_extract_job1 (sap_monitor.rls/1)
sap_extract_job2 (sap_monitor.rls/2)
D.18 Rules: Handling GEM events

This section describes rules that handle GEM events.
Provide GEM sub_source values
Not "system label" as in TEC
Forward events to GEM server
SAP_Server_Monitors
SAP_Status_Monitors
Convert SAP_APM_HEARTBEAT to APM_HEARTBEAT and send to
GEM
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.
sap_gemevnts_rule1 (sap_gemevents.rls/1)
385
D.19 Rules: Handling daemons

This section describes rules that handle daemons.
Rules to manage R/3 daemons
Specifically intended for saposcol
Closes down event when up received
Handles duplicate down events
Increment original duplicate counter
Drop new event
The saposcol is a daemon provided by R/3 to provide OS level information to

the R/3 system. When this daemon is down, R/3 is unable to report these OS
values. Manager for R/3 provides implements a DM monitor for daemon
status. These rules complement that monitor by managing the events coming
from it.
sentry_daemon_or_application_up (sap_monitor.rls/6)
sentry_daemon_or_application_down (sap_monitor.rls/7)
These rules are really not selective about daemons. They need to be modified
to specifically reference saposcol.
D.20 Rules: Handling hosts

This section describes rules that handle hosts.
Rules to manage R/3 host machines
Specifically intended for machine status
Function dropped in 2.0
Rules still present
Closes down event when up received
Handles duplicate down events
Increment original duplicate counter
386
Drop new event
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.
sentry_host_up (sap_monitor.rls/8)
sentry_host_down (sap_monitor.rls/9)
387
388
Appendix E. Special notices

This publication is intended to help system designers and technical users of
Tivoli products to understand more about the Tivoli Manager for R/3 and how
to manage SAP R/3 systems with Tivoli products. The information in this
publication is not intended as the specification of any programming interfaces
that are provided by Tivoli. See the PUBLICATIONS section of the IBM
Programming Announcement for Tivoli for more information about what
publications are considered to be product documentation.
References in this publication to IBM products, programs or services do not
imply that IBM intends to make these available in all countries in which IBM
operates. Any reference to an IBM product, program, or service is not
intended to state or imply that only IBM's product, program, or service may be
used. Any functionally equivalent program that does not infringe any of IBM's
intellectual property rights may be used instead of the IBM product, program
or service.
Information in this book was developed in conjunction with use of the
equipment specified, and is limited in application to those specific hardware
and software products and levels.
IBM may have patents or pending patent applications covering subject matter
in this document. The furnishing of this document does not give you any
license to these patents. You can send license inquiries, in writing, to the IBM
Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY
10504-1785.
Licensees of this program who wish to have information about it for the
purpose of enabling: (i) the exchange of information between independently
created programs and other programs (including this one) and (ii) the mutual
use of the information which has been exchanged, should contact IBM
Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and
conditions, including in some cases, payment of a fee.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The use of this information or the
implementation of any of these techniques is a customer responsibility and
depends on the customer's ability to evaluate and integrate them into the
customer's operational environment. While each item may have been
reviewed by IBM for accuracy in a specific situation, there is no guarantee
that the same or similar results will be obtained elsewhere. Customers
389
attempting to adapt these techniques to their own environments do so at their

own risk.
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of
these Web sites.
The following terms are trademarks of the International Business Machines
Corporation in the United States and/or other countries:
ADSTAR
AS/400
DB2
MQSeries
OS/2
RISC System/6000
Tivoli
Tivoli Ready
AIX
CICS
IBM
NetView
OS/390
SAP
Tivoli Enterprise
TME
The following terms are trademarks of other companies:

Tivoli, Manage. Anything. Anywhere.,The Power To Manage., Anything.
Anywhere.,TME, NetView, Cross-Site, Tivoli Ready, Tivoli Certified, Planet
Tivoli, and Tivoli Enterprise are trademarks or registered trademarks of Tivoli
Systems Inc., an IBM company, in the United States, other countries, or both.
In Denmark, Tivoli is a trademark licensed from Kjbenhavns Sommer - Tivoli
A/S.
C-bus is a trademark of Corollary, Inc. in the United States and/or other
countries.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and/or other
countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States and/or other countries.
PC Direct is a trademark of Ziff Communications Company in the United
States and/or other countries and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel
Corporation in the United States and/or other countries.
UNIX is a registered trademark in the United States and other countries
390
licensed exclusively through The Open Group.

SET and the SET logo are trademarks owned by SET Secure Electronic
Transaction LLC.
Other company, product, and service names may be trademarks or service
marks of others.
Special notices
391
392
Appendix F. Related publications

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

For information on ordering these publications see How to get IBM
Redbooks on page 395.
All About Tivoli Management Agents, SG24-5134
Tivoli Enterprise Performance Tuning Guide, SG24-5392
Managing SAP R/3 with Tivoli , SG24-5298
Tivoli Enterprise Internals and Problem Determination, SG24-2034
An Introduction to Tivolis TME 10, SG24-4948
Designing Tivoli Solutions for End-to-End Systems and Service
Management, SG24-5104
New Features in Tivoli Software Distribution 3.6, SG24-2045
TME 10 Deployment Cookbook: Courier and Friends, SG24-4976
Securing Applications with Tivoli Security Management Lockdown
Modules , SG24-5140
F.2 IBM Redbooks collections

Redbooks are also available on the following CD-ROMs. Click the CD-ROMs
button at http://www.redbooks.ibm.com/ for information about all the CD-ROMs
offered, updates and formats.
CD-ROM Title
System/390 Redbooks Collection
Networking and Systems Management Redbooks Collection
Transaction Processing and Data Management Redbooks Collection
Lotus Redbooks Collection
Tivoli Redbooks Collection
AS/400 Redbooks Collection
Netfinity Hardware and Software Redbooks Collection
RS/6000 Redbooks Collection (BkMgr)
RS/6000 Redbooks Collection (PDF Format)
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
F.3 Other resources

These publications are also relevant as further information sources:
Managing SAP R/3 with Tivoli , ISBN 0-1301-5037-1
Tivoli Manager for SAP R/3 Users Guide, GC31-8411
Tivoli Manager for SAP R/3 Release 1.5 , GI10-9224
Framework 3.6 Users Guide, GC31-8433
F.4 Referenced Web sites

These Web sites are also relevant as further information sources:
http://www.support.tivoli.com
http://ncc.hursley.ibm.com/javainfo
http://www.tivoli.com
394
How to get IBM Redbooks

This section explains how both customers and IBM employees can find out about IBM Redbooks,
redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.
Redbooks Web Site http://www.redbooks.ibm.com/
Search for, view, download, or order hardcopy/CD-ROM Redbooks from the Redbooks Web site.
Also read redpieces and download additional materials (code samples or diskette/CD-ROM images)
from this Redbooks site.
Redpieces are Redbooks in progress; not all Redbooks become redpieces and sometimes just a few
chapters will be published this way. The intent is to get the information out much quicker than the
formal publishing process allows.
E-mail Orders
Send orders by e-mail including information from the IBM Redbooks fax order form to:
In United States
Outside North America
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)
1-800-879-2755
1-800-IBM-4YOU
Country coordinator phone number is in the How to Order
section at this site:
Fax Orders
United States (toll free)
Canada
1-800-445-9269
1-403-267-4455
Fax phone number is in the How to Order section at this site:
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.
IBM Intranet for Employees

IBM employees may register for information on workshops, residencies, and Redbooks by accessing
the IBM Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button.
Look in the Materials repository for workshops, presentations, papers, and Web pages developed
and written by the ITSO technical professionals; click the Additional Materials button. Employees may
access MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.
395
IBM Redbooks fax order form

Please send me the following:
Title
Order Number
First name
Quantity
Last name
Company
Address
City
Postal code
Country
Telephone number
Telefax number
VAT number
Card issued to
Signature
Invoice to customer number

Credit card number
Credit card expiration date
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
File Transfer Protocol
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
collection interval 280

collector 272
command 93, 272, 285
Common Object Request Broker Architecture
(CORBA) 10
configuration 52, 119, 128
Configuration Files
ihsttec.cfg 323
r3mibIID.conf 84, 186
r3slogIID.cl 84, 189
r3slogIID.conf 84, 189
rfc_interface 197
configuration method 54
configuration parameter 130
context variable 104
control mode 333
core dump 78
correlation 246
CPIC 139, 197
CPU time 76, 299
cross-platform business application 65
csv file 296, 298
CUA buffer 188
cube 295, 296, 298
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
dependency 120, 123, 125

dependency manager 90
dependency set 93
Dependency Sets
sap_dep 93
sap_lib_dep 93
sap_tool_dep 93
deployment 168
Destiny 43
development 51
development class 129, 137
dialog user 129
directory 123, 125, 133, 150, 153, 176
disk space 171
Distributed Monitoring 10, 15, 17, 37, 50, 62, 78,
119, 152, 185, 194, 197, 199, 202, 208, 217, 219,
222, 223, 236, 241, 259, 274
distributed systems management 8
domain 324
downcall 93
download 120
drill-down 298
drill-down process 83, 186, 197, 220, 222
duplicate event 223
dynamic routing 25
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
generic event 186

Global Enterprise Manager (GEM) 10, 21, 53, 64,
111, 119, 163, 229, 236, 240, 241, 264, 304
group ID 133
GUI 1, 36, 38, 240, 264, 266, 272, 304, 305, 314,
343
guideline 246
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
Java 44, 305, 309, 314

Java Developer Tool Kit (JDK) 306, 308, 310
job ID 75
job log 290
job name 75
job scheduling 35
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
memory allocation 217

method 91
methodology 246
MIB 185, 188, 194, 222
MIB interface 186, 195, 220
Microsoft 3
Microsoft SQL Server 5
middleware 8
migration 67, 85, 98
mission critical transaction system 3
mode 131
module 93
monitor 17, 58, 145, 152, 211, 217, 248
monitor argument 79
monitor event 321
monitoring 15, 231, 242
monitoring collection 15, 78, 199, 202, 218, 242,
248
Monitoring Collections
R3 Server Central Monitors 79, 195, 202
R3 Server Remote Monitors 79, 195, 202,
208
monitoring profile 59, 79, 237, 275, 277, 283
monitoring schedule 280
monitoring source 79, 218
Monitors
Application Server Status 69
Long Running Work Process 78
Work Process 79
Work Process Dispatch Queue 79
Motif 168
MQSeries 33
multimedia 1
multiple column table 70
multiple R/3 systems 51
native installation 173, 178

nesting level 54
NetView 15, 46, 236, 241
NetWare Managed Site 97
network 16, 27, 51, 227 , 230, 241, 262
network component 237
network computing environment 7
network management 46
network mode 295
network topology 46
Network X-Ray 28
NIS Domain 97
notice 274
notice group 274
Nowp type 82
object 86, 99, 137, 150

object call 83
object database 63, 93, 98, 99, 103
object ID 94, 99
object instance 99
object label 99
Object Management Group (OMG) 10
object structure 52
object-oriented 7, 21
ODBC connection 296
ODBC driver 295, 298
OEM 19
online data 297
operating system 4, 51, 202, 217, 230, 232, 237
operation 230, 239, 240
operational task 18
operator 53, 231, 264
Oracle 5, 31, 150, 248, 254, 295
organization 230, 262, 268
OS/2 5, 314
OS/390 5, 196, 202, 207, 218, 238, 265
OS/390 DB2 18, 203, 218
OS/400 5
output 267
output environment 268
output resource 268
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
R3 App Server Monitors 200, 204

R3 DB Server Monitors 202
R3 Managed Nodes Monitors 202
R3 Transport 89, 130
program 99
property 68
proxy 26
pull down menu 68
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
SQL query 296

SQL Server 295
standard network protocol 25
startup option 324
status 76, 79
status icon 69
step-by-step approach 246
Subject Matter Experts (SME) 248
sub-policy region 199, 319
subregion 141
subscriber 89, 97, 132, 178, 201, 203, 207, 283
subscriber list 61
subscription list 199
Sun Solaris 315
swap file 233
switch 231
switched network 28
Sybase 271, 285, 287, 295
syslog 17, 84, 185, 189, 221, 223
syslog event 190
syslog event adapter 17, 61, 83, 84, 158, 159, 185,
189, 219
syslog message 17
syslog message ID 190
SysMan 185
SysMan interface 139, 186
system configuration 107
system job 238
system performance 298
system resource 297
system workload 297
systems management service 15
SystemView 7
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
task library 56, 61 , 126, 319

Tasks
Cancel Batch Jobs 73
Cancel Work Process 76
Configure Autodiscovery 72, 144
Configure Event Adapter 160, 186, 189
Configure Event Console 155, 321
Configure Event Server 152
Configure Remote Function Call 146, 197
Display Batch Jobs 72, 164
Display Buffer Information 340
Display Event Adapter Configuration 189
Display Work Processes 76
Release Batch Jobs 73
Remove Autodiscovery 67, 72
Send GEM Heartbeat 325, 342
Start Database 167
Stop Database 167
TCP service 265
TCP/IP 5, 25
TDS component 293
TDS Guide 19, 293
TEC 15, 16, 17, 37, 46, 50, 53, 62, 83, 110, 119,
151, 186, 189, 237, 239, 241, 247, 259, 343
TEC database 155
TEC event 15, 83, 84, 159, 185, 220, 242, 323
TEC event console 15, 84, 89, 128, 151, 186, 207,
216, 222, 247, 328, 339
TEC server 37, 63, 83, 103, 122, 124, 128, 151,
154, 186, 219, 220, 223, 305, 312, 321
technical analyst 293
telnet 237
test 51
test case 289
thin node 115
thread 234
threshold 52, 79, 184, 197
timeout 144, 160
Tivoli 7, 51
Tivoli administrator 52, 129, 141, 169, 274
Tivoli Application Performance Manager (TAPM)
20, 25, 112, 119, 163, 241, 271
Tivoli Commands
idlattr 100, 104
idlcall 100, 104
objcall 100
tivoli 122, 124
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
R3AppServer 93, 99, 103, 144, 326

R3AppServerPD 99
R3AppServerPV 99
R3DBServer 99, 103, 144, 326
R3DBServerPD 99
R3DBServerPV 99
R3Instance 99
R3System 99, 103, 104, 144, 326
R3SystemPD 99
R3SystemPV 99
Tivoli Output Manager 10, 43, 264
Tivoli Plus for Tivoli Workload Scheduler 35
Tivoli product 108
Tivoli role 61, 128
Tivoli Roles
install_product 122, 124
r3_admin 60, 140
r3_senior 60, 140
r3_user 60, 140
super 169
Tivoli Security Management 10, 40, 264
Tivoli Service Desk 10
Tivoli Storage Manager 42
Tivoli User Administration 36, 39, 264
Tivoli User Administration for SAP R/3 36
Tivoli Workload Scheduler 10, 35, 129, 236
Tivoli Workload Scheduler Extended Agent for SAP
R/3 10
TME 10 7
TMR 39, 62, 83, 89, 110, 119, 202, 314, 327, 336
TMR role 141
TMR server 37, 39, 62, 85, 91, 103, 108, 122, 124,
128, 130, 145, 148, 152, 155, 159, 169, 173, 175,
176, 195, 202, 203, 241, 317
topology information 334
topology map 304
TPPARAM file 134
transaction 26, 129, 297
transaction code 301
Transaction Codes
rz10
rz20
se80
sm21
sm37
sm50
sm51
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 Redbooks evaluation

SG24-5500-00
Your feedback is very important to help us maintain the quality of IBM Redbooks. Please complete this
questionnaire and return it using one of the following methods:
Use the online evaluation form found at http://www.redbooks.ibm.com/
Fax this form to: USA International Access Code + 1 914 432 8264
Send your comments in an Internet note to redbook@us.ibm.com
Which of the following best describes you?
_ Customer _ Business Partner
_ Solution Developer
_ None of the above
_ 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
__________
Please answer the following questions:

Was this redbook published in time for your needs?
Yes___ No___
If no, please explain:
What other Redbooks would you like to see published?
Comments/Suggestions:
(THANK YOU FOR YOUR FEEDBACK!)
409
SG24-5500-00
Printed in the U.S.A.
SG24-5500-00

Using Tivoli To Manage A Large-Scale SAP R 3 Environment

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Using Tivoli To Manage A Large-Scale SAP R 3 Environment

Загружено:

Авторское право:

Доступные форматы

Using Tivoli to Manage a Large-Scale SAP R/3

Yoichiro Ishii, Jamie Cooper, Yasuko Takada, Andre Wahjudi

International Technical Support Organization

International Technical Support Organization

First Edition (December 1999)

Chapter 2. What is new: Tivoli Manager for R/3 Version 2.0 . . . . . . . . 49

Copyright IBM Corp. 1999

2.2.1 Brief overview of new features and improvements . . . . .

Chapter 3. Our SAP R/3 System environment. . . . . . . . . . . . . . . . . . . 107

Chapter 4. Planning and implementation . . . . . . . . . . . . . . . . . . .

Chapter 5. Managing SAP R/3 environment . . .