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

SG24-5500-00

International Technical Support Organization

www.redbooks.ibm.com

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

Yoichiro Ishii, Jamie Cooper, Yasuko Takada, Andre Wahjudi

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

December 1999

SG24-5500-00

International Technical Support Organization

© Copyright International Business Machines Corporation 1999. All rights reserved.Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure issubject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

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 OrganizationDept. JN9B Building 003 Internal Zip 283411400 Burnet RoadAustin, Texas 78758-3493

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute theinformation in any way it believes appropriate without incurring any obligation to you.

Before using this information and the product it supports, be sure to read the general information inAppendix E, “Special notices” on page 389.

Take Note!

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix

Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiThe team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Information Technology environment . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Evolution of ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 ERP - The backbone of e-business . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 SAP - The leading ERP vendor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 What is SAP R/3?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 A brief history of Tivoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.7 SAP management challenges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.8 The Tivoli Management Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 81.9 Tivoli’s management solution for SAP R/3 . . . . . . . . . . . . . . . . . . . . . . 91.10 Tivoli Product Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.11 Summary of Tivoli’s management solutions . . . . . . . . . . . . . . . . . . . 11

1.11.1 Tivoli Management Framework . . . . . . . . . . . . . . . . . . . . . . . . . 151.11.2 Tivoli Distributed Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.11.3 Tivoli Enterprise Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.11.4 Tivoli Software Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.11.5 Tivoli Manager for SAP R/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.11.6 Tivoli Decision Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.11.7 Tivoli Global Enterprise Manager . . . . . . . . . . . . . . . . . . . . . . . 211.11.8 Tivoli Application Performance Manager. . . . . . . . . . . . . . . . . . 251.11.9 Tivoli Database Management Products. . . . . . . . . . . . . . . . . . . 311.11.10 Tivoli Manager for MQSeries . . . . . . . . . . . . . . . . . . . . . . . . . 331.11.11 Tivoli Workload Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . 351.11.12 Tivoli User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361.11.13 Tivoli Global Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371.11.14 Tivoli Security Management (Lockdown Module) . . . . . . . . . . 401.11.15 Tivoli Storage Manager (Tivoli ADSM) . . . . . . . . . . . . . . . . . . 421.11.16 Tivoli Output Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431.11.17 Tivoli NetView. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Chapter 2. What is new: Tivoli Manager for R/3 Version 2.0 . . . . . . . . 492.1 Tivoli Manager for R/3 packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.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 . . . . . . . . . . . 522.3 New functions in Version 2.0 of Tivoli Manager for R/3. . . . . . . . . . . . 54

2.3.1 Restructure of Tivoli Manager for R/3 . . . . . . . . . . . . . . . . . . . . . 542.3.2 Tivoli Management Agent (TMA) support . . . . . . . . . . . . . . . . . . 622.3.3 The Tivoli Global Enterprise Manager support . . . . . . . . . . . . . . 642.3.4 Automatic Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662.3.5 Improvement of status report . . . . . . . . . . . . . . . . . . . . . . . . . . . 692.3.6 Extensive Improvement in RFC API Tool . . . . . . . . . . . . . . . . . . 702.3.7 New tasks of Version 2.0 of Tivoli Manager for R/3. . . . . . . . . . . 712.3.8 New monitors of Version 2.0 of Tivoli Manager for R/3 . . . . . . . . 782.3.9 Improvement of interconnected TMR support . . . . . . . . . . . . . . . 832.3.10 User-Configurable Syslog Event Adapter . . . . . . . . . . . . . . . . . 842.3.11 Filtering events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 842.3.12 Migration tool for Version 2.0 of Tivoli Manager for R/3 . . . . . . 852.3.13 De-install tool for Version 2.0 of Tivoli Manager for R/3 . . . . . . 852.3.14 Delivery of ABAP program using J class . . . . . . . . . . . . . . . . . . 882.3.15 New R/3 specific event sources . . . . . . . . . . . . . . . . . . . . . . . . 89

2.4 Advanced knowledge of Tivoli Manager for R/3 . . . . . . . . . . . . . . . . . 902.4.1 R/3 Manager Endpoint methods . . . . . . . . . . . . . . . . . . . . . . . . . 902.4.2 R/3 Manager object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 992.4.3 Tivoli Application Proxy internals . . . . . . . . . . . . . . . . . . . . . . . 103

Chapter 3. Our SAP R/3 System environment. . . . . . . . . . . . . . . . . . . 1073.1 Overview of our environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073.2 Overview of our SAP R/3 environment . . . . . . . . . . . . . . . . . . . . . . . 115

Chapter 4. Planning and implementation . . . . . . . . . . . . . . . . . . . . . . 1194.1 Overview and objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194.2 Installation planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

4.2.1 Installation Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1204.3 Installing and configuring Tivoli Manager for R/3 . . . . . . . . . . . . . . . 121

4.3.1 Installing Tivoli Manager for R/3 . . . . . . . . . . . . . . . . . . . . . . . . 1224.3.2 Configuring Tivoli Manager for R/3 . . . . . . . . . . . . . . . . . . . . . . 1284.3.3 Configuring each SAP R/3 System . . . . . . . . . . . . . . . . . . . . . . 1284.3.4 Configuring the Tivoli Manager for R/3 to the R/3 System. . . . . 1404.3.5 Configuring event handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Chapter 5. Managing SAP R/3 environment . . . . . . . . . . . . . . . . . . . . 1635.1 Version 2.0 of Tivoli Manager for R/3 . . . . . . . . . . . . . . . . . . . . . . . . 163

5.1.1 SAP R/3 System Management tasks and jobs . . . . . . . . . . . . . 1635.1.2 SAPGUI distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

5.2 Log files for troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1835.3 Monitoring functions of Tivoli Manager for R/3 . . . . . . . . . . . . . . . . . 184

5.3.1 Alert Event Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

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

5.3.2 Alert Control Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1885.3.3 Syslog Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1895.3.4 Tivoli Distributed Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945.3.5 Default monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1995.3.6 TEC event classes and rules . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Chapter 6. SAP R/3 Management scenarios . . . . . . . . . . . . . . . . . . . . 2276.1 Tivoli SAP R/3 Management solutions . . . . . . . . . . . . . . . . . . . . . . . 2276.2 SAP R/3 Management scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 2306.3 Operations scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

6.3.1 What are operations? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2306.3.2 Detailed scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2316.3.3 Operations software solution . . . . . . . . . . . . . . . . . . . . . . . . . . 2366.3.4 Solution implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2376.3.5 Scenario summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

6.4 Availability and performance scenario . . . . . . . . . . . . . . . . . . . . . . . 2406.4.1 What is meant by availability and performance? . . . . . . . . . . . . 2406.4.2 Detailed scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2416.4.3 Availability and performance software solution . . . . . . . . . . . . . 2416.4.4 Solution implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2426.4.5 Scenario summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

6.5 Security and resource management scenario . . . . . . . . . . . . . . . . . . 2606.5.1 What is meant by security and resources? . . . . . . . . . . . . . . . . 2606.5.2 Detailed scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2616.5.3 Security and Resource Management Software solution . . . . . . 2646.5.4 Solution implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2646.5.5 Scenario summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Chapter 7. Examples of new features in SAP R/3 Management . . . . . 2717.1 Tivoli Application Performance Manager . . . . . . . . . . . . . . . . . . . . . 2717.2 Installation and configuration of TAPM components . . . . . . . . . . . . . 273

7.2.1 Installation and configuration of TAPM . . . . . . . . . . . . . . . . . . . 2747.3 Tivoli Decision Support for SAP R/3 . . . . . . . . . . . . . . . . . . . . . . . . . 293

7.3.1 Tivoli Decision Support components . . . . . . . . . . . . . . . . . . . . . 2937.3.2 Supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2947.3.3 Tivoli Decision Support architecture . . . . . . . . . . . . . . . . . . . . . 2957.3.4 Tivoli Decision Support work flow . . . . . . . . . . . . . . . . . . . . . . . 2967.3.5 Tivoli Decision Support for SAP R/3 . . . . . . . . . . . . . . . . . . . . . 2977.3.6 TDS for SAP R/3 Cubes and Related Reports . . . . . . . . . . . . . 2987.3.7 Examples of using TDS for SAP R/3 Analysis. . . . . . . . . . . . . . 299

7.4 Tivoli Global Enterprise Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 3047.4.1 Overview of Tivoli GEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3057.4.2 Installing Tivoli GEM for SAP R/3 management . . . . . . . . . . . . 306

v

7.4.3 Configuring Tivoli GEM for SAP R/3 management . . . . . . . . . . 3207.4.4 Using Tivoli GEM for SAP R/3 management . . . . . . . . . . . . . . . 3297.4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

Appendix A. Winrunner-Quicktest for R/3 test case . . . . . . . . . . . . . . . 345

Appendix B. Event classes for Tivoli Manager for R/3 . . . . . . . . . . . . . 347B.1 R3 alert event classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347B.2 R/3 operational event classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349B.3 R/3 Syslog event classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353B.4 Distributed monitoring event classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 357B.5 Special event classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358B.6 Tivoli GEM event classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

Appendix C. Monitor sources and their attributes . . . . . . . . . . . . . . . . 361C.1 OS collect source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361C.2 Roll area source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363C.3 Page area source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364C.4 Work process source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365C.5 Work process dispatch queue source. . . . . . . . . . . . . . . . . . . . . . . . . . . 366C.6 Long running work process source. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367C.7 Buffer source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367C.8 Performance source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369C.9 OS/390 DB2 source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369C.10 OS/390 source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Appendix D. TEC Rules and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373D.1 Event Classes: Distributed Monitoring based . . . . . . . . . . . . . . . . . . . . . 373D.2 Event Classes: Alert adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373D.3 Event Classes: Syslog adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374D.4 Event Classes: GEM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375D.5 Correlating events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375D.6 Rules: Handling duplicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376D.7 Rules: Handling harmless. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377D.8 Rules: Handling start up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378D.9 Rules: Handling mode switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379D.10 Rules: Handling shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380D.11 Rules: Handling application server down . . . . . . . . . . . . . . . . . . . . . . . 380D.12 Rules: Forwarding events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381D.13 Rules: Synchronizing R/3 with TEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 382D.14 Rules: Synchronizing TEC with R/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 383D.15 Rules: Handling Syslog alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383D.16 Rules: Drill down. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384D.17 Rules: Handling jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384

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

D.18 Rules: Handling GEM events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385D.19 Rules: Handling daemons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386D.20 Rules: Handling hosts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

Appendix E. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

Appendix F. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393F.1 IBM Redbooks publications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393F.2 IBM Redbooks collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393F.3 Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394F.4 Referenced Web sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395IBM Redbooks fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

List of abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

IBM Redbooks evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

vii

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

Figures

1. SAP R/3 three tier architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42. Initial SAPGUI login screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63. Complex ERP management environment . . . . . . . . . . . . . . . . . . . . . . . . . . 94. Tivoli’s integrated solution - SAP R/3 management. . . . . . . . . . . . . . . . . . 105. Tivoli product architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116. Example: Business systems management scenario . . . . . . . . . . . . . . . . . 237. Tivoli’s action for business systems management. . . . . . . . . . . . . . . . . . . 248. Tivoli Global Enterprise Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259. The Tivoli approach to managing application performance . . . . . . . . . . . . 2810. Example: Database management scenario . . . . . . . . . . . . . . . . . . . . . . . . 3211. Tivoli’s action for database management . . . . . . . . . . . . . . . . . . . . . . . . . 3312. Example of security groups and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4113. Typical output environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4414. Example of a NetView display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4715. Tivoli Manager for R/3 components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5016. The relationship between Tivoli Core Applications and R/3 Manager . . . . 5117. Tivoli Manager for R3 icon on Tivoli Desktop . . . . . . . . . . . . . . . . . . . . . . 5518. Contents of manager for R/3 Policy Region. . . . . . . . . . . . . . . . . . . . . . . . 5619. R/3 System on policy region: Manager for R3 . . . . . . . . . . . . . . . . . . . . . . 5720. Application server and database server in R/3 System . . . . . . . . . . . . . . . 5821. Distributing monitors and tasks in prior Version of R/3 Manager. . . . . . . . 5922. New format of distributing monitor and tasks. . . . . . . . . . . . . . . . . . . . . . . 6023. New TMR roles of manager for R/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6124. The example of application proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 6425. Tivoli Global Enterprise Manager Console . . . . . . . . . . . . . . . . . . . . . . . . 6526. Schedule setting for automatic discovery . . . . . . . . . . . . . . . . . . . . . . . . . 6727. R/3 System on policy region:Manager for R3 . . . . . . . . . . . . . . . . . . . . . . 6828. R/3 System properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6929. The status icons of application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7030. Task library: R3 configuration tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7231. Task library: R3 App Server tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7332. Display batch jobs output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7433. Job overview alphabetic on SAPGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7534. Cancel batch job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7535. Release batch job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7636. Display work process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7637. Work processes output after running the task . . . . . . . . . . . . . . . . . . . . . . 7738. Process overview on SAPGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7839. Cancel work process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7840. Add monitor to Sentry profile (long running work process) . . . . . . . . . . . . 80

© Copyright IBM Corp. 1999 ix

41. Add monitor to Sentry profile (work process). . . . . . . . . . . . . . . . . . . . . . . 8142. Add monitor to Sentry profile (work process dispatch queue) . . . . . . . . . . 8243. New TEC event source icons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9044. Endpoint method cache management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9245. R/3 Manager Endpoint methods handling . . . . . . . . . . . . . . . . . . . . . . . . . 9646. The Difference between dataless and classic profile manager . . . . . . . . . 9847. Application Proxy and Tivoli Object Database . . . . . . . . . . . . . . . . . . . . . 10348. Overview of our environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10849. Installing Application Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12350. Installing Tivoli Manager for R/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12551. New Manager for R3 icon on the desktop . . . . . . . . . . . . . . . . . . . . . . . . 12652. Policy region: Manager for R3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12753. R/3 Configuration task libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12754. R3 Profile Manager: R3 Transports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13155. Change to the dataless profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13256. Edit File Package properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13357. Unix Package Unix options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13458. Checking the development class J8C1 . . . . . . . . . . . . . . . . . . . . . . . . . . 13759. Checking active table structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13860. User list at SAPGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13961. Display R/3 instance profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14062. Assigning the new TMR roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14163. Create R/3 system from desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14264. Create R/3 application server from desktop. . . . . . . . . . . . . . . . . . . . . . . 14365. Create R/3 database server from desktop . . . . . . . . . . . . . . . . . . . . . . . . 14466. Configure Autodiscovery for UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14567. Task Library: R3 Configuration tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14668. Configure remote function call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14769. Configure remote function call output . . . . . . . . . . . . . . . . . . . . . . . . . . . 14770. Tivoli Manager for R3 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15171. Task Library: R3 configuration tasks (for Event Server) . . . . . . . . . . . . . 15372. Configure Event server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15473. Task Library: R3 Configuration tasks (for Event Console). . . . . . . . . . . . 15574. Configure event console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15675. Configure Event console output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15776. TME 10 Event server configuration (Event Group) . . . . . . . . . . . . . . . . . 15877. Tivoli Enterprise Console (for Event Source). . . . . . . . . . . . . . . . . . . . . . 15978. Task Library: R3 Configuration Tasks (for Event Adapter) . . . . . . . . . . . 16079. Configure Event Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16180. WR3MIB and WR3SLOG Event on TEC console . . . . . . . . . . . . . . . . . . 16281. Task Library: R3 App Server Tasks Collection . . . . . . . . . . . . . . . . . . . . 16482. Display Batch Jobs Execute Task Window . . . . . . . . . . . . . . . . . . . . . . . 16583. Display Batch Jobs Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

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

84. Display Batch Jobs Output Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16785. Task Library: R3 DB Server Tasks Collection . . . . . . . . . . . . . . . . . . . . . 16886. Edit Job for a Reference Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17087. Settings for the Job’s execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17188. Result of the Job Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17289. Edit the Profile: Configuring the R/3 SAPGUI Client File Package . . . . . 17390. Edit Job for a Native Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17491. Native Installation Job Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17592. Result of the Job Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17793. Edit the Profile: Configuring the R/3 SAPGUI Client Native Installation . 17894. Change to Dataless Profile Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17995. Cloning Profile into Dataless Profile Manager . . . . . . . . . . . . . . . . . . . . . 18096. Distributing the SAPGUI Client File Package . . . . . . . . . . . . . . . . . . . . . 18197. Example of SAPGUI Access on a Windows NT Client . . . . . . . . . . . . . . 18298. CCMS Alert Overview (Customized) - Transaction RZ20 . . . . . . . . . . . . 18499. Explanation for the Alerts and Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185100.Event Adapters and the Drill-Down Mechanism . . . . . . . . . . . . . . . . . . . 187101.Tivoli Distributed Monitoring in an SAP R/3 System . . . . . . . . . . . . . . . . 196102.Default Profile Managers, Subscription Lists and Profiles. . . . . . . . . . . . 200103.Monitoring Collections Provided by the Tivoli Manager for R/3. . . . . . . . 203104.The Default R3 App Server Profile Manager. . . . . . . . . . . . . . . . . . . . . . 205105.Predefined R3 Server Autodiscovery Monitors . . . . . . . . . . . . . . . . . . . . 206106.Predefined R3 Server Remote Monitors . . . . . . . . . . . . . . . . . . . . . . . . . 207107.Distributing Monitoring Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208108.Starting Alert Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209109.TEC Event Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210110.Modifying a Default Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211111.Profile Properties to Add a New Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 212112.Creating New Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213113.Creating New Monitor: Edit Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214114.Select Indicator Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215115.Indicator Collection List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216116.Work Process Monitor Event on TEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 217117.Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220118.An example of the enterprise stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228119.Tivoli Enterprise Management Approach . . . . . . . . . . . . . . . . . . . . . . . . 229120.Typical SAP R/3 Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234121.Illustration of Event Management Design and Monitoring Design. . . . . . 247122.Example of a Worksheet for Event Source: AIX errlog . . . . . . . . . . . . . . 259123.Tivoli Application Performance Manager Components . . . . . . . . . . . . . . 273124.Adding the TAPM Notice Group to the Administrator . . . . . . . . . . . . . . . 275125.Adding Marprofile to the pokibmtapm Policy Region. . . . . . . . . . . . . . . . 276126.Creating a TAPM Profile Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

xi

127.Creating a Blank Monitoring Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278128.Adding Applications to a Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279129.The Schedule Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280130.Adding a Monitoring Rule to a Schedule . . . . . . . . . . . . . . . . . . . . . . . . . 281131.Database Settings Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282132.Application Added to Application Availability Profile . . . . . . . . . . . . . . . . 283133.Adding Subscribers to the Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284134.Distributing the Monitoring Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285135.Tables Created by Create Database Script. . . . . . . . . . . . . . . . . . . . . . . 287136.Initial Screen of Winrunner-Quicktest for R/3 . . . . . . . . . . . . . . . . . . . . . 288137.Adding an SAP Connect Step to a Business Process. . . . . . . . . . . . . . . 289138.sm37 Step From Winrunner Testcase. . . . . . . . . . . . . . . . . . . . . . . . . . . 291139.Simulation Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292140.Tivoli Decision Support Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 294141.TDS Architecture Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296142.Cubes and related reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298143.Example 1: R/3 load balance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 300144.Example 2: R/3 Service Level Agreement. . . . . . . . . . . . . . . . . . . . . . . . 301145.Example 3: R/3 response time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302146.Example 4: R/3 load balance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 303147.Example 5: R/3 load balance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 304148.The Interactions between Tivoli GEM Components . . . . . . . . . . . . . . . . 306149.Software Configurations on Each Tivoli GEM Component . . . . . . . . . . . 307150.Downloading Java Development Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310151.Tivoli GEM Topology Server Installation . . . . . . . . . . . . . . . . . . . . . . . . . 311152.Tivoli GEM Topology Server Installation Completion . . . . . . . . . . . . . . . 312153.Tivoli GEM Event Enablement Installation . . . . . . . . . . . . . . . . . . . . . . . 313154.Tivoli GEM Event Enablement Installation Completion . . . . . . . . . . . . . . 314155.Tivoli GEM Topology Console Installation. . . . . . . . . . . . . . . . . . . . . . . . 315156.Tivoli GEM Topology Console Installation Completion . . . . . . . . . . . . . . 316157.Tivoli GEM Topology Console Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317158.Tivoli GEM Instrumentation for R/3 Manager Installation . . . . . . . . . . . . 318159.Tivoli GEM Instrumentation for R/3 Manager Installation Completion. . . 319160.Instrumentation Task Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320161.Configuring TEC Event Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322162.Creating Tivoli GEM Console User Group . . . . . . . . . . . . . . . . . . . . . . . 323163.Importing Application Management Package File . . . . . . . . . . . . . . . . . . 325164.Send GEM Heartbeat Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326165.Executing the Send GEM Heartbeat Task . . . . . . . . . . . . . . . . . . . . . . . 327166.The Send GEM Heartbeat Task Completion. . . . . . . . . . . . . . . . . . . . . . 328167.TEC Events of the Send GEM Heartbeat Tasks . . . . . . . . . . . . . . . . . . . 329168.Tivoli GEM Console Sign On Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 330169.Tivoli GEM Console Initial Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

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

170.The Plan Mode Screen of Tivoli GEM Console . . . . . . . . . . . . . . . . . . . . 332171.The Verify Mode Screen of Tivoli GEM Console. . . . . . . . . . . . . . . . . . . 333172.The Control Mode Screen of Tivoli GEM Console . . . . . . . . . . . . . . . . . 334173.SAP R/3 Managed Resources Topology Information . . . . . . . . . . . . . . . 335174.Displaying SAP R/3 Resource Properties . . . . . . . . . . . . . . . . . . . . . . . . 337175.The Pull-Down Menu Bar of SAP R/3 Application Server . . . . . . . . . . . . 338176.Tivoli GEM Console Event Viewer Screen . . . . . . . . . . . . . . . . . . . . . . . 339177.The Tivoli GEM Event Viewer Properties . . . . . . . . . . . . . . . . . . . . . . . . 340178.The Result of the Display_Buffer_Info Task Execution . . . . . . . . . . . . . . 341179.The Running Monitors Status of SAP R/3 Application Server . . . . . . . . . 342180.The Unknown Status SAP R/3 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . 343181.Winrunner-Quicktest for R/3 test case (1/2) . . . . . . . . . . . . . . . . . . . . . . 345182.Winrunner-Quicktest for R/3 test case (2/2) . . . . . . . . . . . . . . . . . . . . . . 346

xiii

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

Tables

1. List of Operating and Database Systems that SAP R/3 Supports. . . . . . . . 52. Summary of Tivoli’s Management Solutions . . . . . . . . . . . . . . . . . . . . . . . 113. Functions and benefits of Tivoli Manager for MQSeries . . . . . . . . . . . . . . 344. Some advantages of Tivoli Workload Scheduler for R/3 . . . . . . . . . . . . . . 365. The Relationship between R/3 Roles and Tivoli Basic Roles . . . . . . . . . . 616. Description and Location of two De-install Scripts. . . . . . . . . . . . . . . . . . . 867. Installation Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208. Log Files for Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1839. Monitoring Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21810. Element List: Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24211. Element List: Network Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24412. Element List: All Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24413. Tivoli Manager for R/3 Monitors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24814. Tivoli Manager for Domino/Notes Monitors . . . . . . . . . . . . . . . . . . . . . . . 25015. UNIX Monitoring Collection: Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25016. UNIX Monitoring Collection: Specific . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25117. Universal Monitoring Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25318. TME Monitors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25419. Oracle Monitoring Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25420. Windows NT Monitoring Collection: Default. . . . . . . . . . . . . . . . . . . . . . . 25521. Windows NT Monitoring Collection: Specific . . . . . . . . . . . . . . . . . . . . . . 25722. Configuration Details for out TAPM Database . . . . . . . . . . . . . . . . . . . . . 28623. Tivoli GEM Software Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30724. R/3 Alert Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34725. R/3 Operational Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34926. R/3 Syslog Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35327. Distributed Monitoring Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 35728. Special Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35829. Tivoli GEM Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35830. OS Collect Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36131. Roll Area Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36332. Page Area Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36433. Work Process Source (Attribute 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36534. Work Process Source (Attribute 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36535. Work Process Dispatch Queue Source . . . . . . . . . . . . . . . . . . . . . . . . . . 36636. Long Running Work Process Source (Attribute 1) . . . . . . . . . . . . . . . . . . 36737. Long Running Work Process Source (Attribute 2) . . . . . . . . . . . . . . . . . . 36738. Buffer Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36739. Performance Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36940. OS/390 DB2 Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

© Copyright IBM Corp. 1999 xv

41. OS/390 Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

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

Preface

Effective management of a large-scale SAP R/3 environment requires thateach layer of the underlying IT infrastructure - networks, systems, databases,middleware, and applications - be addressed under a single, integrated, andcentralized monitoring and reporting environment. Using thismultidisciplinary, "big picture" approach, companies can remain proactive indeploying and monitoring SAP applications and the associated infrastructurecomponents that may impact access to business critical data.

Tivoli’s management products for SAP R/3 build on core Tivoli managementapplications and support the Tivoli approach to unified, comprehensiveenterprise management. This approach allows R/3 to be managed as part ofthe enterprise and with the same tools that are used to manage the entireenterprise. Tivoli Enterprise software allows organizations to simplify themanagement of complex environments with offering like the Tivolimanagement solution for R/3, enabling continual operation of systems thatdrive customers' businesses.

In this redbook, we describe the intricacies of managing a large-scale SAPR/3 environment using the Tivoli Enterprise Software products. Specialattention is given to the cornerstone of Tivoli’s solution for R/3 management -The Tivoli Manager for R/3. This redbook details the setup and use of thelatest version (2.0) of the Tivoli Manager for R/3. In addition, we also focus onthe other components of Tivoli’s comprehensive solution for SAPmanagement. These products include Tivoli Database Manager Product thatenables management of SAP’s underlying database, Tivoli Decision Supportfor SAP R/3 that enables an analysis of SAP R/3 system activities, TivoliApplication Performance Management that allow you to measure SAP R/3performance, as well as Tivoli Global Enterprise Manager that enables abusiness systems topology view of the SAP environment.

Detailed scenarios are documented for use by customers or service providersin client engagements.

The team that wrote this redbook

This redbook was produced by a team of specialists from around the worldworking at the International Technical Support Organization, Austin Center.

Yoichiro Ishii is an Advisory I/T Specialist working as a project leader at theInternational Technical Support Organization Tivoli Group, Austin Center. Hemanages Tivoli projects and develops technical documents including

© Copyright IBM Corp. 1999 xvii

redbooks on Tivoli Enterprise topics. He also teaches IBM classes worldwideon all areas of systems management, application management, and networkmanagement. Before joining the ITSO in mid-1998, Yoichiro worked at IBMJapan as an I/T Specialist for systems and network management, consultingmajor IBM customers. In this role, he architected systems managementdesign and solution for large government projects. He can be reached [email protected].

Jamie Cooper is the Managed SAP Operations Team Leader at NorthHarbour, IBM United Kingdom. He has worked on SAP R/3 related projectssince he joined IBM in May, 1997. He has specialised in AIX, SAP R/3, andLotus Notes. He helped to build the Managed SAP Operations team, which hefinds himself the team leader of at this time. He is also a Lotus Notesdeveloper, when time permits, and has written several Notes applicationstailored towards operations use. He is also responsible for writing a largeamount of educational and technical documents for his, and other operations,departments.

Yasuko Takada is an IT Engineer in Japan. She has several years ofexperience in the Tivoli Systems Management field. She has worked at theIBM Systems Engineering field support department for three years. She hasjoined a customer project deploying workstations with Tivoli systemmanagement products on large environment.

Andre Wahjudi is an advisory I/T Specialist with IBM Netherlands. He joinedCIMAD Consultants BV in January of this year as a SAP IT Consultant (whichrecently became IGS BMS/ERP Services). Since he joined IBM in August1996, Andre has worked on the Tivoli Systems Management area for severalmultinational clients with the focus on SAP Management. In these Tivoliprojects, he has also been involved in the design, implementing, and supportof the solution. Andre is a certified SAP Consultant and holds an ElectricalEngineering degree from Delft University of Technology.

Edson Manoel is an Advisory ITSO representative working as a projectleader at the International Technical Support Organization, Tivoli Group,Austin Center. He applies his extensive field experience as an I/T TivoliSpecialist to his work at the ITSO where he writes extensively on all areas ofsystems management. Prior joining the ITSO, Edson worked at IBM BrazilProfessional Services Organization as an I/T Architect where he was involvedin numerous projects, designing and implementing systems and networkmanagement solutions for major IBM Brazil customers.

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

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

Poonam DhawanTivoli Systems

Bill MelolingTivoli Systems

Ellen DicksonTivoli Systems

Ron ChervenyTivoli Systems

Stefan UelpenichTivoli Systems

Angela PittsTivoli Systems

Jay KruemckeTivoli Systems

Monte CopelandTivoli Systems

Tom HaywoodTivoli Systems

Charles BrownIBM UK

Carsten SieglerIBM Germany

David A WhiteIBM Global Service

Delmos GaierIBM Gloval Service

Gene CapanoIBM Gloval Service

Greg GrethIBM Gloval Service

xix

Cyndi ChapmanIBM Gloval Service

John OwczarzakInternational 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 yourcomments about this or other redbooks in one of the following ways:

• Fax the evaluation form found in “IBM Redbooks evaluation” on page 409to 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 [email protected]

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

Chapter 1. Introduction

In this chapter, we introduce the SAP R/3 application system and the Tivolimanagement strategy for applications in general and for SAP R/3 specifically.We give a brief overview of the current business data processing situationand provide an explanation of enterprise resource planning. Also included isan overview of any additional modules to the Tivoli Enterprise Solution thatwere implemented during the course of this project. This includes adescription 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 anunsuitable resource for serious business data processing. However, the tightintegration of single and multi-user systems in today’s world is a standardfeature of modern business applications.

Not until the wide dissemination of PCs during the early to mid 1980s werethe conditions set for an entirely new way of thinking. At first, the PC waslargely ignored as a platform for business data processing. Then, for severalyears it was thought that the PC could act as a graphical front end for abusiness application; however, the business application would still have to runon a central machine. Unfortunately, this approach was not revolutionaryenough to achieve real progress in the design of commercial applications. Notuntil the second half of the 1980s, with the market success of linked PCsolutions, which were based on Local Area Networks (LANs), did a newapproach win out. That approach was the client/server principle.

However, there is a drawback to the seemingly wonderful world of theclient/server: Not every client/server architecture is suited for implementingcompany-wide applications. This is especially true of applications that canonly separate the graphical user interface (GUI) from the closely tiedapplication and database functions. In this case, the scalability of the systemis extremely limited since the monolithic system of application and databasefunctions 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 onseparate computers, has prevailed as a viable foundation for company-wideclient/server solutions. This architecture provides the foundation for acompletely new generation of business applications; a generation which isdistinguished by sophisticated GUIs, interfaces to external applications, useof multimedia technology, functionality that is unimpaired by scarce

© Copyright IBM Corp. 1999 1

resources, high performance, and expansive scalability. The limit of the abilityto develop such systems is reached only when reliable system managementand 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 aproactive business tool? Competitive market pressures, such as continualprice erosion and short product life cycles, have prompted many companiesduring the last decade to turn to technology to meet these challenges.

As the 1990s unfolded, software vendors began to connect a wide range ofbusiness functions and enterprise wide solutions began to emerge as financeand accounting, sales-order administration, procurement, logistics, and avariety of other business functions were interconnected with manufacturingand material planning software applications. The early 1990s gave birth tofull-function ERP (Enterprise Resource Planning) systems that integratedbusiness functions, shared common data, and provided connectivity with asingle interface. Soon after, the ERP marketplace exploded. Single-sourcetransaction processing engines linked internal operating segments, includingfinance, manufacturing, purchasing, order administration, and logistics.Packaged software, fueled by reliable hardware, modern databases, andhuge information technology advances, offer tremendous businessfunctionality to even the largest enterprises. Continued advancements inhardware and middleware technologies have enabled worldwide connectivityof ERP systems throughout an enterprise.

Offering integrated common processes, globally shared data, and shortenedtransaction cycle times resulting in reduced administrative costs, ERPsoftware products represent some of today’s ground-breaking technology.

1.3 ERP - The backbone of e-business

The rise of e-business technologies has caused a fundamental change in theway companies interact, both with their customers and their trading partners.Today, companies realize that it is critical to establish their e-businessstrategy in relation to ERP. ERP contains a tremendous degree of access toand control over critical business information. ERP brings all of a company’sdata together in real time, making it possible to gain unprecedented insightinto how the business is performing and where it is headed.

With "enterprise" now being extended beyond the traditional boundaries ofthe organization to include customers and suppliers, the importance of

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

well-managed, supply-chain-enhancing processes is heightened. As theorganization’s mission critical transaction system, ERP has evolved tobecome the "Enterprise application backbone" supporting the extended valuechain to create new business processes. ERP vendors have responded tothis dramatic shift in the way business is being conducted by evolving to xRP- extended ERP. xRP involves extending ERP applications to integrate thevalue 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 tobecome the world’s fourth largest independent software supplier.

With headquarters in Walldorf, Germany, five former IBM employees startedSAP in 1972. From its inception, SAP approached application software from abusiness perspective. The original idea of SAP was to provide customers theability to interact with a common corporate database for a comprehensiverange of applications. By collaborating with business and IT executives, andpartners worldwide, SAP developed a unique understanding of thechallenges faced in implementing technology solutions for business users.Gradually, the applications have been assembled, and today manycorporations including IBM and Microsoft, are using SAP products to run theirbusiness.

SAP applications built around the latest R/3 (release 3) system provide thecapability to manage financial, asset, cost accounting, production operationsand materials, personnel, plants, and archived documents. The system usesthe client server model and runs on multiple platforms, including Windows NTand UNIX.

Since the introduction of Web interfaces and a scalable, Internet-readyarchitecture in 1996, SAP has been working with companies making thetransition to the Internet business model. It is now focused on inter-enterprisesoftware solutions that integrate the processes within and among enterprisesand business communities.

1.5 What is SAP R/3?

This section only provides a brief overview of SAP R/3. For more in depthinformation on SAP R/3, refer to the appropriate R/3 materials.

Introduction 3

SAP R/3 is a client/server application system used for Enterprise ResourceManagement (ERP). R/3 has many modules that allow the modelling of allparts of the enterprise business and can manage data from finance, sales,accounting, manufacturing, human resources, and other businessdepartments.

R/3 allows the customer to integrate business data and processes. R/3 canact as a catalyst for change, as it not only allows the customer to automatebusiness processes using information technology but also can be used todrive changes to the business processes themselves.

R/3 has a multi-tier architecture with the following components:

• 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 allrun on different operating systems including Windows NT and all major UNIXplatforms.

DatabaseServer

ApplicationServers

Presentation Clients


Traditionally, there is one database server in an R/3 system. This can be astand-alone or run in parallel with an R/3 application on the same server. Thedatabase 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 forRS/6000 or OS/390. The protocol used for communication between the threemain components of the R/3 system is TCP/IP unless DB2 for OS/390 hasbeen used for the R/3 database, in which case, UDP is also used. Thefollowing table gives a quick reference of which operating systems supportwhich database systems. Only the most widely used databases and operatingsystems supported by SAP R/3 are listed:

Table 1. List of Operating and Database Systems that SAP R/3 Supports.

Access to the R/3 system is achieved by a presentation client, often called theSAPGUI, which is available on all major operating system platforms and is astand-alone package. Users log in from presentation clients to the R/3application servers via the SAPGUI. The application servers, in turn,communicate with the database server. Application servers can also run onWindows NT and all major UNIX platforms.

SAPGUI is available for the platforms listed previously and additionally forWindows 95, Windows 98 and OS/2. The following figure shows an exampleof the initial login screen of the SAPGUI on Windows 95 or Windows 98:

Database System Operating System

DB2 All Major UNIX PlatformsIBM OS/400IBM OS/390

Oracle Windows NTAll Major UNIX Platforms

Informix Windows NTAll Major UNIX Platforms

Microsoft SQL Server Windows NT

Introduction 5

Figure 2. Initial SAPGUI login screen

An R/3 system is comprised of one database server and one or moreapplication servers as well as the presentation clients. The R/3 system isidentified by a three-character system identifier (SID), such as DEV, TST,FP7, and so forth. The SID allows the grouping of the database server andthe application servers, and it identifies the R/3 system as a whole.

Instances are assigned to the application servers in the R/3 system. Aninstance is a single R/3 application running on any application server. It ispossible to run multiple instances on a single application server; however, this isnot common and is rarely seen in IBM internal implementations of R/3. Of theinstances in an R/3 system, one is deemed the Central instance. Usually, inIBM internal implementations of R/3, this is the machine that either holds theDB2 for RS/6000 database server, as well as an SAP instance, or it has theconnection to the OS/390 LPAR that holds the DB2 for OS/390 database.

R/3 has many additional components that have not even been mentionedhere, 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 stilla new buzzword. The company correctly foresaw that the typical largeorganization would want to combine all its computers, databases, andbusiness applications into a single integrated network computingenvironment.

Tivoli also foresaw that the cost and complexity of systems and networkmanagement would be a major barrier to network computing. Existingmanagement solutions could not be integrated to support network computingbecause each of these solutions has been developed to solve one particularproblem on one computing platform. This meant that customers would have touse multiple management solutions and employ multiple teams with multipleskills.

To overcome the cost and complexity, customers would require a singlenetwork computing management solution. This would have to be anintegrated solution that could manage all the systems, databases, andapplications in a network as well as the network itself. However, it wasunlikely 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 industryaround it, an industry that would be based on standards and cooperation.

During the next eight years, Tivoli pursued this opportunity. Working closelywith partners, they developed and refined the Tivoli ManagementEnvironment (TME). This was the first and only software specifically designedfor the seamless management of an entire enterprise from desktop to datacenter.

Tivoli merged with IBM in March, 1996. The Tivoli Systems name hasremained, and it has become an independent business unit of IBM. Beforethe merger, IBM had its own systems management product line known asSystemView. Tivoli’s products were known collectively as TME 3.0. Themerger allowed the best of both product lines to be combined into oneoffering called TME 10. In current versions of Tivoli, the TME 10 brand namehas been phased out, and all applications are known collectively as the TivoliEnterprise Software.

Introduction 7

1.7 SAP management challenges

Since SAP applications depend on information from numerous corporatesystems, it is not enough to simply monitor the applications alone for "redalerts". What if a problem occurs in the middleware as data is translated fromthe mainframe to another server for use in a SAP solution? Where does ITlook when the sales force cannot access product delivery information? Is it aproblem with the SAP solution? The integrated sales automation package? Orperhaps, the problem is in the database feeding the SAP application.

In the past, companies developed islands of management - separateorganizations and tools that addressed once seemingly separate issues;network management, mainframe management, database management, LANmanagement, and desktop management. Yet with the increasing complexityof today’s environments, transforming systems management to a centralized,integrated approach has become a necessity to optimize the use ofinformation across an organization.

Managing the complete SAP R/3 environment means extending managementbeyond the monitoring and control of network devices, system platforms, andmiddleware such as MQSeries, and production services. It adds specializedmanagement for application events, application jobs and output, applicationsoftware distribution, and application service levels. This specializedmanagement enables R/3’s IT and business owners and users to understand,control, and improve business systems that use or interact with R/3. Therange of management disciplines spans security, problem and changemanagement, job scheduling, output management, event monitoring andcorrelation, help desk, software distribution and configuration, and IT assetinventory management.

1.8 The Tivoli Management Environment

Consistent and centralized management of distributed systems of differentbrands and architectures is crucial to large customer environments. Tivoli’sapplications are a suite of distributed systems management products thathave been gaining a lot of attention within IBM and among customers sincethe merger between IBM and Tivoli.

The current computing environment relies more and more on distributedclient/server setups for information system needs where users at the clientworkstations perceive the network as one big server or service provider.Distributed computing or network computing ties people, information, andresources more closely together. However, this brings a challenge when


considering the management of these systems. Managers face the complexproblem of maintaining many different types of hardware and operatingsystems.

Tivoli provides a way to manage network computing resources of manydifferent types from a single point. Tivoli products provide a consistentinterface to different operating systems and services. Tivoli allowsadministrators to control users, systems, and applications from one desktop.It also provides a streamlined way to automate and delegate routine, timeconsuming tasks.

Figure 3. Complex ERP management environment

1.9 Tivoli’s management solution for SAP R/3

Tivoli’s solution for managing the SAP R/3 environment is one of the mostcomprehensive solution available in the market today. Tivoli offers a completeset 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 thismulti-disciplinary, "big picture" approach, companies can remain proactive indeploying and monitoring ERP applications and the associated infrastructurecomponents that may impact access to business critical data.

Tivoli’s R/3 management solution covers the full cycle and range ofmanagement requirements for the SAP R/3 environment. Tivoli’s SAP R/3

Change Management• Planned IT rollouts• Impact analysis to avoid

potential problems• Automated software

distribution

Problem Management• Centralized correlation of

network, system, database,and application events

• Performance managementSecurity Management• Centralized user

administration• Access control• Global sign-on

Decision Support• Service level management• Business relevant analysis to

drive policies, budgets, resourceallocations

Operations Management• Workload scheduling• Output management

Service Management• Service level agreements• Escalations/notifications• Knowledge content

ERP

Storage Management• Fast, reliable restore / backup• Disaster recovery management

Introduction 9

solution combines specialized products such as Tivoli Manager for R/3, TivoliWorkload Scheduler Extended Agent for SAP R/3, and Tivoli Service Desk forR/3 with Tivoli’s standard management products. These products includeTivoli Enterprise Products; Tivoli Distributed Monitoring for eventmanagement 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 managingenterprise applications; Tivoli Security Management and Tivoli GlobalSign-On for enhanced security, plus Tivoli Workload Scheduler for jobscheduling; Tivoli Output Manager; and Tivoli Data Protection for SAP R/3 forbackup and recovery R/3 data (refer to Figure 4).

Figure 4. Tivoli’s integrated solution - SAP R/3 management

1.10 Tivoli Product Architecture

The Tivoli applications all share a common framework called the TivoliManagement Framework. The Tivoli Framework is open and object-orientedand includes a set of managers, brokers, and agents that conform with theCommon Object Request Broker Architecture (CORBA) specificationsproduced by the Object Management Group (OMG). This technology allowsmajor differences between computer operating systems to be hidden from theTivoli users and allows the encapsulation of key services in objects that canbe used by multiple management applications. To put this in more simple

MQSeries

DB2

\60\65

10

1520

25

30

35Oracle

WorkloadScheduling

DatabaseManagement

MiddlewareManagement

SecurityManagement

OutputManagement

Service Levels

Service Desk

DesktopManagement

ERPManagement

UserAdministrationLegacy system


terms, it allows for platform-independence, a unifying architecture, and theability of third-party vendors to easily adapt to the Tivoli Framework.

The following figure shows the relationship between the Tivoli Framework andsome of the additional modules in the Tivoli Architecture.

Figure 5. Tivoli product architecture

1.11 Summary of Tivoli’s management solutions

The following table (Table 2) gives a brief description and indication of the keystrengths of the Tivoli solutions discussed in this chapter. It also indicates foreach product what the prerequisites are in terms of other Tivoli products:

Table 2. Summary of Tivoli’s Management Solutions

TivoliSolution

Description Prerequisite Key Strengths

TivoliManager forR/3

Specialized SAPmonitors, softwaredistribution file-packs,CCMS event mapping,automation rules, tasks,and classes.

Tivoli FrameworkTivoli SoftwareDistributionTivoli EnterpriseConsoleTivoli DistributedMonitoring

Breadth of R/3managementfunctions. Integrationwith application,system, and networkmanagement. Secureinterface to R/3.

S ecurity P o lic ie s

D a ta M essag ing

Tivo liInven to ry

Tivo liS oftwa re D is tribu tion

Tivo liD is tr ibu ted M on ito ring

Tivo liU se r A dm inis tratio n

T ivo liS ecurity

M an age m ent

Tivo liE n terpr ise C onso le

Tivo liM a es tro

Tivo liO u tp ut

M an age r

Tivo liD ec is ionSu ppo rt

Tivo liG lobal

E n terpr iseM ana ger

Tivo liA D S M

TivoliA pplicatio n

P erform a nceM an ager

Tivo liF ram ewo rk

Introduction 11

TivoliDistributedMonitoring

Event correlation,management, andautomated response,which apply policyacross the enterprise.

Tivoli Framework Breadth of platforms.Scalability. Flexibilityfor defining events andfiltering views.

TivoliEnterpriseConsole

Presents eventinformation and is thelaunching pad formanagement tasks.

Tivoli Framework Integration with Tivoliand partnersmanagementapplications andability of correlatingthe events.

Tivoli GlobalEnterpriseManager

Provides a businesssystem view that allowsmanagement andcontrol of multipleintegrated softwarecomponents required todeliver a specificbusiness service.

Tivoli Frameworkand coreapplications

GEM monitors thestate of discreteapplications as well asthe relationships anddata flow betweeninterconnectedapplications and thedependenciesbetween applicationsand physicalresources.

Tivoli GlobalSign-On

Provides a secure andeasy to use solutionthat grants usersaccess to thecomputing resourcesthey are authorized touse with just one logon.

Tivoli FrameworkTivoli UserAdministrationTivoli SoftwareDistribution

Removes the needfor end-users tomanage multipleuser-IDs andpasswords.Simplifies user IDmanagement.

TivoliWorkloadScheduler

Uses common policiesto manage jobschedules acrossplatforms andapplications.

n/a Integrates R/3 batchworkloads with otherapplication jobschedules.

TivoliSolution



TivoliDecisionSupport

Reporting and analysisvia Online AnalyticalProcessing (OLAP)enables exploration ofmanagement data toevaluate trends, analyzeevent impact, planupgrades, preventrecurrence of problems.

Tivoli FrameworkTivoli EnterpriseConsole

Integrates disparatedata from multiplesources to examinekey indicators from avariety of angles.

TivoliDatabaseManagementProducts

Predefined monitors forunattended monitoringof databaseperformance andavailability. Task librariesautomate routineadministrative tasks.

Tivoli FrameworkTivoli SoftwareDistributionTivoli EnterpriseConsoleTivoli DistributedMonitoring

Database breadthincluding DB2,Microsoft SQL Server,Oracle, Sybase, andInformix.

TivoliManager forMQSeries

Centralizedmanagement of IBMMQSeries. Providessoftware distribution,administration, andconfiguration ofMQSeries

n/a Business systemperspective.Out-of-bandMQSeries healthmonitoring.Multidomain, crossplatformadministration.Correlates eventsoutside MQSeries.

TivoliSoftwareDistribution

Uses Tivoli Inventory orother query to selecttargets for push or pulldistribution. Fans outdistribution service toregional servers.

Tivoli Framework Breadth of Platformscovered. Scalability.

TivoliOutputManager

Delivers any output toany user based oncentral policy and userpreferences. Ensuresthat R/3 printingcompletes.

n/a Breadth of output andplatform coverage.Central policy allowsuser participation inoutput decisions.

TivoliSolution


Introduction 13

Tivoli ADSM Provides centrallymanaged and scheduledstorage managementand disaster recoverybackup for R/3 and anyother enterprise data.

n/a Breadth of data andplatforms covered.Speed andautomation of backupand hierarchicalstorage management.Fault recoverycapabilities.Repeatable, reliablebackup and recoveryof R/3.

TivoliApplicationPerformance Manager

Uses Applicationinstrumentation,Transaction simulation,and Client capture inconjunction with aback-end process formanaging the measureddata.

Tivoli Framework Because it covers allthe differentmeasurementtechniques, it providesthe basis for accuratemeasurement andreporting.

TivoliNetview

Tivoli solution focusedon managing IP-basednetworks. GeneratesSNMP traps that aredisplayed in a centralevent window.

Tivoli Framework Simple to use andconfigure. Gives theability to view thestatus of the whole IPnetwork at once.

Tivoli UserAdministration

Extends the capabilitiesof the Tivoli environmentto allow themanagement of useraccounts on a number ofplatforms including R/3.

Tivoli Framework CentralizedGUI-based control ofadministration tasks.Consistentadministrative policydefinition. Automationof repetitiveadministration tasks.

TivoliSecurityManagement(LockdownModules)

A system or applicationspecific Tivoli SecurityProfile that can bemodified to match anenvironment, appliedon an endpoint, andthen tested to lockdowna specific system orapplication.

Tivoli FrameworkTivoli SecurityManagement

Makes Tivoli SecurityManagementsimpler. Allows andencourages theexchange ofknowledge andexperience.

TivoliSolution



The following sections describe overview of each Tivoli Enterprise Productsthat enable highly integrated SAP R/3 management.

1.11.1 Tivoli Management FrameworkThe Tivoli Management Framework is the backbone of the Tivoli solution andthe basis for all Tivoli systems management applications. The TivoliFramework provides the basic systems management services, such ascommunications, presentation, security, and so forth, that all the Tivolisystems management applications use, therefore, ensuring consistency andintegration.

All Tivoli systems management tasks, regardless of the application orcomponent that is to be managed, are performed using the Tivoli Desktop,which provides a user interface consistent throughout Tivoli managementapplications.

1.11.2 Tivoli Distributed MonitoringTivoli Distributed Monitoring is the Tivoli application for monitoring systemsand applications. Distributed monitoring is tightly integrated with the TivoliFramework and provides monitoring capabilities for a wide range of systemsand components. The strength of distributed monitoring is that monitoringcollections for components can easily be added, thus, allowing the monitoringof any kind of component.

1.11.3 Tivoli Enterprise ConsoleThe Tivoli Enterprise Console (TEC) provides a central event display andcorrelation for the enterprise regardless from which source the events areoriginating. Unlike traditional SNMP managers, Enterprise Console usesevent adapters that can convert any kind of event stream into TivoliEnterprise Console events that can then be processed by the EnterpriseConsole. Event adapters are available for a wide range of systems andapplications.

The major strength of the Tivoli Enterprise Console is that events from anykind of system can be displayed and, more importantly, be correlated into oneplace. This allows, for example, correlating a network event that comes fromNetView with an application event coming from R/3 and triggering an actionas a result of the correlation.

Introduction 15

1.11.4 Tivoli Software DistributionTivoli Software Distribution provides a simple and reliable service to distributesoftware in the enterprise across platforms and networks. SoftwareDistribution has such features as fan-out and bandwidth optimization.Software is grouped in file packages that Software Distribution can thenautomatically distribute to the desired targets.

Many applications require distribution of components or data across thenetwork. This function can be provided by Software Distribution. For example,the Tivoli Manager for R/3 provides utilities that assist in the creation of filepackages. This means that the SAPGUI component can be automaticallydeployed to a large number of presentation clients.

1.11.5 Tivoli Manager for SAP R/3Tivoli Manager for R/3 is the foundation of Tivoli's comprehensive, reliable,and cost-effective SAP R/3 management solution. It seamlessly integratesthe management of R/3 with the rest of the enterprise by monitoring R/3resources, managing R/3 alerts, automating routine tasks, and deployingsoftware for R/3 desktops. Tivoli Manager for R/3 maximizes your R/3investment by building on the Tivoli Enterprise environment. Together theyprovide a common management infrastructure and comprehensive set ofmanagement tools for enterprise R/3 management.

Tivoli Manager for R/3 consolidates management of multiple R/3 systems thatuse different versions of R/3 and integrates this management with the rest ofthe enterprise environment. It manages the monitoring and operational tasksfor R/3 production, testing, development, and training environments from onecentral location and captures and reports events from all R/3 systems.Through the Tivoli Enterprise Console, Tivoli Manager for R/3 manages thedisplay of valid events as a function of R/3 server availability. The informationof these events can be processed with the events’ information about theoperating system, the network, the database, and other related components.This provides an overall picture on how the R/3 environment is performingand helps operators quickly identify and resolve the cause of any availabilityproblems.


1.11.5.1 Availability and PerformanceThe ability to productively use the R/3 system depends on many resourcesincluding databases, application servers, networks, and even the R/3 clientsoftware on workstations. Tivoli Manager for R/3 provides more than 250monitors for R/3, in addition to thousands of monitors provided by TivoliEnterprise.

The monitors provide capability for automated monitoring of the R/3 systems.For example, one of the monitors periodically checks for processes that havebeen running too long - a common indication of a more serious problem.Tivoli Manager for R/3 automatically detects this potentially serious situation24 hours a day, 7 days a week.

Monitors are only one source of information about the R/3 systems. SAPmaintains a system log (syslog) that contains detailed information about theworkload and events within the R/3 system. Via the R/3 Syslog EventAdapter, Tivoli provides automated access to information in the SAP syslog.You can define which syslog messages, including severity, should be sent toTivoli Enterprise Console. Because Syslog Event Adapter filtering and eventseverity are conducted outside of R/3, you can employ common syslog eventstandards for multiple R/3 systems without having to configure each R/3system. The Syslog Event Adapter can process every syslog event, evenwhen several events occur simultaneously.

1.11.5.2 Proactive Problem DetectionTivoli Manager for R/3 proactively identifies potential problems before theyaffect R/3 users using a comprehensive collection of monitors and events.The information is collected from several sources including R/3'sSAPOSCOL, Tivoli Distributed Monitoring, and information available throughthe R/3 Computing Center Management System (CCMS). The importantinformation from across the R/3 landscape and supporting components iscorrelated by the Tivoli Enterprise Console if you have configured properly.This means that it is possible to prevent many R/3 alert situations from

The Tivoli Manager for R/3 used during the course of this redbook was abeta code version. The versions of SAP R/3 that are supported by thisproduct are subject to change at any time before or after release of themodule.

The R3System name used in this redbook has dbhostname_SID, while theactual product has SID_dbhostname.

Note

Introduction 17

happening and automate actions for specified problems using the rulesmechanism.

Monitors included with Tivoli Manager for R/3 provide information about CPUutilization, CPU load average, available physical memory, paging, swapspace, disk utilization and response time, and all other values displayed bythe R/3 transaction ST06. Tivoli Manager for R/3 also displays informationconcerning 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 valuesdisplayed by R/3 transaction ST02. For the DB2 database on OS/390, Tivolitracks additional values including buffer pool-hit ratios, shortages and pageinformation, and deadlock and lock time outs.

1.11.5.3 Efficient OperationsWith Tivoli's unique policy-based management approach, you can securelydelegate routine activities to junior personnel. Tivoli's single actionmanagement and automation saves your time by simplifying operationaltasks. Tivoli Manager for R/3 provides a variety of operational tasks as wellthe ability to easily add additional tasks to further increase administrator andoperator efficiency.

AutomationTivoli enables easy automation of routine tasks such as shutting down thesystem for backups, clearing old logs, and restarting stopped printers. Itsimplifies IT administrator’s operations and reduces workload.

Speeding R/3 deployment and accommodating changeTivoli provides the software distribution capabilities to deploy new versions ofthe SAP client code (SAPGUI) quickly and efficiently to thousands ofend-user workstations. Companies can also save time and accelerate the rollout of the SAPGUI to hundreds or thousands of end-user workstations byutilizing Tivoli Manger for R/3.

Tivoli Manager for R/3 also provides facilities to manage changes in the R/3server environment. Capabilities include autodiscovery of new R/3 systemsand servers, generic monitors and tasks that apply to multiple R/3 systems,and an architecture that is scalable to meet the growing/changing SAPenvironment.

Tivoli Manager for R/3 builds on core Tivoli management applications andsupports the Tivoli approach to unified, comprehensive enterprisemanagement. This approach allows R/3 to be managed as part of the


enterprise and with the same tools that are used to manage the entireenterprise. Operators can easily manage R/3 and other enterprisecomponents from one point and without the need for R/3 expertise.

For more detailed information about the features and functions of the TivoliManager for SAP R/3, see Chapter 2, “What is new: Tivoli Manager for R/3Version 2.0” on page 49, Chapter 4, “Planning and implementation” on page119 and Chapter 5, “Managing SAP R/3 environment” on page 163.

1.11.6 Tivoli Decision SupportTivoli Decision Support (TDS), along with the Tivoli Decision SupportDiscovery Guides, provides a ready-to-use view into the wealth of datagathered by Tivoli Enterprise Products. The product line consolidates thisdata from Tivoli products and transforms it into easily accessible ITbusiness-relevant information. This information, presented in a variety ofgraphical formats can be viewed interactively (slice, dice, drill down, drillthrough), posted on a URL. Tivoli Decision Support provides insight,revealing hidden patterns and natural relationships among the data and theability to better answer IT business-relevant questions quickly andon-the-mark.

Tivoli Decisions Support is a multidimensional query and reporting tool andsimple query and reporting software targeted at help desks and customersupport operations. The product is specifically targeted at helpingtechnologists and business users better understand their internal help deskand external customer support operations.

To meet the specific needs of help desk/customer support analysis, TivoliDecision Support includes two primary elements:

• A combination of multidimensional analysis and reporting as well assimple 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 inselecting which questions to ask and locating the data that will answerthese questions.

These facilities are the backbone for user organizations, either alone orworking with Tivoli, to quickly incorporate focused decision supportcapabilities 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 LevelManagement.

Introduction 19

Decisions Support offers a number of business advantages. The major onesare as follows:

• End-users can access information themselves. Decisions Support allowsanyone, from support analysts to CEOs, to directly view the summary anddetailed information that is relevant to them. This means that technicalstaff are relieved of the burden of trying to guess what information wouldbe valuable to each user, as they are able to get exactly what is requiredthe first time. Decisions Support eliminates a number of manual and timeconsuming processes, such as the traditional White Board, which is themanual mechanism found in most call centers to display performancedata.

• Business processes are changed for the better. Decisions Supportenables users to show, from a quantitative perspective, which businessactivities were successful and which were not. This enables the easyidentification and correction of the most critical problem areas. This, inturn, leads to improved call handling and support dispatching capabilities.By discovering which activities and questions consume the most time andenergy, it is possible to allocate resources appropriately as well asimprove procedures and documentation.

• Eliminates the need to build and maintain a separate and historicaldatabase for reporting. This ability to run against production data reducesreporting overhead on the technical staff and increases the timeliness ofreaction.

Performance Analysis and ReportingTivoli provides a set of reporting capabilities for performance data with aDecisions Support Guide for Tivoli Application Performance Manager.Organizations spend numerous hours and resources gathering performancestatistics, analyzing the data to determine needs, trends, and creating themultidimensional graphs that evaluate their performance and needs. Tivolieasily automates these functions in a solution that uses collectedperformance data to track the performance levels of the target system.

The following list provides sample questions found in the Decisions SupportGuide 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 isaffected?

• Which application server or application modules are affected?


• What performance trends may cause problems in the future?

With expertise in targeted applications, you can create relationships betweenthe various performance indicators to determine trends across related datapoints. For example, a performance module for the SAP R/3 environment mayprovide multi-level reports on transaction execution, workload analysis, andresource consumption. However, because of the comparativelynon-distributed nature of PeopleSoft transaction execution, implementing thesame metrics and rules for PeopleSoft might not be as efficient. To provide acomprehensive solution across implementations of various ERP solutionsand applications, middleware and underlying database metrics also need tobe monitored and measured. Irrespective of the application, the performancemodule must use the latest in object-oriented techniques, data storage andgraphical interfaces. This allows the generation of specialized reportsaddressing application performance regardless of whether it encompasses asingle server or a whole enterprise.

Tivoli Decision Support for SAP R/3 (TDS R/3 Guide) provides the ability toevaluate and analyze the performance and capacity of the SAP R/3application. The TDS R/3 Guide can help avoid unnecessary investments inadditional server capacity by providing quantitative information and analysisabout SAP workload patterns, trends, and the service provided on atransaction by transaction basis. The TDS R/3 Guide transforms managementof the R/3 application from a reactive, problem based approach to a proactive,service based methodology. The end result is better service with lower overallcosts.

Included with the Tivoli Manager for R/3 is the Tivoli Decision Support forSAP R/3, which extends management perspective to enable analysis of theperformance and capacity of the R/3 environment during long intervals.

We will describe more detailed information about Tivoli Decision Support forSAP R/3 in Chapter 7, “Examples of new features in SAP R/3 Management”on page 271.

1.11.7 Tivoli Global Enterprise ManagerThe evolving role of IT today demands that IT be focused on achieving thebusiness goals. Companies today need to have a business-relevant view ofthe technology. Tivoli Global Enterprise Manager (GEM) extends thecapabilities of Tivoli Enterprise to provide a new paradigm for applicationsmanagement called business systems management. Business systemsmanagement allows customers to manage groups of related applications that

Introduction 21

underpin and enable critical business functions, such as enterprise resourceplanning (ERP).

Mission-critical business systems present a unique management challenge.They typically span host and distributed environments, are comprised ofmany 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 ofmanagement and control and allows them to utilize the concept of end-to-endbusiness systems management to organize related components and givebusiness context to management decisions.

Tivoli’s Global Enterprise Manager, enables customers to view the ERPcomponents in a unified manner. This approach significantly improvesproblem solving by allowing IT staff to see the interrelationships anddependencies between ERP components. Most importantly, Tivoli GlobalEnterprise Manager allows customers to solve IT problems in the context ofthe business processes that rely on the underlying technology. With TivoliGlobal Enterprise Manager, the IT staff has the knowledge they need tounderstand how an underlying infrastructure problem impacts the business.

For example, the following figure (Figure 6) shows an example of businesssystems management in most customer environments.


Figure 6. Example: Business systems management scenario

Normally, in most customer environments, the business systems involvemany components - application server, database, application, middleware,and so on - and these environments are complicated. Customers spendnumerous hours and resources understanding, controlling, or monitoring theirbusiness systems topology, hierarchy, and status. Tivoli Global EnterpriseManager easily resolves these problems and provides up-to-date topologyinformation of the business systems. The following figure (Figure 7) showsTivoli’s action for business systems management using Tivoli GlobalEnterprise Manager.

� Scenario:Problem Resolution Between ERP andOther Systems

Sales ForceAutomation

Server

CICSSystem

Introduction 23

Figure 7. Tivoli’s action for business systems management

Tivoli Global Enterprise Manager is Tivoli’s solution for managing applicationsand systems from a business perspective. Once and application isinstrumented from Global Enterprise Manager, Tivoli allows management ofthis component in the wider context of a business system. The followingfigure (Figure 8) gives some idea of what Global Enterprise Managerintegration looks like.

MQ SeriesLink for R/3

QueueManager

� Scenario 2:Problem Resolution Between ERP andOther Systems

� Scenario 2:Problem Resolution Between ERP andOther Systems

R&D System

Human ResourcesSystem

Sales System

HQ System

ManufacturingSystem

•Business impact understood in real time•Single view across multiple disciplines•Can manage by technical and business rules•High level views and actions powered by product specific tools


Figure 8. Tivoli Global Enterprise Manager

We will describe more detailed information about Tivoli Global EnterpriseManager (GEM) in Chapter 7, “Examples of new features in SAP R/3Management” on page 271.

1.11.8 Tivoli Application Performance ManagerTivoli Application Performance Manager (TAPM) is Tivoli’s performancemanagement solution. It encompasses the best parts of four standardmeasurement techniques to provide an accurate view of the end-userapplication performance. This comprehensive solution tightly integrates withTivoli's existing resource management, alerting, reporting, and analysissolutions. Application Performance Manager provides applicationperformance management in a comprehensive solution.

In recent years, two-tier client/server applications have become increasinglyimportant. The number of servers has increased from a few mainframes todozens or even hundreds of smaller systems. TCP/IP and its dynamic routinghave become the standard network protocol, and performance of the

Introduction 25

endpoint, usually the users PC that has replaced the old terminals, hasbecome an important factor.

The factors listed previously have all made the task of managing performanceincreasingly difficult. However, because of the relatively low cost to add moreservers or new LAN segments, organizations have managed the problem inthe past by simply adding more resources to overcome performance drops.

As the underlying infrastructure becomes more robust, applicationarchitectures are evolving to become more complex. In current times, three,and even four-tier, architectures are not unusual. Users are accustomed tobeing able to move large blocks of data without actually being aware ofexactly how much data is involved. The number of servers organizations haveis steadily increasing from dozens to hundreds and even to thousands. Thenumber of clients is often many times greater than the number of servers anorganization has. Organizations are finding it more difficult to know where todeploy resources and what effect that will have on the performance of eachapplication. The gradual degradation of infrastructure performance is one ofthe biggest problems that organizations face.

The traditional areas of performance measurement are as follows:

Application instrumentationThis involves modifying applications so that they make calls to the ApplicationResponse Measurement (ARM) API. The ARM can be implemented in ameasurement agent, which clocks the elapsed time from the start to the endof a transaction. This enables the measurement of actual businesstransactions without any excess overhead. This also means that theapplication instrumentation can be controlled by the developers.

Using ARM is the least invasive technique. Response can be measuredwithout sending any extra traffic across the network to be processed byservers. It also enables the collection of measurements without trafficinterception and event processing. Because application developers controlthe measurements, it is easy to ensure accurate measurement of usertransactions. Even if the transaction itself changes as result ofenhancements, the instrumentation can be updated at the same time.

Transaction simulationThis method does not measure the real application. A script or program actsas a proxy for it. The proxy is executed periodically, and it passesmeasurements to an agent, preferably by making ARM API calls. The resultsof this can be used to approximate the end-user experience. However,


because it is a simulation, the results can never be considered too accuratealthough they can be used to predict performance problems.

Transaction simulation is considered a low-cost and reliable approach. It doesnot depend on access to source code, and it has two distinct advantages overthe 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 nousers are active, such as in the middle of the night.

However, problems can arise in some environments, as this method createsartificial loads, and it does not measure actual user transactions.

Client captureThis does not require any changes to be made to the application. Instead, itrelies on sensors at key interfaces. These observe all activity of that typewithin a system. An event indicating the activity is forwarded to an event filterwhere events unrelated to the monitored application are discarded. Theremaining events are forwarded to an event analyzer. The analyzer looks forpatterns to determine the type of transaction that was executed, and itmeasures 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 doesnot create artificial loads. Therefore, it is often described as non-invasive.However, closer inspection of how it is implemented shows that this is not thecase. It is actually quite invasive. This comes from a requirement fordeploying sensors across the environment as well as overhead associatedwith capturing and processing events.

The challenge of providing a robust client capture solution is a large one. Theevent patterns that are the signature for a transaction can change fromrelease to release. It is possible that there may be many different patternsthat all indicate the same transaction. Unless client capture is implementedvery carefully, it can overlook subtle changes in the event patterns andprovide inaccurate results.

Network X-RayThis method uses probes that attach to the network and sniff packets. Thismeans that they are able to look inside data streams and find clues to thetype of transaction that is executing. The time between the start and the endof the transaction is measured.

Introduction 27

There are a number of challenges with implementing a solution based onNetwork X-Ray probes:

• Deploying enough probes can be expensive especially if you plan tomeasure the response time of all users. This is particularly true in the caseof switched networks.

• Probes have little or no business process context. Scaling one probe tomeasure many hundreds of users is a difficult task.

• If your environment uses encryption, probes cannot measure anytransactions.

Generally, because it is a challenge to associate individual packets with anapplication, Network X-Ray has limited value in determining performanceinformation in a business application context.

The Tivoli Approach to Application Performance ManagementThe following figure (Figure 9) illustrates the Tivoli approach to managingapplication performance including service levels. The approach uses all threesystem based techniques in conjunction with a back-end process formanaging the measured data.

Figure 9. The Tivoli approach to managing application performance

MeasurementAgent

Sensor

Sensor

EventFilter

EventAnalyzer

Application

TransactionsSimulatingApplications

ApplicationUsing ARM

Start

Stop

Start

Stop

Client Capture

TransactionsSensor


This approach allows the ability to measure different transactions in differentways depending on the environmental needs. It also enables the use ofmultiple measure techniques on the same system. One possible scenario isthat the ARM is used for end-user transactions, however, client capture couldbe used to measure lower level calls to a server or database.

No matter how a transaction is measured, the same management processescan be applied to the data. The collected data can be used for service-levelreporting, on-line monitoring, or even problem diagnosis. Ultimately,techniques can be combined with the same agent and even for the sametransaction.

Performance monitoring is a basic prerequisite for performance management.Performance monitoring enables real-time data collection and analysis toreport 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 thefollowing:

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 howto redesign and reconfigure the application to achieve optimalperformance.

5. Tuning resources.

Tivoli Application Performance Manager focuses on performancemanagement from an end-user or business perspective. This enables TivoliApplication Performance Manager to measure the service levels of businesstransactions and use this information as a basis for understanding how eachcomponent affects the application performance. Once a component is foundto be a major factor in end-user service levels, it can then be analyzed andinvestigated in depth.

Tivoli Application Performance Manager bases performance on the effect toend-users. This means that time and money are not wasted on pursuingsolutions that provide less than the maximum possible value.

With the use of analysis programs, great quantities of data can be reducedand refined to the information necessary to make informed business

Introduction 29

decisions. This approach maximizes the value of the limited staff available toanalyze performance and capacity.

Tivoli Application Performance Manager achieves the following:

• Seamlessly integrates with the best-of-breed tools for benchmarkingperformance in prototypes and pilot deployments. The pilots use stresstesting to assess the network and server capacity prior to deployment in aproduction environment. For example, these tools show how longtransactions take and how long the sub-transaction calls to other serverstake. Tivoli Application Performance Manager uses the transactionsemployed in the stress test phase to simulate transactions for ongoingmonitoring. This avoids the creation of a new set of transactions formonitoring purposes and allows comparisons between expectedperformance and actual performance.

• Reports on Service Level Agreements (SLAs). SLAs are a fundamentalbuilding blocks of a good process. They provide a way to measure theprocess, and they are important tools for executives looking at the valuechain from a business perspective.

• Provides online monitoring and status reporting versus thresholds.Automation routines can be established so that, in the event of a thresholdbeing exceeded, corrective action can be performed. The correlation ofevents related to application performance along with those events relatedto applications, databases, systems and networks, enable the quickidentification of the cause of a failure or shutdown.

• Provides an at-a-glance view of service levels for one or all of theapplications in an enterprise. This is done in conjunction with the GEMConsole, thus providing a business-system perspective.

• Provides ready-to-use solutions for popular applications. These solutionsdo not need to be configured; however, they can be customized andextended. 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 uniqueenvironments. Service providers, consultants, and other skilled users canadd value by building or customizing solutions for specific customerenvironments, such as developing instrumentation for specific applicationsand developing reports tailored to an application or an installation.

• Integrates with other Tivoli products. To manage the performance ofdistributed applications effectively requires integration of other data, suchas network topology, system inventory, events, and problem reports.


Instead of drowning in the data, intelligent combination of all this dataprovides usable information to IT and business managers.

We will describe more detailed information about Tivoli ApplicationPerformance Manager (TAPM) in Chapter 7, “Examples of new features inSAP R/3 Management” on page 271.

1.11.9 Tivoli Database Management ProductsThe Tivoli Database Manager Products allow for the seamless managementof RDBMS components with Tivoli. Similar to the Tivoli Manager for R/3, theyuse the Tivoli Management Framework and core applications to manage acertain application, in this case, RDBMS servers.

1.11.9.1 Tivoli Manager for DB2Tivoli Manager for DB2 addresses the needs of DBAs who support theoperational environment. It focuses on monitoring DB2 servers, taskscheduling, and automated task execution on AIX, Sun Solaris, and WindowsNT. DBAs can discover databases automatically and display DB2 instanceand database properties. Tivoli Manager for DB2 provides DB2 systemsmanagement on the Tivoli Management Framework. Using the Tivolimanagement by subscription paradigm, Tivoli Manager for DB2 provides thedatabase administrator with the necessary controls to manage hundreds ofDB2 servers from one console.

The Tivoli Manager for DB2 is the strategic follow-on to the two IBM DataHubproducts, DataHub for OS/2 and DataHub for UNIX OS, and the IBM DB2Enterprise Control Center for Tivoli (DB2 ECC) product. The functionsprovided by the two DataHub products on UNIX, OS/2, and Windows NT havebeen incorporated and enhanced in DB2 UDB.

1.11.9.2 Tivoli Manager for OracleThe Tivoli Manager for Oracle is designed for organizations with large,heterogeneous database installations. It is primarily designed to aid twogroups of people inside the enterprise:

1. The IT Operations staff who are charged with maximizing the availability ofdatabase resources.

2. The DBA’s responsible for managing the efficiencies of, access to, and thecontent of database resources.

Commercial database products, such as Oracle, play a business-critical rolein practically all computing environments. For the operations staff, the TivoliManager for Oracle greatly reduces the overhead of ensuring that database

Introduction 31

resources are available and operating optimally. These people generally donot have the level of database specific knowledge that a DBA possesses butmust be able to detect problems with databases and engage the appropriateexpertise to remedy the situation. By providing a sophisticated event and alertmanagement solution, the Tivoli Manager for Oracle reduces the overheadand streamlines the problem detection and resolution cycle for these people,therefore, resulting in higher database availability.

1.11.9.3 Tivoli Manager for SybaseThe Tivoli Manager for Sybase performs a very similar task to the TivoliManager for Oracle described above. It is designed to aid the same twogroups as the Tivoli Manager for Oracle and also provides the same cost andtime reductions afforded by that product. They could almost be classified asidentical in feel and function.

For example, the following figure (Figure 10) shows an example of databasemanagement in most customer environments.

Figure 10. Example: Database management scenario

Databases play a vital role in ERP application systems. If the database hassome trouble, it immediately affects the response time of the ERPapplications that are using the database. As a result, end-users call the

� Scenario:ERP Availability - Database slow!


operator; however, the operator cannot detect and resolve the problem.Finally, an IT administrator is called and has to detect and correct theproblem. This inefficient process will be repeated each time the database hasa problem. Normally, it takes a long time to recover, and the cost of the ITadministrator is very expensive. Tivoli Database Manager Products can be apowerful solution for this problem.

Figure 11. Tivoli’s action for database management

Tivoli Database Manager Products enable proactive management. TivoliDatabase Manager Products provide efficient monitoring function and detectpotential problems before they occur. If some rules are defined in TECproperly, these rules resolve the potential problem automatically. Theseprocesses are performed without interruption; so, end-users can continuetheir work using ERP applications without any problems.

1.11.10 Tivoli Manager for MQSeriesThe Tivoli Manager for MQSeries is an enterprise level management solutionthat brings Tivoli’s life-cycle management capabilities to organizations usingthe MQSeries across host and distributed environments. The most powerfulaspect of Tivoli’s MQSeries management approach is that MQSeries ismanaged in the context of the applications and business systems that utilizeit. This provides IT managers with the information they need to understandthe business-level impact of MQSeries availability and performance.

� Scenario 1:ERP Availability - Database slow!

TivoliEnterpriseConsole

TivoliDistributed

Monitoring /DB Managers

•Proactive Management•All Actions taken Automatically•ERP system not effected•No requirement for operator, help desk, DBA, orBasis/Peopletools specialists

Introduction 33

It is the only MQSeries management solution that manages MQSeries and isan integral part of a larger business solution. It is also the only MQSeriesmanagement product that manages the entire application stack, fromlow-level network and operating system resources up through theapplications, that utilize MQSeries for messaging. Tivoli Manager forMQSeries provides centralized management for distributed MQSeriesnetworks that span geographic distances and heterogeneous systems.

Tivoli Manager for MQSeries has a number of management services. Thefollowing table lists these along with their functions and benefits:

Table 3. Functions and benefits of Tivoli Manager for MQSeries

ManagementService

Function Benefits

AutomatedSoftwareDistribution

Provides pre-distributionchecks for system resourcesand dependencies, disk space,memory, OS level and networkconfiguration, automateddistribution and installation ofMQSeries software to remoteMQSeries nodes, andpost-distribution validation.

Saves significant time, effort,and money in deployingMQSeries software andsubsequent upgrades.

MQSeriesConfiguration

Supports the definition andconfiguration of MQ objectsfrom a central console. Adiscovery feature automaticallydetects Queue Managers andtheir associated objects inMQSeries networks--even onOS/390.

Reduces the complexity ofdefining and deployingMQSeries networks resulting inspeedier and less error-pronedeployments.

ComprehensiveMonitoring

Provides extensive in-band andout-of-band monitoring toensure the availability ofMQSeries. Captures MQSeriesevents and passes them to acentral console for display andaction. The health andperformance of MQSeriesprocesses, hosts, and systemresources necessary forreliable MQSeries operation ismonitored and displayed live atthe central managementconsole.

Comprehensive monitoringensuring the availability ofMQSeries networks upon whichyour business-criticalapplications depend.


1.11.11 Tivoli Workload SchedulerTivoli Workload Scheduler, also known as Maestro, is the Tivoli product forenterprise-wide job scheduling. Tivoli Workload Scheduler is an applicationwith full functionality in scheduling purposes and is available on severalplatforms. Currently, these include all flavours of UNIX, for example, AIX andHP UX, Windows 95, Windows 98, and Windows NT. It can be integrated withTivoli using the Tivoli Plus for Tivoli Workload Scheduler product. Thisproduct allows the management of Tivoli Workload Scheduler from the TivoliDesktop.

Tivoli Workload Scheduler for SAP R/3:

• Tivoli Workload Scheduler has been certified with SAP's BusinessApplication Programming Interface (BAPI) for scheduling R/3.

• Enables batch job coordination between SAP R/3 and other environments.

• Is certified by SAP.

CentralizedMQSeriesManagement

Allows administrators tomanage multi-domain,cross-platform, andenterprise-scale MQSeriesnetworks from one centralizedpoint.

Simplifies and reduces laborrequired to manage MQSeriesnetworks.

Rules-BasedEventCorrelation

Correlates MQSeries eventswith other sources, such asnetwork devices and operatingsystems, based onuser-defined rules.

Allows events to be evaluated incontext with one another foraccurate problem diagnosisand resolution.

AutomatedOperations

Actions can be automated toexecute on a scheduled basisor as the result of eventoccurrences.

Provides lights-outmanagement.

End-to-endMQSeriesManagement

Manages MQSeries networksthat span host and distributedenvironments.

A complete view andmanageability of your entireMQSeries network.

Tivoli GlobalEnterpriseManagerIntegration

Allows MQSeries to bemanaged as a component oflarger business systems.

Higher availability of thebusiness systems that driveyour business.

ManagementService

Function Benefits

Introduction 35

The following table lists some of the features available in Tivoli WorkloadScheduler and their advantages to the R/3 user.

Table 4. Some advantages of Tivoli Workload Scheduler for R/3

1.11.12 Tivoli User AdministrationTivoli User Administration extends the capabilities of the Tivoli environment toallow management of user accounts on UNIX, Windows NT, and NovellNetWare platforms (Tivoli User Administration for SAP R/3). Additionally, andof most relevance to this book, you can also manage SAP R/3 user accountsall from a single location.

Tivoli User Administration provides your network computing environment withthe 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.

Selected Feature Function Advantage

Central console Allows a single point of controlfor SAP R/3 and non-SAP R/3scheduling.

Saves money throughreduced training andsimplifies troubleshootingthrough consolidatedinformation.

Cross-applicationsupport

Allows schedulingdependencies betweendisparate system.

Enables SAP R/3 jobs to bedependent on non-SAP R/3jobs and vice-versa.

Fault tolerance Allows processing to continuein the event of a node ornetwork failure.

Ensures reliability in theSAP/R3 schedulingenvironment.

Rule-basedprocessing

Introduces advancedscheduling features into theSAP R/3 environment throughTivoli Workload Scheduler.

Improves and expands dataintegrity enterprise wide.


1.11.13 Tivoli Global Sign-OnTivoli Global Sign-On provides a secure and easy to use solution that grantsusers access to the computing resources they are authorized to use with justone logon. Global Sign-On is primarily designed for large enterprises, whichconsist of multiple applications and systems, within heterogeneous,distributed computing environments. Global Sign-On removes the need forend-users to manage multiple user IDs and passwords.

1.11.13.1 Tivoli Global Sign-On ComponentsTivoli Global Sign-On consists of a number of components. When GlobalSign-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 ModuleThe Tivoli Global Sign-On Plus Module is a prerequisite that must be installedbefore the Tivoli environment can be used to create and distribute the GlobalSign-On Server and Client.

Using the Plus modules and Tivoli Software Distribution, it is possible todistribute Global Sign-On application’s file packages. The Plus modules mustbe installed on the TMR server, on the Tivoli Enterprise Console server andon all Managed Nodes that are going to be Global Sign-On servers ordatabase servers.

The Tivoli Global Sign-On Plus Module provides some predefined monitors,event filters, and correlation rules. The monitors can be used with TivoliDistributed Monitoring, which allows the management of vital Global Sign-Oncomponents, such as process and log files. The Tivoli Enterprise Console canbe used with the filters and rules to automate the response to specific events.

Tivoli Global Sign-On ServerWhen the Global Sign-On Server is installed in a Managed Node in a Tivolienvironment, it transforms the node into a Global Sign-On server. Theprimary functions of a centralized server are user authentication and userconfiguration management.

Introduction 37

A Global Sign-On server uses the services of the Kerberos Security Registryto securely manage the user information. This includes user definition andidentification and the extended registry attributes capabilities for storage ofuser information.

It is possible to have more than one Global Sign-On server; however, onlyone 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, thenclients can connect to a Replica server, which will have assumed the role ofthe master server and retrieve the information they require. This is theconcept of a replicated environment and clustering similar in operation toLotus Notes.

Tivoli Global Sign-On ClientThe Global Sign-On Client runs on the user’s workstation and interacts withthe Global Sign-On server. These workstations then also become known asGlobal Sign-On Clients. These can be either PC Managed Nodes or ManagedNodes.

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 GlobalSign-On server to verify the user’s ID and password and to collectadditional user information.

• Management Service

This service allows the user to perform administration activities, forexample, password changes, changing target definitions, and so forth. Itinteracts with the Global Sign-On server to store or change the userdefinitions.

• Logon Coordinator

The function of this is to actually perform the logons to the various targetsas well as getting the users target information from the Global Sign-Onserver.

• Communication Service

This service is responsible for the communication between the GlobalSign-On server and the clients. This is achieved via secure encryptionmethods (Data Encryption Standard).


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 thatGlobal Sign-On database clients have authenticated access to an underlyingRDBMS. It is recommended that the Global Sign-On Database Servercomponent is installed on the same physical machine as the RDBMS itself.

The Global Sign-On Database Server component supports the followingdatabases:

• 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 normalGlobal Sign-On Client so that database user authentication can be performedwith the RDBMS running on the Global Sign-On Database Server. Thiscomponent varies depending on the RDBMS that is being used. With thiscomponent installed, the workstation is also classed as a Global Sign-Ondatabase client.

Tivoli Global Sign-On User AdministrationThe Global Sign-On User Administration component adds Global Sign-Onuser properties to Tivoli Management Framework. It provides a single point ofcontrol for managing Global Sign-On information for existing Tivoli UNIX,Windows NT, and NetWare user accounts. The Tivoli Global Sign-On UserAdministration component can be installed from any managed node in theTMR. It should be installed on the TMR server where the current Tivoli UserAdministration component is installed and also on any Managed Nodes thatare required to be Global Sign-On servers or database servers.

The Global Sign-On User Administration component upgrades Tivoli UserAdministration 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, anddistributed to, the Global Sign-On server.

Tivoli Global Sign-On TargetA Global Sign-On target is an application or system that a user wishes toaccess. Targets are classified into different target types. These types identifythe target by application name, such as MVS, AIX, DB, and so forth.

Tivoli Global Sign-On Supported PlatformsThe Global Sign-On User Administration, Plus Module, Server, and DatabaseServer 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 andPlus Modules only)

1.11.14 Tivoli Security Management (Lockdown Module)Tivoli Security Management provides maximum flexibility and improvementsin administrator reliability and efficiency. Tivoli Security Managementachieves this by abstracting from the security model of individual platforms. Itstill manages the platform specific security data; however, it achieves crossplatform security modelling through role-based security. There are significantbenefits to this form of abstraction, but it makes the implementation of thesecurity module more difficult. An ideal Tivoli Security Managementimplementation design would include the identification of all job tasks in anorganization as well as the IT resource access requirements to fulfill each ofthose tasks. This data would then form the basis of Tivoli SecurityManagement roles and resource data. This would require that all personnelalso be defined in Tivoli Security Management groups. In a largeorganization, this can take a long time.

Tivoli Security Management was the first security product that was designedfrom the ground up to manage access control in a consistent fashion in adistributed environment using a role-based security model. With role-basedsecurity, it is possible to determine what resources people have access tobased on the job tasks or roles that they need to perform. In Tivoli SecurityManagement, these resources can be of different types including files,printers, programs, or TCP services. They can also reside on differentplatform types, such as Windows NT, different flavours of UNIX, and onOS/390 systems protected by the OS/390 Security Resource Access Control


Facility (RACF). Once all the resources that are required to complete the taskhave been identified, they can all be listed in a role and the relevant accessrights given. Tivoli security groups can then be formed based around a jobtitle, and those groups can then be given all the roles they need in thatposition.

Once it is configured, an administrator does not have to be concerned withgranting access to a user to resources of many different types on manydifferent systems. Instead, an administrator adds the user to the Tivolisecurity group, and all the access rights are granted during the next securityprofile distribution through the role relationships. The time saved inadministration once Tivoli Security Management is in place can be significant.

1.11.14.1 Lockdown ModulesA Lockdown Module is a way of defining a security profile that can be easilyaltered, expanded, and, most importantly, be reused in another location.Some Lockdown Modules can be ready made for products, such as WindowsNT, the Oracle RDBMS, Lotus Domino, and SAP R/3. A Lockdown Module willinclude the definition of roles that provide the required level of access toperform different tasks with the subject application or operating system. Anideal Tivoli Security Management implementation places users in as fewgroups as possible.

Figure 12. Example of security groups and roles

The example in Figure 12 shows how groups can be used to represent jobtitles in an organization and how the tasks people perform define accessrights through roles. The Soton server administrator has access to resourcessimilar to the Romsey server administrator, with the additional role ofmanaging the Web server. The Romsey IT manager has access to additional

Romsey_IT_Manager Romsey_Server_Admin Soton_Server_AdminGroups

Payroll_DB_View

Customer_DB_Update

Customer_DB_View

Webserver_Admin

Company_Employee

AIX_AdminRoles

Introduction 41

information, for example, the payroll database, as well as higher than averageaccess for the customer database.

A Lockdown Module is a system or application specific Tivoli Security Profilethat can be modified to match an environment, applied on an endpoint, andthen tested to lockdown a specific system or application.

Building Lockdown Modules breaks down the security management task intoeach application or operating system that requires protection. Each moduledefines Tivoli security roles that can be given to groups to enable them toperform tasks that would otherwise be restricted. Tivoli security groups androles are one area of the module that is likely to require some customizing tointegrate into your security model.

The goal of using a Lockdown Module is to make Tivoli Security Managementsimpler, whether by developing your own, or obtaining the ready-made Tivoliversions. They also allow and encourage the exchange of knowledge andexperience. For further information on lockdown modules, please refer to theredbook Securing Applications with Tivoli Security Management LockdownModules, SG24-5140.

1.11.15 Tivoli Storage Manager (Tivoli ADSM)Tivoli Storage Manager is a full-function storage software set that managesthe complete range of information needs, by providing business continuity forplanned and unplanned outages, and delivering "one-touch" control over theentire "info-structure". Built upon the solid, award-winning foundation of IBM’sADSTAR Distributed Storage Manager (ADSM), Tivoli Storage Manager set isa new standard in information management and protection.

Tivoli Storage Manager (Tivoli ADSM) is Tivoli’s enterprise backup/restoreand archive/retrieve solution that is available on a wide range of platforms.Tivoli Storage Manager provides integration of several databases andapplications, such as DB/2, Oracle, Lotus Notes, SAP R/3, and so forth.

Locking down applications with Tivoli Security Management should be onepart of a coordinated security policy. Tivoli Security Management greatlyenhances access control management and consistency; however, it is oflittle use if other aspects, such as physical access ti servers or passwordcontrols, are not considered.

Note


The Tivoli Storage Manager connection to SAP R/3 allows the customer toback up their SAP R/3 database and archive their SAP R/3 application datawith one utility.

1.11.15.1 Tivoli Data Protection for SAP R/3Tivoli Data Protection for SAP R/3, (formerly called BACKINT/ADSM), is theleading solution for high performance data backup and recovery within theSAP R/3 area. It is seamlessly integrated with Tivoli Storage Manager andSAP 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 enablessystem administrators to more efficiently manage the large volumes of datainvolved in system operations and it facilitates the most efficient use ofresources. System administrators can follow SAP procedures and use theintegrated SAP utilities (SAP DBA: BRBACKUP, BRARCHIVE, andBRRESTORE) for backup and restore.

1.11.16 Tivoli Output ManagerTivoli Output Manager, formerly known as Destiny, is the Tivoli product forenterprise-wide output control. The output environment is an ever changingand diverse environment containing different printing devices (Postscript,PCL, encapsulated PostScript, plotters, line printers), different printercartridge fonts in printing devices, facsimile machines, Web servers, differentmail gateways (X400, PROFS, cc:Mail, Lotus Notes, Microsoft Exchange,Microsoft MS Mail, Microsoft OutLook, SMTP), and the global differences inpaper sizes in the distribution centers. Companies are starting to look atenterprise output managers for coordination, routing paths, delivery, andabove all, security of documents. The Tivoli Output Manager is positioned todo this with an easy-to-use user interface and rule engine to deliverdocuments reliably across the enterprise.

Enterprise applications, such as SAP R/3, rely on the output environment todeliver the critical daily, weekly, and month-end reports to a single end user orgroups of management teams. It is the responsibility of the enterprise outputmanager to orchestrate and deliver these reports according to the businessrules that have been defined by the process engineers. The following figureshows a typical output environment.

Introduction 43

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 ManagementTivoli Output Manager provides administrators the option of fully centralizedadministration, fully distributed administration, or a mix of both environments.The consoles that the administrators used are based on Java. Two types ofconsoles are available. One console manipulates the structure of theenvironment, and the other console performs the operation of theenvironment. The console that manipulates the environment logs on to theenterprise component of Tivoli Output Manager and can cause WAN networktraffic. The console manipulates the operational structure, logs on to the

WebWebFaxFax

EmailEmail

ProductRequirements

RevenueForecast

MarketingMix

Executive

WebWeb

Marketing

Sales

ManufacturingEngineering

PrintPrint


Domain component of Tivoli Output Manager, and can cause LAN networktraffic.

The consoles will show all the alerts of the defined resources in the outputnetwork. The consoles are also used to monitor output activity and track itclosely and pro-actively.

1.11.16.2 Controlled Access of Output ResourcesAdministrators and users are defined across all the output resources forglobal policy adherence and consistency. These definitions are distributedand activated throughout the output network and are done by administratorswith the needed security profile.

Just like administrators, users also have to go through the authorizationlayers to use the output network. This provides user-to-user notifications andreliable access control of the resources in the output network.

1.11.16.3 Routed Output ResourcesTivoli Output Manager is structured around a rule-based foundation. Whencertain resources are down, fault tolerant routing rules can still deliver andnotify the appropriate people of the different path that was used. This is veryuseful for mission critical reports.

The rule engine can also respool and extract archive documents to outputresources if duplicates are detected. This is very useful for streamlining theoutput environment and prevents large reports from duplicating over slownetwork links between distribution centers.

1.11.16.4 Reliable and Secure Output ChannelsThe delivery path for the user’s workstation to the output resource is always inan encrypted form. The packets flowing between the user’s workstation andthe output destination are not visible for LAN sniffers and packet analyzers.This provides a good way to deliver documents over the Internet safely andsecurely.

Tivoli Output Manger provides definitions for secure output resources. Thisallows the users to rely on the output network for delivery to all the securedevices if their favorite device is off-line.

The secure output channels are defined by the administrator and allowspecific users or groups, like the executive team, to use these printers.

Introduction 45

1.11.16.5 Automated Delivery ChannelsThis option of the Tivoli Output Manager allows the definition of rules oncertain output resources, for example, aggregate all printing from a certainprint server and archive the data onto disk.

This attribute, at first glance, seems inappropriate, but when it comes toenterprise security and re-routing of output devices, it makes sense. Withautomated delivery channels, you can track headers and apply audit rules toall, or some, of the channels.

1.11.17 Tivoli NetViewTivoli NetView is Tivoli’s network management solution that is focused onmanaging IP-based networks. NetView displays the nodes in the network ona map representing the network topology and the status of the networknodes.

In the case of something happening in the network, NetView generatesSimple Network Management Protocol (SNMP) traps that are displayed in acentral event window and that can trigger actions or correlations. In thatregard, NetView is similar to the Tivoli Enterprise Console. However, NetViewis exclusively focused on processing SNMP events, usually events related tothe network. However, NetView alerts can be forwarded onto the TivoliEnterprise Console by the application of simple filter rules.

NetView can also receive events created by external sources, such as theservers it is monitoring. These are received in the form of SNMP trapsformatted for display in the NetView event window.

The following figure shows an environment displayed on a NetView map, withthe Control Desk attached at the bottom of screen to display SNMP alerts.


Figure 14. Example of a NetView display

Introduction 47


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 themanagement of R/3 with the rest of the enterprise by monitoring R/3resources, managing R/3 alerts, automating routine tasks, and deployingsoftware for R/3 desktops. Tivoli Manager for R/3 maximizes your R/3investment by building on the Tivoli Enterprise environment. Together theyprovide a common management infrastructure and comprehensive set ofmanagement tools for enterprise R/3 management.

Version 2.0 of Tivoli Manager for R/3 improves its management abilitydramatically. It provides more reliable, flexible, and scalable SAP R/3management, and it allows you to manage multiple R/3 systems efficientlyand easily even if it is in a large-scale environment.

In this chapter, we introduce the overview and highlights of Version 2.0 ofTivoli Manager for R/3 and what is new in Version 2.0 of the Tivoli Managerfor R/3.

2.1 Tivoli Manager for R/3 packaging

Tivoli Manager series products are complicated products, especially R/3Manager because it consists of a variety Tivoli core product facilities. In otherwords, R/3 Manager is a complex package for managing R/3 systems usingTivoli products or features. R/3 Manager consists of the following facilities:

• Policy Region

• Profile Manager

• Sentry Monitor

• Indicator

• Task

All examples in this book regarding Version 2.0 of Tivoli Manager for R/3are performed with the pre-GA version of the product. Therefore, somedetailed feature may be changed without notice. Please check with yourIBM or Tivoli representative for further information.


Note


• File Package

• TEC Rule Base

• GEM Instrumentation

• R/3 Object

The following figure (Figure 15) shows the relationship between R/3 Managerand each of the components.

Figure 15. Tivoli Manager for R/3 components

As you can see, each component is based on Tivoli core applications, suchas TEC Rules or Distributed Monitoring monitors. To perform R/3management operations, R/3 Manager uses these Tivoli core applicationfunctions efficiently. This is the reason why R/3 Manager requires these Tivolicore applications as its prerequisite. The following figure (Figure 16) showsthe relationship between Tivoli core applications and R/3 Manager.

Tivoli Manager for R/3

Indicator

File Package

Policy Region

TEC Rule Base

Profile Manager

Task

GEMInstrumentation

Sentry Monitor


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 coreapplications. If you need more detailed information on Tivoli or Tivoli coreapplications, you can refer to the following redbooks:

• All About Tivoli Management Agents, SG24-5134

• An Introduction to Tivoli’s 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 systemsthat use different version of the R/3 application. It is capable of managing themonitoring and operational tasks for R/3 testing, development, andproduction from a centralized location. It captures and reports events from allR/3 systems and has the ability to forward these onto the Tivoli EnterpriseConsole. The Manager for R/3 enables the integration of informationregarding R/3 availability with information about the operating system,network, database, and other R/3 related components. It provides an overall

Tivoli Management Framework

Tivo

liE

nte

rpri

seC

on

sole

Dis

trib

ute

dM

on

ito

rin

g

So

ftw

are

Dis

trib

uti

on

Ap

plic

atio

nP

roxy

Tivoli Manager for R/3

Other Products

What is new: Tivoli Manager for R/3 Version 2.0 51

picture of how the R/3 environment is performing and helps operators quicklyidentify and resolve the cause of any availability problems.

2.2.1 Brief overview of new features and improvementsThe new release of the Tivoli Manager for R/3 has many improvements andadditions over the old version. What follows is a brief overview of each ofthese new features, which will be covered in greater depth later on in thechapter.

2.2.1.1 Product RestructureAs the title suggests, the product has been largely restructured. This includesa new object structure, a new configuration policy subregion, and the ability tomonitor the current status of an application server indicated by its icon on theTivoli Desktop. The new object structure means that each R/3 system isconfigured as a policy subregion that contains the application servers and thedatabase server that define the R/3 system. The new configuration policysubregion contains new configuration and list maintenance tasks specific toSAP R/3.

2.2.1.2 Common Tasks and MonitorsThese enable the distribution of tasks and monitors to all servers across theR/3 systems managed by the Tivoli Management Region (TMR) server. NewTivoli Distributed Monitoring collections provide a wide range of internal andexternal R/3 monitors, such as the monitoring of performance statistics fromthe R/3 SysMan or monitoring internal R/3 buffer statistics by using the R/3Remote Function Call (RFC) interface. All of these include configurablethresholds and responses, which enable effective monitoring and automaticcreation of differing severity levels of Tivoli Enterprise Console events.

2.2.1.3 Integration of Common R/3 Resource RolesThe Tivoli Manager for R/3 now uses three resource roles that can beassigned to Tivoli Administrators. These roles allow the control of access toR/3 systems and tasks. These resource roles are common across R/3systems.

2.2.1.4 New R/3 Specific TasksThere 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


These new tasks make the management and control of R/3 systems via Tivolimuch easier and quicker.

2.2.1.5 New Monitors for Work Processes and Cancelled Batch JobsIt is now possible with this new version of the Tivoli Manager for R/3 tomonitor work processes. This includes the ability to monitor the processcount, watch for queued work processes, and monitor long runningprocesses. It also includes a monitor for cancelled batch jobs.

2.2.1.6 User-Configurable Syslog Event AdapterThe Syslog Event Adapter processes the R/3 syslog file and converts newentries into TEC events; so, it is possible to configure the types of events towatch for. These can then be converted into Tivoli Enterprise Console eventsfor display to operators. The syslog event adapter also allows the ability to getTEC events based on the R/3 syslog messages. The Syslog Event Adapterobtains syslog messages through the R/3 RFC interface, therefore, theSyslog Event Adapter must log on to the R/3 system. The Syslog EventAdapter 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 moreinformation).

This is a new and significant function. Tivoli-provided filtering capabilities canbe applied to these events. Please refer to 5.3.3, “Syslog Adapter” on page189 for more detailed information about the Syslog Event Adapter.

2.2.1.7 Improved Event FilteringIt is now possible to filter events at the Event Adapters so that only particularevents are forwarded onto the Tivoli Enterprise Console.

2.2.1.8 Miscellaneous Improvements and FeaturesThe following is a list of the other improvements or new features that havebeen 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 andimprovements listed in this section in much greater detail. The first of these isthe new product structure.


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 andusability enhancements over the previous release. The following are newfunctions and features of Version 2.0 of R/3 Manager:

• Restructure of Tivoli Manager for R/3 to improve scalability, usability, andmaintainability.

• 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 andGEM 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 release1.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 explainhow each works.

2.3.1 Restructure of Tivoli Manager for R/3In Version 2.0 of Tivoli Manager for R/3, the restructure of R/3 Manager isapplied to several aspects. As a result, the user interface or configurationmethods are a little different from the previous version of R/3 Manager.Basically, Version 2.0 of R/3 Manager becomes much simpler than theprevious version of R/3 Manager in improving scalability, usability, andmaintainability.

In this section, we introduce the restructure of the following aspects and showthe differences and changes between Version 2.0 of R/3 Manager and theprevious version of R/3 Manager.

• New icons and nesting level


• SID-specific indication

• New resource roles of R/3 Manager

2.3.1.1 New Icons and Nesting LevelThe changes on Tivoli Desktop are obvious, and you can recognize themeasily when you open the Tivoli Desktop. On the Tivoli Desktop, you willnotice that several new icons are added. We will introduce the changes on theTivoli Desktop and the new nesting level perspective.

After completing installation of R/3 Manager, the Manager for R3 policyregion appears with a new icon on Tivoli Desktop. The following figure (Figure17) shows this new icon.

Figure 17. Tivoli Manager for R3 icon on Tivoli Desktop


If you open the new R/3 Manager policy region (Manager for R/3), you findthe 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 lowerhierarchy, it contains the following objects:

• R3 System List (Profile Manager)

• R3 Configuration Tasks (Task Library)


• R3 Internal Tasks (Task Library)

• R3 List Maintenance Tasks (Task Library)

As you can see, it reduces the hierarchy from five levels to two levelscompared to the previous version of R/3 Manager. It enables you to reach theappropriate managed resource icon easily and quickly.

Once you complete the managed R/3 resources configuration, the R/3objects 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 applicationserver icon or R/3 database server icon, or both the R/3 application servericon and R/3 database server icon. In the following example (Figure 20), theR/3 application server and database server are configured on the samesystem, therefore, both the R/3 application server icon and the databaseserver icon are displayed.


Figure 20. Application server and database server in R/3 System

One more new feature is that the application server provides the extraindicator, which shows the status of the application server graphically. We willintroduce 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 IndicationAs we mentioned, Version 2.0 of R/3 Manager simplifies many R/3 systemmanagement operations. In this section, we introduce how the structuresimplifies your management operations and improves maintainability andscalability.

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), butdoes not have SID-specific code. Basically, it simplifies R/3 managementoperations greatly.

SID is a three-character identifier (ID) for an R/3 system. In the prior versionof 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 eachSID. In Version 2.0 of R/3 Manager, you only need one copy of them for allSIDs. This means that you can distribute a single task or monitor to all R/3systems. In other words, you do not need to define tasks or monitors for eachSID. Since you need to maintain only one copy, it improves yourmaintainability.


For example, in the prior version of R/3 Manager environment, if you wouldlike to distribute a monitoring profile or task to the three different R/3 systemsthat have different SIDs, you need to configure three different profiles even ifthe setting of each profile is the same. The following figure (Figure 21) showsthis situation.

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 tocreate just one profile and distribute the profile to the three R/3 systems thathave different SIDs (refer to the Figure 22) because you do not need tospecify the SID for each task or monitor anymore.

TMR Server

SID "AAA" SID "BBB" SID "CCC"

AAA BBB 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/3Restructure of R/3 Manager simplifies the security model as well. In theprevious 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. Theseroles allow you to utilize Tivoli global and resource-specific permissionseffectively.

Once you complete the installation of Version 2.0 of R/3 Manager, it createsthe following three new resource roles that can be assigned to each Tivoliadministrator.

• r3_user

• r3_senior

• r3_admin

The following figure (Figure 23) shows the new resource roles that areprovided by Version 2.0 of R/3 Manager.

TMR Server

SID "AAA" SID "BBB" SID "CCC"

R/3 System


Figure 23. New TMR roles of manager for R/3

To use an R/3 Manager task, at least one of these authorization roles isnecessary. In addition to the R/3 authorization, basic Tivoli authorizationroles, 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 basicTivoli authorization role, and the granted authority for each roles.

Table 5. The Relationship between R/3 Roles and Tivoli Basic Roles

To use the wr3rfc functions and syslog event adapter, you must configure anSAP R/3 user ID so that you can access the RFC interface. The ConfigureRemote Function Call task in the R/3 Configurations Tasks task libraryconfigures the user ID and password to use during accessing the RFCfunction. Once the configuration task has been done, the password is storedin the Tivoli database in encryption form, and it is never shown in text again.

R/3AuthorizationRole

Basic TivoliAuthorizationRole

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 exceptfor the Configuration Remote Function Call-Create New Subscriber List task in the R/3 ListMaintenance Task Library

r3_senior senior -Configure Remote Function Call task in the R/3Configuration Task Library


2.3.2 Tivoli Management Agent (TMA) supportVersion 2.0 of R/3 Manager supports Tivoli Management Agent (TMA). In theprior version of R/3 Manager, the R/3 application server and database servermust be configured on Managed Node; however, in Version 2.0 of R/3Manager, the R/3 application server and database server can be configuredon TMA. It will reduce the number of Managed Nodes in your TMR and helpsto 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 performreliable and extensible SAP R/3 management.

To support TMA, Tivoli Application Proxy plays a vital role in your SAP R/3management environment. The next section introduces Tivoli ApplicationProxy 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 asthe prerequisite, for example, Tivoli Management Framework, DistributedMonitoring, Tivoli Enterprise Console, and Software Distribution. In addition tothese prerequisite products, Version 2.0 of R/3 Manager requires one moreproduct, Tivoli Application Proxy.

Application Proxy is an extension of the Tivoli Framework that provides acommon set of services that are used by the Manager for R/3. ApplicationProxy enables the R/3 Manager to run on Tivoli Management Agent (TMA).Application Proxy provides the interface function between the R/3 Managerand TMA. Application Proxy is independent of the R/3 Manager. This meansthat the R/3 Manager does not need to care about whether its object iscreated on a TMA or Managed Node, and Application Proxy handles eachrequest 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 TivoliManager series products, such as Tivoli Manager for Domino, and will providethe interface function between other Tivoli Manager series products and TMA.In other words, several Tivoli Manager series products will support TMA in thenear future as well.


2.3.2.2 How Tivoli Application Proxy WorksTo support TMA in R/3 Manager, the R/3 Manager has to manage therelationship between its R/3 objects and each TMA. In other words, the R/3Manager must understand which TMA contains the R/3 objects in the TMR.This object information is stored in a Tivoli object database; however, TMAdoes not have its own object database. Therefore, Application Proxy handlesthis information instead of the R/3 Manager and performs the followingprocesses:

• 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 ApplicationProxy behavior.

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 119for more information about Application Proxy installation.

Note


Figure 24. The example of application proxy behavior

For example, a task executed against the R/3 server object (which existsphysically on a Managed Node) needs to get redirected down to the actualTMA hosting the R/3 server. The Application Proxy understands how toredirect tasks and Distributed Monitoring profiles. Therefore, ApplicationProxy redirects the task execution request to the appropriate TMA by referringthe Tivoli object database. As you can see, Application Proxy simplifies R/3Manager operations. Please refer to the “Advanced knowledge of TivoliManager for R/3” on page 90 for more information about Application Proxy.

2.3.3 The Tivoli Global Enterprise Manager supportIt is optional, but it is possible to manage R/3 resources by using the TivoliGlobal 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

TMR ServerManager for R/3Application ProxyDM/TEC/SDFW

TEC ServerManager for R/3Application ProxyDM/TEC/SDFW

TMA TMAApplication Server

TMA TMA

EPGW BManager for R/3Application ProxyDM/TEC/SDFW

EPGW AManager for R/3Application ProxyDM/TEC/SDFWApplication Server

MNManager for R/3DM/TEC/SDFWDB Server

Redirect

Tivoli Application Proxy is not a customer product; so, Tivoli ApplicationProxy is always shipped with Tivoli Manager series products. TivoliApplication Proxy is contained in Version 2.0 of Tivoli Manager for R/3CD-ROM media.

Note


looking at the graphics, they can easily understand the status of eachcomponent or relationships between each managed resource. The TivoliGEM server displays your business system information graphically.Consequently, you can graphically monitor, control, and configure yourbusiness system. The following figure (Figure 25) shows a Tivoli GEMconsole screen.

Figure 25. Tivoli Global Enterprise Manager Console

To use Tivoli GEM for your SAP R/3 management, you need to install Version2.0 of Tivoli Manager for R/3 and Tivoli GEM Instrumentation for TivoliManager 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/3Management” on page 271 for more information about Tivoli GEM.


2.3.4 Automatic DiscoveryAutomatic discovery is a new function that dynamically discovers the R/3systems and servers to create Tivoli R/3 objects.

In the previous version of R/3 Manager, each R/3 object is defined by usingSID-specific indication. Version 2.0 of R/3 Manager does not implementSID-specific indication, and it enables the R/3 Manager to perform automaticdiscovery operations. The automatic discovery function provides scalabilityand 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 upthe R/3 management environment, especially in a large-scale managementenvironment. If you attempt to create each R/3 object manually in alarge-scale environment, it might be difficult.

The automatic discovery function is also useful when you move your R/3application server from one machine to another machine or when the SAPR/3 configurations or allocations in your environment are changed frequently.

Automatic discovery provides the schedule list that can set the automaticdiscovery function to run regularly. The schedule list is useful in keepingup-to-date configuration information in your SAP R/3 managementenvironment. The following figure (Figure 26) shows an example of theschedule list.


Figure 26. Schedule setting for automatic discovery

In this example, the automatic discovery is scheduled to run every Tuesday at5 pm.

If you would like to stop running the automatic discovery, simply run thepredefined task called Remove Autodiscovery. You need to run the task onthe target that the automatic discovery is scheduled to run regularly. Theschedule list is maintained by the operating system. Instead of logging intoeach server to change the schedule, this task allows you to disable automaticdiscovery by using the Tivoli Desktop.

Automatic discovery is also useful when you migrate the R/3 Manager fromVersion 1.5 to Version 2.0. Using the automatic discovery function to find theR/3 application server and database server, it can also automatically migrateRFC (Remote Function Call) configuration data and the TEC adapter if R/3Manager has been already installed.

2.3.4.2 Results after Running Automatic DiscoveryAfter running the automatic discovery function, new R/3 objects are createdand an R/3 system icon shows up on the Manager for R3 policy regionautomatically. You will be able to find the R/3 application server and databaseserver (if a database server exists) icons under the R/3 system icon. The


following figure (Figure 27) shows the R/3 system icon that is automaticallycreated 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 asR/3 system SID or R/3 system release. You can see the properties of the R/3system by displaying the pull down menu at the R/3 system icon. Thefollowing figure (Figure 28) shows an example of the R/3 system properties.


Figure 28. R/3 System properties

The automatic discovery function works only when the application server isavailable. Therefore, we recommend that you check the status of theapplication server before performing automatic discovery. Then, theautomatic discovery should work fine.

2.3.5 Improvement of status reportIn Version 2.0 of R/3 Manager, we can see the status of the application servergraphically by checking the status icons. To see the status of the applicationserver, you simply run the Application Server Status monitor on each target.

To show the status graphically, there are four types of icons. The followingfigure (Figure 29) shows each status icon that shows the status of theapplication server.


Figure 29. The status icons of application server

As you can see, the mark on the right corner indicates each status of theapplication server. Although the previous version of R/3 Manager showed nostate at all, the status icon of Version 2.0 of R/3 Manager can provide detailedstatus information. In the previous version of R/3 Manager, the status icononly showed whether the application server was up or down.

2.3.6 Extensive Improvement in RFC API ToolIn Version 2.0 of Tivoli Manager for R/3, the wr3rfc command line interfacecan support a multiple column table. In the previous version of R/3 Manager,the table is able to have only one column.

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.

You must distribute a monitor profile containing the Application ServerStatus Monitor in order to get the icon status. This monitor is in thestandard AutoDiscovery Monitors profile but not in the R3 Server RemoteMonitors profile.

Note


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 thework 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, wewould not be able to display this table by using the wr3rfc command. WithVersion 2.0 of R/3 Manager, we can map the table into its columns so thatwhen the wr3rfcwrites the data, it formats each column correctly according toits data type. In Version 2.0 of R/3 Manager, the character columns aredisplayed as characters and the integer columns are converted to characterto be displayed.

2.3.7 New tasks of Version 2.0 of Tivoli Manager for R/3Tivoli Manager for R/3 provides many predefined tasks that enable you tomanage your SAP R/3 systems easily. In Version 2.0 of R/3 Manager, threenew 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 DiscoveryIn Version 2.0 of R/3 Manager, there are four tasks related to the configureautomatic 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 thefollowing predefined tasks that are located in the R3 Configuration Tasks tasklibrary (refer to Figure 30).


Figure 30. Task library: R3 configuration tasks

You need to run the appropriate task depending on your application serverplatform type. As a result, a discovery schedule is established, and then anewly discovered R/3 system object is created automatically, and its new iconis displayed on the Manager for R3 policy region as we mentioned before. Inthis case, your application server has to be available; otherwise, it will not bediscovered.

When you would like to stop performing the automatic discovery, run theRemove Autodiscovery task. In this case, you need to run the task on thesame Endpoint (system) that you ran the Configure Autodiscovery taskbefore.

2.3.7.2 R/3 Batch JobsIn Version 2.0 of R/3 Manager, three types of tasks related to R/3 batch jobsare added as follows:

• Display Batch Jobs


• Cancel Batch Jobs

• Release Batch Jobs

To use R/3 batch jobs functions, run the following tasks defined in the R3 AppServer Tasks task library. The following figure (Figure 31) shows the R3 AppServer Tasks library.

Figure 31. Task library: R3 App Server tasks

In the following sections, we introduce how to use these tasks and what kindof information you can get as a result of each task.

Display Batch JobsThe Display Batch Jobs task displays the batch jobs by using the followingkey words:

• Date

• Job name

• Job ID

• Scheduled by

• Released by

• Status

• Class


The information that can be obtained by running the Display Batch Job task issimilar to the information that is provided by the R/3 transaction code sm37 atSAPGUI. The following figure (Figure 32) shows the information that isobtained 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 theR/3 transaction code sm37 at SAPGUI.


Figure 33. Job overview alphabetic on SAPGUI

Cancel Batch JobThe 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). Werecommend you run the Display Batch Jobs task first to make sure of theappropriate job ID and job name.

Figure 34. Cancel batch job

Release Batch JobThe Release Batch Job task releases and starts a scheduled task. To executethis task, enter the job ID and job name that you want to release (refer toFigure 35). We recommend you run the Display Batch Jobs task first to makesure of the appropriate job ID and job name.


Figure 35. Release batch job

2.3.7.3 Work ProcessesIn Version 2.0 of R/3 Manager, two types of tasks related to work processesare added:

• Display Work Processes

• Cancel Work Process

To use the work processes function, run the above two tasks that are definedin the R3 App Server Tasks task library (refer to Figure 31).

Display Work ProcessesThe Display Work Processes task displays information about the R/3processes running on a certain application server. In this information, you canfind the process type, process ID, status, and reason. If you also want to knowinformation about the CPU time, enable the CPU time option (refer to Figure36).

Figure 36. Display work process

The information that can be obtained by running the Display Work Processestask is similar to the information that is provided by the R/3 transaction code


sm50 at SAPGUI. The following figure (Figure 37) shows the information thatis 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 theR/3 transaction code sm50 at SAPGUI.


Figure 38. Process overview on SAPGUI

Cancel Work ProcessThe 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 coredump option (refer to Figure 39). We recommend you run Display WorkProcesses 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/3Tivoli Manager for R/3 provides a set of monitoring collections that monitorthe R/3 application server. These monitors run on the Distributed Monitoringengine (Sentry engine).

Version 2.0 of R/3 Manager adds three new monitors:

• Long Running Work Process


• Work Process

• Work Process Dispatch Queue

Tivoli Manager for R/3 provides two monitoring collections for the R/3environment (the R3 Server Remote Monitors and R3 Server CentralMonitors). The three new monitors belong to the R3 Server Remote Monitorsmonitoring collection. The new monitors provide you with the correct numberof running processes and status. You can check these processes if they arenot hanging or if there is no backlog in the work requests. These newmonitors provide better visibility, which helps internal workflow of theapplication server.

These new monitoring profiles are not predefined profiles, and you cannotfind them in the R3 Server Remote Monitors profile. You need to create a newprofile and define it yourself for monitoring. When you configure a profile, youcan select the R3 Server Remote Monitors in the monitoring collectionsfield, and you can find these three new monitors in the monitoring sourcesfield. This procedure is the same as standard Distributed Monitoringconfigurations. In the following sections, we introduce more detailedinformation about these three new monitors.

2.3.8.1 Long Running Work ProcessThe Long Running Work Process monitor will return the number of processesaccording to the specified type of work process whose elapsed time is greaterthan or equal to the specified threshold. When you configure the profile in themonitor argument field, you need to select a process type and enter athreshold in seconds (refer to Figure 40).


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 SourceThe Work Process Source monitor will return the number of processes of thespecified type in the specified state. When you configure the profile, in themonitor argument field, you need to select a work process type and workprocess status (refer to Figure 41).


Figure 41. Add monitor to Sentry profile (work process)

In this configuration, you can define several different types of R/3 workprocess types:

• Dialog

• Update

• Enqueue

• Batch

• Spool

• Update2

• All

You can also define several different types of R/3 work process states:

• Free

• Waiting

• Running


• Stopped

• Completed

• ******

• All

2.3.8.3 Work Process Dispatch QueueThe Work Process Dispatch Queue monitor will return the number of queuedrequests for the specified type. Where, the Nowp type meansnon-work-process processes, for instance, the saprouter program. When youconfigure the profile in the monitor argument field, you need to select a workprocess 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


• Enqueue

• Batch

• Spool

• Update2

• All

2.3.9 Improvement of interconnected TMR supportThis enhancement provides various ways in which one or more TEC eventservers can be configured in relationship to one or more TMRs. For eachconfiguration, the R/3 Manager alert event adapter and the syslog eventadapter always send their events to the default TEC server regardless of theTMR in which it is located. For the alert adapter, additional drill-downprocessing is performed. Drill-down processing sends events using eitherTivoli object calls or the wpostemsg command depending on the type ofEndpoint originating the event.

This enhancement allows you to configure TEC event servers in several ways.

One TMR and one TEC event serverIn this configuration, the TEC event server is defined in the TMR, and theTEC server receives all events.

Multiple TMRs and multiple TEC event serversIn 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, youcan configure a TEC event server to automatically forward events to anotherTEC event server in another TMR.

Multiple TMRs and one TEC event serverIn this configuration, one TEC event server receives events from all TMRs.Support for this configuration depends on the type of Endpoints sendingevents to the TEC server:

• If you want to collect R/3 Manager events only from Managed Nodes, thenyou will need to install the TEC product in every TMR even though theTEC server will only be active in one TMR. Having the TEC productinstalled provides the infrastructure needed by the R/3 Manager forsending events using Tivoli object calls. In this configuration, resourcesmust be shared between the TMRs.

• If you want to collect R/3 Manager events only from TMAs, then you willneed to have the TEC product installed only in the TMR hosting the TECserver. Resources must be exchanged between the TMRs, and the


EventServer class must be registered in all TMRs not hosting the TECserver. This configuration enables the R/3 Manager to send events byusing the wpostemsg command from the TMAs. TEC ACF still is needed onthe Endpoint Gateways in the local TMRs.

2.3.10 User-Configurable Syslog Event AdapterTivoli Manager for R/3 provides a TEC Event Adapter that processes thesyslog and converts new entries into TEC events. Tivoli-provided filteringcapabilities can be applied to these events.

As a result, in Version 2.0 of R/3 Manager, you can configure the syslogadapter yourself to process the syslog and convert new entries into the TECevents. The syslog adapter supports user-defined event classes and serverson a per message basis. The syslog event adapter is very powerful andflexible feature. Please refer to 5.3.3, “Syslog Adapter” on page 189 for moredetailed information.

2.3.11 Filtering eventsIn the prior version of the R/3 Manager environment, you might have somekinds of R/3 events that you do not like to display on the TEC consolebecause these events are unnecessary for further action or considered asharmless events. In this case, to avoid displaying some particular events onthe TEC console you usually filter the events by using the TEC rule basefunction.

In Version 2.0 of R/3 Manager, you can use the following configuration files tofilter the events on the TEC console.

Alert Event Adapter Use the r3mibIID.conf configuration file.

Syslog Event Adapter Use the r3slogIID.cl and r3slogIID.confconfiguration files.

2.3.12 Migration tool for Version 2.0 of Tivoli Manager for R/3Version 2.0 of the R/3 Manager provides two installation methods: freshinstallation and migration (by using the migration tool). The migration tool isavailable for only Version 1.5 or 1.5.1 of the Tivoli Manager for R/3.

In Version 2.0 of the R/3 Manager configuration, collecting R/3 Managerevents to a single TMR from both Managed Nodes and TMAs is notsupported.

Note


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 theApplication Server, use the Auto Discovery tool that is provided by Version2.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 youcarefully read the readme file provided by the tool.

2.3.13 De-install tool for Version 2.0 of Tivoli Manager for R/3Version 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 forthe 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 ManagedNodes 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 theR3Mgr_mn_deinstall.2.0 script is located in the$BINDIR/../generic_unix/TME/SAP directory (on the Managed Node) or in the

There is no upgrade module between Version 1.5.x and 2.0 of the R/3Manager. Therefore, when you have already implemented Version 1.5.x ofthe R/3 Manager and attempt to upgrade R/3 Manager, you need toperform one of the following installation methods:

• Fresh Install

• Migration

However, in both cases, you have to perform a de-install operation of theR/3 Manager.

Note


$LCF_BINDIR/../../generic_unix/TME/SAP directory (on the TMA). Thefollowing table (Table 6) summarizes the de-install script information.

Table 6. Description and Location of two De-install Scripts

As you can see in the following list, the $BINDIR/../generic_unix/TME/SAPdirectory on the TMR server contains two de-install scripts,R3Mgr_tmr_deinstall.2.0 and R3Mgr_tmr_deinstall.2.0.

Once you have completed the de-installation processes by using theR3Mgr_tmr_deinstall20 script on the TMR server and R3Mgr_mn_deinstall20script on all Managed Nodes and TMAs, the Manager for R3 policy region andthe objects that are contained in the Manager for R/3 policy region will bedeleted 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 aManaged Node successfully, the following messages are logged into the logfile 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" ?

Scripts Name Description Location

R3Mgr_tmr_deinstall20 De-installsVersion 2.0 of R/3Manager on theTMR server.

$BINDIR/../generic_unix/TME/SAP

R3Mgr_mn_deinstall20 De-installsVersion 2.0 of R/3Manager on theManaged Nodesand TMAEndpoints.

If Managed Nodes:$BINDIR/../generic_unix/TME/SAP

If TMA Endpoints:$LCF_BINDIR/../../generic_unix/TME/SAP

rootitso@pokibmxtmrb20(/usr/local/Tivoli/bin/generic_unix/TME/SAP)#ls2.2C SAP.init sap_migrate_profile.sh3.0B baroc sappre.initR3Mgr_mn_deinstall.2.0 dsl shR3Mgr_tmr_deinstall.2.0 icons win16SAP.client rls win32


---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 ServerManagedNode1533820760.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

---2.) DELETING YOUR Manager for R3 files at location/usr/local/Tivoli/bin/aix4-r1/TME/TEC/adapters/bin/SAP+rm -rf /usr/local/Tivoli/bin/aix4-r1/TME/TEC/adapters/bin/SAP

---3.) DELETING YOUR Manager for R3 files at location/usr/local/Tivoli/bin/aix4-r1/TME/TEC/adapters/etc/SAP+rm -rf /usr/local/Tivoli/bin/aix4-r1/TME/TEC/adapters/etc/SAP

---4.) DELETING YOUR Manager for R3 files at location/usr/local/Tivoli/bin/aix4-r1/../generic_unix/TME/SAP+rm -rf /usr/local/Tivoli/bin/aix4-r1/../generic_unix/TME/SAP

---5.) DELETING YOUR Manager for R3 files at location/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

---6.) DELETING YOUR Manager for R3 files at location/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

---7.) DELETING YOUR Manager for R3 files at location/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

---8.) DELETING YOUR Manager for R3 files at location/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

---9.) DELETING YOUR Manager for R3 files at location/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


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

---12.)DELETING YOUR Manager for R3 tag files at location/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*

---13.)DELETING YOUR Manager for R3 tag files at location/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

---14.)DELETING YOUR Manager for R3 tag files at location/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

---15.)DELETING YOUR Manager for R3 tag files at location/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

---16.)DELETING YOUR Manager for R3 tag files at location/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 theappropriate R3 Manager manuals.

2.3.14 Delivery of ABAP program using J classIn an SAP R/3 systems environment, the Y and Z classes are reserved forcustomers’ use. In the previous version of the R/3 Manager, the Z class is foryour 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) developmentclass:

• J_8C1_ALERT_CONTROL

• J_8C1_ALERT_READER

• J_8C1_BUFFER_INFO

• J_8C1_BUFFER_NAMES


• 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 packageIn the R/3 Manager configurations, one of the configuration processes entailsmoving the transports to the R/3 application server. In Version 2.0 of the R/3Manager, to move the transports you can use the one of the followingmethods:

• 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 ofsubscribers. In the case of using the R/3 ABAP file package distribution, youdo not need to copy the transport files one by one manually.

Once Version 2.0 of the R/3 Manager installation is completed successfully inyour TMR, the R3 Transport profile manager is created in the Manager for R3policy region. In the R3 Transport profile manager, the R3 ABAP file packagehas already been created. Then, you just need to define the subscribers anddistribute the file package to the appropriate targets. For more informationabout importing R/3 transports, please refer to Chapter 4, “Planning andimplementation” on page 119.

2.3.15 New R/3 specific event sourcesAfter configuring the TEC event console, you will find new event source groupicons called WR3MIB and WRSLOG. These two event source groups informyou which event source generates the events efficiently. The following figure(Figure 43) shows the icons of these new event sources.


Figure 43. New TEC event source icons

2.4 Advanced knowledge of Tivoli Manager for R/3

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

2.4.1 R/3 Manager Endpoint methodsAs we mentioned, Tivoli Manager for R/3 supports TMA. To support TMA, theR/3 Manager provides Endpoint methods as well as other Tivoli ManagementApplications. These new Endpoint methods are managed by the dependency

The detailed information about these new functions that are provided byVersion 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 andChapter 5, “Managing SAP R/3 environment” on page 163 for moreinformation.

Note


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 ManagementThe Endpoint method cache management is very important in understandingthe R/3 Manager implementation on TMA. The TMA gives you the Frameworkfunctions that are necessary to perform management operations, such asthose performed by Tivoli Manager for R/3, and these managementoperations are processed by calling a method on a managed resource. In theTMA environment, this design has not changed: The TMA invokes anEndpoint method for performing management operations on the TMAplatform.

The Endpoint methods that will be used by the Endpoint are stored in theEndpoint Gateway. When the Endpoint performs an R/3 managementoperation, the Endpoint automatically determines what is needed to performthe given management operation. If that Endpoint method already resides onthe Endpoint, it immediately proceeds with the R/3 management operation. Ifnot, the Endpoint downloads the appropriate Endpoint method from theEndpoint Gateway to the Endpoint with no operator intervention. In addition,the Endpoint downloads newer versions as updates are loaded on theEndpoint Gateway. You can gain significant productivity advances with thesemanagement features because the R/3 Manager is installed only once on theEndpoint Manager (TMR server) and Endpoint Gateways, with updatesperformed automatically thereafter. The following figure (Figure 44) showshow Endpoint Gateway and Endpoint handle Endpoint methods.


Figure 44. Endpoint method cache management

By default, the Endpoint method cache exists under theC:\Tivoli\lcf\dat\1\cache (for Windows NT) or /opt/Tivoli/lcf/dat/1/cache (forUNIX) directory. The Endpoint Gateway stores the Endpoint methods underthe /usr/local/Tivoli/bin/lcf_bundle directory and also stores Endpoint methodinformation in the Endpoint Gateway database ($DBDIR/gwdb.bdb file). Thisinformation can be synchronized with the information on the EndpointManager ($DBDIR/imdb.bdb file) by using the wgateway gw_label dbcheck

command.

The following summary describes how the Endpoint manages the Endpointmethod cache.

• Once the Endpoint method is stored in the Endpoint method cache, theEndpoint uses it even if the system is rebooted.

Endpoint Manager

Endpoint Gateway

Endpoint Method Cache

Endpoint(SAP Server)

R/3 ManagerInstallation

Downcall

Method

Method Cache Synchronize(wgateway gw_name dbcheck)


• 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 currentversion of the Endpoint method, the Endpoint downloads the newermethod automatically.

• When the Endpoint downloads the Endpoint method, the related methodsthat are defined in the dependency set are also downloaded at the sametime. The dependency set is a list of other files, modules, or commandsthat are required for the correct operation of the method.

2.4.1.2 Endpoint Method and R/3 ManagerTivoli Manager for R/3 invokes methods by using upcalls and downcalls toperform its management functions as well as other Tivoli ManagementApplications. Which method will be used by the R/3 Manager? Thedependency manager handles the methods for each Tivoli ManagementApplication. The dependency manager exists as a class object in the Tivoliobject database and plays a very important role in implementing the LCFarchitecture. We can understand the relationship between the Endpointmethod and R/3 Manager by checking the dependency manager.

2.4.1.3 Dependency Sets for R/3 ManagerNormally, the dependency set is added to the dependency manager wheninstalling the Tivoli Management Application (but it is not mandatory; itdepends on the application design).

When R/3 Manager is installed completely, and the R3AppServer object iscreated, the following three dependency sets will be added into thedependency manager:

• sap_dep

• sap_lib_dep

• sap_tool_dep

You can see these dependency sets by using the wlookup command asfollows:

wlookup -ar DependencyMgr

You also can see the contents of these dependency sets for the R/3 Managerby using the wdepset command as follows:

wdepset -v 1533820760.1.970

where,


1533820760.1.970 is the object ID of the sap_dep dependency set in ourenvironment. For example, in our environment, the following Endpointmethods are defined in the sap_dep dependency set.

# wdepset -v 1533820760.1.970w32-ix86:bin/w32-ix86/TME/SAP/2.2C/wr3mib.exe,../../bin/w32-ix86/TME/SAP/2.2C,8bin/w32-ix86/TME/SAP/2.2C/tecad_wr3mib.exe,../../bin/w32-ix86/TME/SAP/2.2C,8bin/w32-ix86/TME/SAP/2.2C/tecad_wr3mib.conf,../../bin/w32-ix86/TME/SAP/2.2C,8bin/w32-ix86/TME/SAP/2.2C/wr3slog.exe,../../bin/w32-ix86/TME/SAP/2.2C,8bin/w32-ix86/TME/SAP/2.2C/tecad_wr3slog.conf,../../bin/w32-ix86/TME/SAP/2.2C,8bin/w32-ix86/TME/SAP/2.2C/tecad_wr3slog.cl,../../bin/w32-ix86/TME/SAP/2.2C,8bin/w32-ix86/TME/SAP/2.2C/wr3rfc.exe,../../bin/w32-ix86/TME/SAP/2.2C,8bin/w32-ix86/TME/SAP/2.2C/wbindmsg.exe,../../bin/w32-ix86/TME/SAP/2.2C,8bin/w32-ix86/tools/bash.exe,%TOOLS%,8bin/w32-ix86/tools/sh.exe,%TOOLS%,8bin/w32-ix86/tools/echo.exe,%TOOLS%,8bin/w32-ix86/tools/expr.exe,%TOOLS%,8bin/w32-ix86/tools/win32gnu.dll,%TOOLS%,8bin/w32-ix86/tools/sed.exe,%TOOLS%,8bin/w32-ix86/tools/tr.exe,%TOOLS%,8hpux10:bin/hpux10/TME/SAP/2.2C/wr3mib,../../bin/hpux10/TME/SAP/2.2C,8bin/hpux10/TME/SAP/2.2C/tecad_wr3mib,../../bin/hpux10/TME/SAP/2.2C,8bin/hpux10/TME/SAP/2.2C/tecad_wr3mib.conf,../../bin/hpux10/TME/SAP/2.2C,8bin/hpux10/TME/SAP/2.2C/wr3slog,../../bin/hpux10/TME/SAP/2.2C,8bin/hpux10/TME/SAP/2.2C/tecad_wr3slog.conf,../../bin/hpux10/TME/SAP/2.2C,8bin/hpux10/TME/SAP/2.2C/tecad_wr3slog.cl,../../bin/hpux10/TME/SAP/2.2C,8bin/hpux10/TME/SAP/2.2C/wr3rfc,../../bin/hpux10/TME/SAP/2.2C,8bin/hpux10/TME/SAP/2.2C/wbindmsg,../../bin/hpux10/TME/SAP/2.2C,8solaris2:bin/solaris2/TME/SAP/2.2C/wr3mib,../../bin/solaris2/TME/SAP/2.2C,8bin/solaris2/TME/SAP/2.2C/tecad_wr3mib,../../bin/solaris2/TME/SAP/2.2C,8bin/solaris2/TME/SAP/2.2C/tecad_wr3mib.conf,../../bin/solaris2/TME/SAP/2.2C,8bin/solaris2/TME/SAP/2.2C/wr3slog,../../bin/solaris2/TME/SAP/2.2C,8bin/solaris2/TME/SAP/2.2C/tecad_wr3slog.conf,../../bin/solaris2/TME/SAP/2.2C,8bin/solaris2/TME/SAP/2.2C/tecad_wr3slog.cl,../../bin/solaris2/TME/SAP/2.2C,8bin/solaris2/TME/SAP/2.2C/wr3rfc,../../bin/solaris2/TME/SAP/2.2C,8bin/solaris2/TME/SAP/2.2C/wbindmsg,../../bin/solaris2/TME/SAP/2.2C,8aix4-r1:bin/aix4-r1/TME/SAP/2.2C/wr3mib,../../bin/aix4-r1/TME/SAP/2.2C,8bin/aix4-r1/TME/SAP/2.2C/tecad_wr3mib,../../bin/aix4-r1/TME/SAP/2.2C,8bin/aix4-r1/TME/SAP/2.2C/tecad_wr3mib.conf,../../bin/aix4-r1/TME/SAP/2.2C,8bin/aix4-r1/TME/SAP/2.2C/wr3slog,../../bin/aix4-r1/TME/SAP/2.2C,8bin/aix4-r1/TME/SAP/2.2C/tecad_wr3slog.conf,../../bin/aix4-r1/TME/SAP/2.2C,8bin/aix4-r1/TME/SAP/2.2C/tecad_wr3slog.cl,../../bin/aix4-r1/TME/SAP/2.2C,8bin/aix4-r1/TME/SAP/2.2C/wr3rfc,../../bin/aix4-r1/TME/SAP/2.2C,8bin/aix4-r1/TME/SAP/2.2C/wbindmsg,../../bin/aix4-r1/TME/SAP/2.2C,8generic:bin/generic_unix/TME/SAP/sh/sap_common.sh,../../bin/generic_unix/TME/SAP/sh,8bin/generic_unix/TME/SAP/sh/sap_adapter_common.sh,../../bin/generic_unix/TME/SAP/sh,8bin/generic_unix/TME/SAP/2.2C/sh/sap_start.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8bin/generic_unix/TME/SAP/2.2C/sh/sap_start_db.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8bin/generic_unix/TME/SAP/2.2C/sh/sap_start_dbaccess.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8bin/generic_unix/TME/SAP/2.2C/sh/sap_start_sapgui.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8bin/generic_unix/TME/SAP/2.2C/sh/sap_start_server.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8bin/generic_unix/TME/SAP/2.2C/sh/sap_start_adapter.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8


bin/generic_unix/TME/SAP/2.2C/sh/sap_start_adapter_internal.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8bin/generic_unix/TME/SAP/2.2C/sh/sap_stop_db.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8bin/generic_unix/TME/SAP/2.2C/sh/sap_stop_server.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8bin/generic_unix/TME/SAP/2.2C/sh/sap_clean_adapter.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8bin/generic_unix/TME/SAP/2.2C/sh/sap_stop_adapter.sh,../../bin/generic_unix/TME/SAP/2.2C/sh,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_ALERT_CONTROL.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_ALERT_READER.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_BUFFER_INFO.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_BUFFER_NAMES.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_OS390_COLLECT.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_OS390_DB2.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_OS_COLLECT.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_ROLL_PAGE_SIZES.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_DISPLAY_BATCH.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_DISPLAY_PROCESSES.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_PROC_MONITORS.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_MODIFY_JOB.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8bin/generic_unix/TME/SAP/2.2C/rfc/wr3rfc_cfg.txt,../../bin/generic_unix/TME/SAP/2.2C/rfc,8msg_cat/C/R3MgrSyslogMsg.cat,%MSGCAT%/C,8msg_cat/C/R3MgrRfcMsg.cat,%MSGCAT%/C,8msg_cat/C/R3MgrMibMsg.cat,%MSGCAT%/C,8bin/generic_unix/TME/SAP/2.2C/rfc/J_8C1_MODIFY_PROCESS.TXT,../../bin/generic_unix/TME/SAP/2.2C/rfc,8depset: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 eachsupport platform that is defined in the specified dependency set. TheseEndpoint methods should be located under the /usr/local/Tivoli/bin/lcf_bundledirectory and loaded to the Endpoint method cache in the Endpoint where theR/3 Manager function is called for the first time (for instance, when wediscover or define an SAP application server on the Endpoint for the firsttime).

2.4.1.4 How Endpoint Methods Work on SAP ServerAs we mentioned, the R/3 Manager provides the Endpoint methods that willbe invoked on the Endpoint for monitoring or controlling a SAP server runningon an Endpoint machine. This section introduces how these Endpoint


methods are loaded to the Endpoint and how they work. The following figure(Figure 45) shows the relationship between the dependency manager andEndpoint methods.

Figure 45. R/3 Manager Endpoint methods handling

1. The R/3 Configuration Task that discovers and defines an SAP applicationserver on the Endpoint that SAP server is running is executed on theEndpoint initially.

2. Then, the Endpoint Gateway checks the Endpoint for the existence of theappropriate executables that are defined in the dependency set. Since thisis the initial discovery and definition, the Endpoint cannot find theexecutable files in the cache on the local disk. Therefore, the EndpointGateway loads these executables into the Endpoint method cache.

DependencyMgr

sap_dep1533820760.1.970#Depends::Mgr#

Method CacheSAP Server (Endpoint)

EP Gateway

EP Manager

Dependency Set

Download

1

2

3

R/3 Configuration Task

Discover/Define/usr/local/Tivoli/bin/lcf_bundle


3. The R/3 Configuration Task that is executed on the Endpoint is completedand discovers and defines the SAP application server on the Endpoint.

Endpoint methods are highly flexible. The software installation process isunnecessary for an Endpoint because an Endpoint downloads the newestmethods automatically. This means the software upgrade process is alsounnecessary for an Endpoint.

2.4.1.5 Dataless Profile Manager and EndpointThe dataless profile manager is a new profile manager type associated withthe dataless client (TMA). The dataless profile manager can have thefollowing subscribers:

• Endpoints

• Managed Nodes

• PC Managed Nodes

• NIS Domains

• NetWare Managed Sites

As you can see in the list above, other profile managers cannot besubscribers to the dataless profile manager. Therefore, the dataless profilemanager cannot be a branch node in a profile manager hierarchy. A datalessprofile manager can only be a leaf node, that is, only have managed systemsas subscribers.

There are some triggers of downloading Endpoint methods other than theabove. 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 defineR3AppServer.

Note

Tivoli Manager for R/3 supports Tivoli Management Agent (TMA).Therefore, when you push a R/3 monitor to Endpoint subscribers, you haveto use the dataless profile manager. It is the same as all other TivoliManagement Applications.

Note


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 notwritten to the database associated with the next level even if it is a fullManaged Node (refer to Figure 46). Therefore, if you distribute the profile byusing the dataless profile manager to full Managed Nodes or Endpoints, thedata is applied directly to the system.

The profile created in the classic profile manager can be locally modifiedbecause the information in the profile is written to the local database of thefull Managed Node. However, the local modification is not a recommendedcustomization because it makes profile management more complicated, andit also makes future migration from a full Managed Node to the TMA moredifficult.

Figure 46. The Difference between dataless and classic profile manager

The dataless profile manager is developed for supporting Endpointsubscribers. However, almost all features, except writing information to thedatabase, are the same as the classic profile manager, for example, definingthe profile, handling the profile, and so on.

Managed Node Managed NodeObject Database Object Database

ProfileProfile

Local Modification

Classic Profile Manager Dataless Profile Manager


2.4.2 R/3 Manager objectTivoli manages each managed resource as an object, and these objects arestored in Tivoli object databases (.bdb files). Tivoli also provides Tivoli NameRegistry (TNR), which is a quick lookup table of object labels and object IDs.All Tivoli Management Applications that are running on Tivoli ManagementFramework should use these objects, and each resource can be referred froman application or program by using an object label or ID. Version 2.0 of R/3Manager is also one of the Tivoli Management Applications that is running onthe Tivoli Framework. Therefore, R/3 Manager adds some new objects intothe Tivoli object databases. In this section, we introduce an overview of theTivoli object and R/3 Manager.

2.4.2.1 New Resource Types for R/3 ManagerWhen you install and configure R/3 Manager properly, the following newresource 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 objectinstances. When you configure your R/3 Manager environment properly, eachobject will have the appropriate object instances. You can check the instancesof the specified resource type in the TNR by using the wlookup command. Forexample, the following are object instances of the R3System resource type inour environment.


2.4.2.2 Attribute of New R/3 Manager ResourceEach object instance of the R/3 Manager resource has attributes as well asother Tivoli objects. You can check the attributes of each object instance byusing the objcall command as follows.

Some of these attribute values cannot be displayed or modified by Tivoli highlevel commands. If you need to display or modify an attribute for somereason, use the idlattr or idlcall command. In this section, we introducehow to refer to an attribute of R3 System resource object.

The Object AttributeEach attribute of an object instance has value, and you can refer to the valueby using the idlattr or idlcall command. The following example shows how

# wlookup -ar R3Systemis1n05_PD9 1533820760.1.1183#R3::R3System#wwdn07_IG3 1533820760.1.1156#R3::R3System##

# objcall 1533820760.1.1183 contentsATTRIBUTE:ABH_ObjectVersionATTRIBUTE:_BOA_idATTRIBUTE:app_contextATTRIBUTE:class_objidATTRIBUTE:classesATTRIBUTE:collectionsATTRIBUTE:databasesATTRIBUTE:disable_engineUpdateATTRIBUTE:disable_run_taskATTRIBUTE:disable_systemATTRIBUTE:endpoint_oidATTRIBUTE:labelATTRIBUTE:last_failedATTRIBUTE:membersATTRIBUTE:pres_objectATTRIBUTE:proATTRIBUTE:pro_nameATTRIBUTE:profile_push_orderATTRIBUTE:push_trans_commit_behaviorATTRIBUTE:resource_hostATTRIBUTE:skeletonATTRIBUTE:sort_nameATTRIBUTE:stateATTRIBUTE:subscriptionsATTRIBUTE:system_timeout#

Use the idlattr and idlcall commands with caution. These commands arenot officially supported, and may adversely affect system configuration ifyou perform the wrong operation.

Note


to refer to the system_timeout attribute value of an R3 System object by usingthe idlattr command.

You also can use the idlcall command to display the system_timeoutattribute value as follows.

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

# idlattr -tg 1533820760.1.1183 system_timeout long300#

# idlcall 1533820760.10.23 _get_system_timeout300#


In this part of the section, we introduced an example of an R3 Systemresource type. However, you can use the same method to explore the Tivoliobject databases and find other objects related to R/3 Manager.

The system_timeout attribute is used by objects related to the R/3Manager, for example, R3Stsrem, R3AppServer, and R3DBServer. Youhave probably experienced a problem in a large-scale environment withhanging distributions; wherein, the failure of a single Endpoint keeps theoverall distribution from proceeding. Even if the process only hangs on oneof the targets (R/3 object), the overall distribution process never returns. Toavoid this situation, the system_timeout is provided. The system_timeoutsets a client-level timeout value for all requests to the R/3 objects.

On the other hand, the session_timeout is provided by the EndpointGateway and specifies the timeout value for the connection between theEndpoint Gateway and its Endpoints. During the data transfer from theEndpoint Gateway to the Endpoint, if the Endpoint stops receiving the datafor a period longer than the value set by the session_timeout parameter,the Endpoint Gateway terminates the distribution to that Endpoint andrecords the timeout error.

The timeout mechanism between the Endpoint Gateway and its Endpointsis very flexible. You do not need to configure the session_timeout each timeyou modify the system_timeout of R/3 objects. The system_timeoutattribute setting overrides the session_timeout setting if thesystem_timeout is modified. The session_timeout and system_timeout areset to 300 seconds by default.

The session_timeout affects each application that runs on the Endpointand issues a downcall, for example, Inventory and Software Distribution. Inother words, the session_timeout value is the timeout for a downcall.Moreover, the session_timeout affects all Endpoints that are managed bythe Endpoint Gateway. Therefore, you do not need to configure thesession_timeout value for each session between the Endpoint Gatewayand Endpoint.

If you need to modify the session_timeout value for some reason, you canmodify this value by using the wgateway command as follows:

wgateway <gw_label> set_session_timeout value

Note


2.4.3 Tivoli Application Proxy internalsTo understand R/3 Manager TMA support, understanding the behavior ofTivoli Application Proxy is very important. Tivoli Application Proxy plays a vitalrole in supporting TMA. We introduced the overview of Application Proxy atthe beginning of this chapter; so, this section introduces detailed informationabout Application Proxy.

2.4.3.1 How Application Proxy WorksIn R/3 Manager configurations, the Application Proxy must be installed on theTMR server, on the TEC server, and on each Managed Node that runs an R/3application server or on the Endpoint Gateway if the R/3 application serverruns on an Endpoint (TMA).

The main design issue for TMA is the decision to create the R/3 applicationobjects (R3System, R3AppServer, R3DBServer, and so on) on the ManagedNode because it is not possible to create the R/3 application objects on TMA.The following figure (Figure 47) shows the relationship between theApplication Proxy and the Tivoli object database.

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.

R/3 Appl Server

R/3 Appl Server

TMR Server

Endpoint Gateway

Endpoint

Managed Node

APPLPROXYAPPLPROXY

Object DB Object DB

R/3 ObjectsR/3 Objects


• Application Proxy provides an upcall collector and command line programsto assist in the initial creation and configuration of objects from a taskrunning on TMA.

• Application Proxy provides a simple execution mechanism for runningscript on TMA.

The IDL interface plays a vital role in these functions. The IDL interface allowsthe R/3 object on a Managed Node to redirect, or proxy, operations that needto execute on a TMA node.

2.4.3.2 The list of context variablesApplication Proxy is used to maintain a list of context variables in the form ofName=Value. This context is added to the environment for all tasks andSentry monitors that run on the TMA node.

The context variables are stored as a StringList attribute called app_contexton each R/3 object. You can refer to these context variables by using theidlattr or idlcall command as follows.

idlattr -t -g <OID> app_context TMF_Types::StringList

or

idlcall <OID> _get_app_context

The following example shows the output of the idlcall command execution torefer to the context variables of the R3System object.

As you can see, this information is the almost same as the information that isobtained by using Tivoli Desktop (refer to Figure 28 on page 69).

Use the idlattr and idlcall commands with caution. These commands arenot officially supported, and may adversely affect system configuration ifyou perform the wrong operation.

Note

# wlookup -ar R3Systemis1n05_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_UseABH_Passwd=" "ABH_Language=" "ABH_DBRelease=" }#


2.4.3.3 Future plan of Application ProxyApplication Proxy is developed to support TMA. Application Proxy could bethought of as code shared between the Tivoli Manager series productsbecause several functions that would be useful for all the Tivoli Managerseries products can be shared.

Other Tivoli Manager series products will, in the near future, support TMA byusing Application Proxy.



Chapter 3. Our SAP R/3 System environment

Our environment was created to reflect the problems faced whencommencing a large scale implementation of Tivoli solutions in an SAP R/3landscape.

Although our environment was not actually large, the results can bereproduced depending on whether you have ten or one thousand systems.The theories and practices discovered and explained in this book can beapplied regardless of organization size.

All of the people who co-authored this book have been involved in largeimplementations of Tivoli or SAP R/3, and in some cases, both. Therefore, allare familiar with the problems faced when implementing an effectivemonitoring solution for SAP R/3.

This chapter introduces and explains our environment, paying close attentionto the hardware and applications involved. This includes full descriptions ofthe system configurations, database configurations, and the Tivoli productsused in this environment.

3.1 Overview of our environment

The following figure illustrates the overall layout of our environment and themachines involved. This figure only gives a brief overview of the environment.Each component will be discussed in depth further on in this chapter.


Figure 48. Overview of our environment

Our environment consisted of eight machines that were part of the TivoliManagement Environment, which means that they all had the TivoliFramework installed as well as any additional Tivoli products that wererequired for this book. The two SAP R/3 systems that complete ourenvironment were configured as Tivoli Management Agents (TMAs). Thewlsinst command was used on both machines with the -ah option to displayinstalled Tivoli products by hostname and the -ah option to display installedpatches and service releases, again by hostname. The following list containsa detailed description and list of all the machines in our Tivoli ManagementEnvironment.

POKIBMXTMRB20This machine was chosen to be the Tivoli Management Region server forboth SAP R/3 systems. The machine had a connection to each of the twoEndpoint Gateway machines, POKIBMXEGWB22 and POKIBMXEGWB21.This was to allow the exchange of a number of resources including Profile

POKIBMTAPMWindows NT 4Tivoli Application Performance ManagerTivoli Decision Support Demo

POKIBMGEMWindows NT 4Tivoli Global Enterprise Manager

POKIBMXTECB20AIX 4.3Tivoli Enterprise Console

POKIBMXTMRB20AIX 4.3TMR Server

POKIBMXEGWB21AIX 4.3

Gateway Server 1

POKIBMXEGWB22AIX 4.3Gateway Server 2

WWDN07AIX 4.2SAP R/3 4.0B

IS1N05AIX 4.2

SAP R/3 3.0F


Managers, Event Servers and Administrators. The specifications of themachine 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

POKIBMXTECB20This machine ran the Tivoli Enterprise Console in our landscape, and it waslinked directly into the POKIBMXTMRB20 machine. Because the TivoliEnterprise Console requires a quite a lot of processing power to run it, thismachine was more powerful than the TMR machine in terms of processorpower. However, it had less memory and hard disk space because these arenot so necessary to a Tivoli Enterprise Console server. The actual hardwaredetails 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

Distributed Monitoring ARM Agent 3.6.1 Maintenance ReleaseDistributed Monitoring ARM Monitors 3.6.1 Maintenance ReleaseDistributed Monitoring ARM EndPoint 3.6.1 Maintenance ReleaseTivoli Software Distribution Patch 3.6.1-COU-0002Tivoli Software Distribution Gateway Patch 3.6.1-COU-0003Tivoli Distributed Monitoring Patch 3.6.1-DMN-0008Tivoli Distributed Monitoring Patch 3.6.1-DMN-0013TME 10 Distributed Monitoring 3.6.1 Maintenance ReleaseTivoli Enterprise Console Patch 3.6.1-TEC-0002 (ACF)Tivoli Framework Patch 3.6.1-TMF-0004 (build 04/13)Tivoli Framework Patch 3.6.1-TMF-0028 (build 06/22)Tivoli Framework Version 3.6.1 Patch 3.6.1-TMF-0029 (build 06/24)TME 10 Enterprise Console Adapter Configuration Facility 3.6.1TME 10 Software Distribution Upgrade, Version 3.6 to 3.6.1TME 10 Software Distribution Gateway, Upgrade Version 3.6 to 3.6.1Tivoli 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.1Tivoli Distributed Monitoring TME Monitors Patch 3.6.1-DMN-0013Tivoli Distributed Monitoring Universal Monitors Patch 3.6.1-DMN-0013Tivoli Distributed Monitoring Unix Monitors Patch 3.6.1-DMN-0013

Patches Installed on POKIBMXTMRB20








• Tivoli Enterprise Console EIF 3.6



• Tivoli Enterprise Console Event Console 3.6

• Tivoli Enterprise Console Server 3.6

POKIBMGEMThis was a machine that we installed with Windows NT 4.0 then configured torun the Global Enterprise Manager (GEM). In order to give some indication ofwhat the requirements for Global Enterprise Manager are, here are thehardware specifications of this machine:

• Dual Pentium Pro 200 Mhz

• 288 Mb RAM

• 7 Gig HD space

Distributed Monitoring ARM Agent 3.6.1 Maintenance ReleaseDistributed Monitoring ARM Monitors 3.6.1 Maintenance ReleaseDistributed Monitoring ARM EndPoint 3.6.1 Maintenance ReleaseTivoli Software Distribution Patch 3.6.1-COU-0002Tivoli Distributed Monitoring Patch 3.6.1-DMN-0008Tivoli Distributed Monitoring Patch 3.6.1-DMN-0013TME 10 Distributed Monitoring 3.6.1 Maintenance ReleaseTivoli Enterprise Console Patch 3.6.1-TEC-0002 (ACF)Tivoli Framework Version 3.6.1 Patch 3.6.1-TMF-0029 (build 06/24)TME 10 Enterprise Console Adapter Configuration Facility 3.6.1TME 10 Software Distribution Upgrade, Version 3.6 to 3.6.1TME 10 Enterprise Console Server 3.6.1Tivoli 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)

Patches Installed on POKIBMXTECB20


The software installed on this machine are as follows:



• Tivoli GEM Topology Console 2.2.1

• Tivoli GEM Topology Server 2.2.1

POKIBMTAPMThis was installed and configured to run Tivoli Application PerformanceManager (TAPM). The hardware specifications of this machine were exactlythe same as for the POKIBMGEM machine. However, the softwareconfiguration was different in a few ways. The software installed on thismachine was as follows:


• Sybase Adaptive Server Enterprise 11.9.2



• Tivoli Software Installation Service 3.6


• Tivoli Manager for Application Performance Monitor Componentversion 1.0

• Tivoli Manager for Application Performance Server Component

• Tivoli Distributed Monitoring TME Monitors 3.6

Tivoli Management Framework 3.6.1 Maintenance Release (build 02/12)

Patches Installed on POKIBMGEM

Distributed Monitoring ARM Agent 3.6.1 Maintenance ReleaseTME 10 Distributed Monitoring 3.6.1 Maintenance ReleaseTivoli Software Installation Service 3.6.1 Patch (3.6.1-SIS-0001)TME 10 Software Installation Service upgrade to 3.6.1Tivoli Management Framework 3.6.1 Maintenance Release (build 02/12)TME 10 Distributed Monitoring TME Monitors 3.6.1

Patches Installed on POKIBMTAPM


POKIBMXEGWB21This machine was one of the two Endpoint Gateways in our environment. Thismachine 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











POKIBMXEGWB22This was the second of the two Endpoint Gateway machines. LikePOKIBMXEGWB21, this machine also had a connection to both SAP R/3systems. The hardware configuration was as follows:

• Uni processor

• 320 Mb RAM

• 18 Gig HD space

This machine had a hardware configuration almost the same asPOKIBMXEGWB21. The software configuration was as follows:









Distributed Monitoring ARM Agent 3.6.1 Maintenance ReleaseDistributed Monitoring ARM Monitors 3.6.1 Maintenance ReleaseDistributed Monitoring ARM EndPoint 3.6.1 Maintenance ReleaseTivoli Software Distribution Patch 3.6.1-COU-0002Tivoli Software Distribution Gateway Patch 3.6.1-COU-0003Tivoli Distributed Monitoring Patch 3.6.1-DMN-0008Tivoli Distributed Monitoring Patch 3.6.1-DMN-0013TME 10 Distributed Monitoring 3.6.1 Maintenance ReleaseTivoli Enterprise Console Patch 3.6.1-TEC-0002 (ACF)Tivoli Framework Patch 3.6.1-TMF-0004 (build 04/13)Tivoli Framework Patch 3.6.1-TMF-0028 (build 06/22)Tivoli Framework Version 3.6.1 Patch 3.6.1-TMF-0029 (build 06/24)TME 10 Enterprise Console Adapter Configuration Facility 3.6.1TME 10 Software Distribution Upgrade, Version 3.6 to 3.6.1TME 10 Software Distribution Gateway, Upgrade Version 3.6 to 3.6.1Tivoli 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)

Patches Installed on POKIBMXEGWB21



3.2 Overview of our SAP R/3 environment

Regardless of how many machines an environment has, the problems andchallenges encountered in implementing a robust and controllablemanagement solution are the same. Therefore, the fact that our SAP R/3environment only had two SAP application servers was not a problem. Bothmachines were IBM System Parallel (SP) nodes, one thin and one wide node.They were both the database and application server in a single machine andhad no direct connection between them. What follows is a brief description ofthe hardware and software of these two machines.

IS1N05This was the wide node of the two. The hardware configuration was asfollows:

• Uni processor

• 512 Mb RAM

• 49 Gig HD space

The following list provides the node’s software configuration:

• AIX 4.2.1

Distributed Monitoring ARM Agent 3.6.1 Maintenance ReleaseDistributed Monitoring ARM Monitors 3.6.1 Maintenance ReleaseDistributed Monitoring ARM EndPoint 3.6.1 Maintenance ReleaseTivoli Software Distribution Patch 3.6.1-COU-0002Tivoli Software Distribution Gateway Patch 3.6.1-COU-0003Tivoli Distributed Monitoring Patch 3.6.1-DMN-0008Tivoli Distributed Monitoring Patch 3.6.1-DMN-0013TME 10 Distributed Monitoring 3.6.1 Maintenance ReleaseTivoli Enterprise Console Patch 3.6.1-TEC-0002 (ACF)Tivoli Framework Patch 3.6.1-TMF-0004 (build 04/13)Tivoli Framework Patch 3.6.1-TMF-0028 (build 06/22)Tivoli Framework Version 3.6.1 Patch 3.6.1-TMF-0029 (build 06/24)TME 10 Enterprise Console Adapter Configuration Facility 3.6.1TME 10 Software Distribution Upgrade, Version 3.6 to 3.6.1TME 10 Software Distribution Gateway, Upgrade Version 3.6 to 3.6.1Tivoli 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)

Patches Installed on POKIBMXEGWB22


• SAP R/3 3.0F

• DB2 2.1.2

• MQSeries 5.0










The SAP R/3 and DB2 versions were relatively low on this machine comparedto latest code levels. However, the Tivoli Manager for R/3 still supported theseapplication code levels on this machine.

Distributed Monitoring ARM Agent 3.6.1 Maintenance ReleaseDistributed Monitoring ARM Monitors 3.6.1 Maintenance ReleaseDistributed Monitoring ARM EndPoint 3.6.1 Maintenance ReleaseTivoli Distributed Monitoring Patch 3.6.1-DMN-0008Tivoli Distributed Monitoring Patch 3.6.1-DMN-0013TME 10 Distributed Monitoring 3.6.1 Maintenance ReleaseTivoli Enterprise Console Patch 3.6.1-TEC-0002 (ACF)TME 10 Enterprise Console Adapter Configuration Facility 3.6.1TME 10 Software Distribution Upgrade, Version 3.6 to 3.6.1Tivoli 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 TME Monitors 3.6.1TME 10 Distributed Monitoring Universal Monitors 3.6.1TME 10 Distributed Monitoring Unix Monitors 3.6.1

Patches Installed on IS1N05


WWDN07This 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










The Tivoli Manager for R/3 used during the project of this redbook was abeta code version. The versions of SAP R/3 that are supported by thisproduct are subject to change at any time before or after release of themodule.

Note


This system had the higher code and version levels of the two systems. Itprovided us with a relatively high level system with which to test theperformance of the Manager for R/3.

Distributed Monitoring ARM Agent 3.6.1 Maintenance ReleaseDistributed Monitoring ARM Monitors 3.6.1 Maintenance ReleaseDistributed Monitoring ARM EndPoint 3.6.1 Maintenance ReleaseTivoli Distributed Monitoring Patch 3.6.1-DMN-0008Tivoli Distributed Monitoring Patch 3.6.1-DMN-0013TME 10 Distributed Monitoring 3.6.1 Maintenance ReleaseTivoli Enterprise Console Patch 3.6.1-TEC-0002 (ACF)TME 10 Enterprise Console Adapter Configuration Facility 3.6.1TME 10 Software Distribution Upgrade, Version 3.6 to 3.6.1Tivoli 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 TME Monitors 3.6.1TME 10 Distributed Monitoring Universal Monitors 3.6.1TME 10 Distributed Monitoring Unix Monitors 3.6.1

Patches Installed on WWDN07


Chapter 4. Planning and implementation

In this chapter, we describe how to set up the environment in which wemanage our SAP R/3 installation, that is, the installation and configuration ofthe SAP R/3 system itself as well as the necessary Tivoli Enterprisecomponents.

We describe in detail how to set up the SAP R/3 systems and Version 2.0 ofTivoli Manager for R/3. For other R/3 system management productsinformation, such as Global Enterprise Manager or Tivoli ApplicationPerformance Manager, please refer to the Chapter 7, “Examples of newfeatures in SAP R/3 Management” on page 271.

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 SAPGUIclients inside or outside TMR. We performed the following steps to set up ourenvironment:

• 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 forR/3, such as Tivoli Management Framework, Tivoli Enterprise Console, TivoliSoftware Distribution, and Tivoli Distributed Monitoring, refer to theappropriate product manuals or documents.

All examples in this book regarding Version 2.0 of Tivoli Manager for R/3are performed with the pre-GA version of the product. Therefore, somedetailed feature may be changed without notice. Please check with yourIBM or Tivoli representative for further information.


Note


4.2 Installation planning

As we mentioned before, there are many dependencies or prerequisites forTivoli Manager for R/3 products, and each dependent or prerequisite productalso has some prerequisites or patches that should be installed properly.Before installing Version 2.0 of Tivoli Manager for R/3, you must look intothese prerequisites including patches.

Normally, the latest patches should be applied to your TMR. To obtain thelatest patch information and download a patch, the following Web site can bea information source:

http://www.support.tivoli.com

Actually, many Tivoli patches are released, especially for Tivoli coreapplications. Some functions may not work correctly unless the proper Tivolipatch is applied. You should take care of applying these patches.

4.2.1 Installation SummaryThe following table (Table 7) shows the installation summary in ourenvironment. You can also refer to Chapter 3, “Our SAP R/3 Systemenvironment” on page 107 for more information about our systemsenvironment.

Table 7. Installation Summary

EnterpriseModule

TMRServer

TECServer

EPGW1 EPGW2 TMA1SAP3.0F

TMA2SAP4.0B

FW3.6+3.6.1+Patch

X X X X

Managed Node X X X X

Gateway X X X

Endpoint X X

Before implementing the SAP R/3 management system, the following stepsshould be done:

• Physical architecture design

• Logical design

Note


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 howto install and configure Tivoli Manager for R/3.

DM3.6+3.6.1+Patch

X X X X

DM TME/TECMonitor

X

DM UNIXMonitor

X

DM UniversalMonitor

X

DM ARMMonitor

X X X X X X

SD3.6+3.6.1+Patch

X X X X

SDGW3.6+3.6.1

X X X

TECEIF3.6+3.6.1+Patch

X

TECConsole3.6+3.6.1

X

TECACF3.6+3.6.1

X X X X X X

SIS3.6+3.6.1 X

R/3 Mgr2.0V2.0

X X X X

R/3 Appl ProxyV1.1

X X X X

EnterpriseModule

TMRServer

TECServer

EPGW1 EPGW2 TMA1SAP3.0F

TMA2SAP4.0B

Planning and implementation 121

4.3.1 Installing Tivoli Manager for R/3In Version 2.0 of Tivoli Manager for R/3 configurations, you need to install theTivoli Application Proxy before you install Version 2.0 of R/3 Manager. Weexplain Application Proxy installation first, then we explain Version 2.0 of R/3Manager installation and configurations.

4.3.1.1 Installing Tivoli Application ProxyTivoli 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 EndpointGateway if the application server runs on a TMA Endpoint.

The installation must be performed as root user. The authorization rolerequired for user root is the install_product role. The setting of theauthorization role for the root user is made via the Tivoli Desktop.

Before installing the Tivoli Manager for R/3, it is recommended to make abackup 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 byrunning the tivoli command.

• In the Tivoli Desktop main window, select Desktop from the menu bar andthe Install -> Install Product... from the pull-down menu.

• In the Install Product window, click the Select Media button to set theright 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 inFigure 49. Also select the clients on which code must be installed.Remember that clients are the TMR server, the TEC server, eachManaged Node that runs an R/3 application server, and the EndpointGateway if the application server runs on a TMA Endpoint.

The following patch is available for Tivoli Application Proxy and it iscontained 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.0of Tivoli Manager for R/3. This patch fixes many problems.

Note


Figure 49. Installing Application Proxy

• Once the settings are correct, click the Install & Close button to start theinstallation. Dependencies for this product will be checked, and thedirectories where the code will be installed are mentioned in the ProductInstall window. If the information contained in this window is correct, thenclick the Continue Install button.

• When the installation is completed successfully, a message is displayed inthe Product Install window. Do not forget to make a new backup of theTivoli database after the Tivoli Application Proxy installation.


4.3.1.2 Installing Version 2.0 of Tivoli Manager for R/3Tivoli Manager for R/3 must be installed on the TMR server, TEC server, theManaged Node that runs an R/3 application server, and the EndpointGateway if the application server runs on a TMA Endpoint.

Optionally, if the database server is not running on the same machine as anR/3 application server, install the Manager for R/3 on database server as well.

The installation must be performed as root user. The authorization rolerequired for user root is the install_product role. The setting of theauthorization 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 byrunning the tivoli command.

• In the Tivoli Desktop main window, select Desktop from the menu bar andthe Install -> Install Product... from the pull-down menu.

• In the Install Product window, click the Select Media button to set theright 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 inFigure 50. Also select the clients on which the code must be installed.Remember that clients are the TMR server, the TEC server, eachManaged Node that runs an R/3 application server, and the EndpointGateway if the application server runs on a TMA Endpoint. Optionally,install the Manager for R/3 on the database server as well if an applicationserver is not running on the same machine.

Each time you install some product, we strongly recommend you make abackup of the Tivoli database. It is the most reliable and easiest way torecover your environment even if your installation fails.

Note


Figure 50. Installing Tivoli Manager for R/3

• Once the settings are correct, click the Install & Close button to start theinstallation. Dependencies for this product will be checked, and thedirectories where the code will be installed are mentioned in the ProductInstall window. If the information contained in this window is correct, thenclick the Continue Install button.

• When the installation is completed successfully, a message is displayed inthe Product Install window. Do not forget to make a new backup of theTivoli database after the Tivoli Manager for R/3 installation.

A new policy region named Manager for R/3 is added to the administrator’sTivoli Desktop as shown in Figure 51.


Figure 51. New Manager for R3 icon on the desktop

This new policy region, Manager for R3, contains one indicator collection, onepolicy region, four profile managers, and three task libraries as shown inFigure 52. The three task libraries are grouped in R3 App Server Tasks, R3DB Server Tasks, and R3 System Tasks, and they contain tasks related totheir server or system type.


Figure 52. Policy region: Manager for R3

The policy region, R3 Configuration, contains three task libraries: R3Configuration Tasks, R3 Internal Tasks, and R3 List Maintenance Tasks. TheR3 Configuration Tasks library provides the product-wide configuration tasks(refer to Figure 53).

Figure 53. R/3 Configuration task libraries


4.3.2 Configuring Tivoli Manager for R/3After installing the code on appropriate the TMR server, TEC server, eachManaged Node that runs an R/3 application server, and the EndpointGateway if the application server runs on a TMA Endpoint, someconfiguration 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 user’s guide and the release notesof Tivoli Manager for R/3 at hand for further complementary investigation.

4.3.3 Configuring each SAP R/3 SystemSome actions have to be performed on each R/3 system in order to allowTivoli to interact and communicate with the SAP systems. These actionsshould be performed by the SAP administrators of the different systems, but


we document them here briefly in order to allow a Tivoli administrator withonly basic SAP knowledge to perform them.

The following steps must be repeated for each R/3 system that is to bemanaged.

4.3.3.1 Creating an SAP UserIn the case that you do not already have an SAP user who has the authorityto create a development class, you have to create one. The default SAP usersSAP* and DDIC do not have this authority. We recommend creating a newuser named TIVOLI (for example) who is a copy of the SAP* user. This dialoguser could be used later by the Tivoli administrator for other actions, such aschecking the import or configuring other R/3-related Tivoli products (TivoliWorkload Scheduler, for example).

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 tochange it at the first logon).

• Make sure it is a Dialog user in the Logon data folder and that it hasSAP_ALL as an authorization profile in the Profiles folder.

• Save your entries and log off.

4.3.3.2 Moving the TransportsTo 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 ABAPfile package. We introduce both ways in the following section.

Copying the Transport FilesOn the application server that will be used to execute the import, copy thedata and cofiles files from $BINDIR/../generic_unix/TME/SAP/2.2C/abap to

Typically, your R/3 Basis administrator will have IDs already set up thathave the desired authorization. We describe how to set up a user here inorder to provide the complete sequence of steps necessary to configureTivoli Manager for R/3.

Note


/usr/sap/trans/data and /usr/sap/trans/cofiles, respectively. The cofiles filescontain the configuration parameters for the transport, and the data filecontains the real data that is imported.

If the application server is on TMA, the product is not resident on the TMAapplication server machine. You cannot just copy from one directory toanother. You have to perform an ftp from another machine to the TMAapplication server machine. The transport profile manager removes the needof ftp.

Distributing the R/3 ABAP File PackageVersion 2.0 of Manager for R/3 provides a new function that distributes theR/3 ABAP file package to the appropriate R/3 application directories. It isuseful when you have a large environment containing a number of applicationservers. You can create a profile manager that contains several applicationservers with same SID, and you can distribute a file package to the profilemanager in one application. Therefore, you do not have to copy the transportfiles to each application server one by one.

The transports only need to be installed in the R/3 system. This is done fromany one application server in that SID. It is not necessary to distribute thetransports to every application server, but only one application server perSID. You could create a subscription list of all central instances and distributethe transports to this subscriber list. Also, using Software Distribution todistribute the profiles, you do not have to worry about getting the right files inthe ../data and ../cofiles directories.

Once you have installed Software Distribution at the TMR server, a profilemanager named R3 Transport is newly created under the Manager for R3policy region. Inside of the R3 Transport profile manager, you can find the R3ABAP file package (Figure 54).


.

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 profilemanager.

• First, you must change the profile manager’s mode into a dataless profilemanager if your application server is at TMA.

• From the R3 Transports Profile Manager window, select Edit -> ProfileManager... then the Edit Profile Manager window shows up.


• In the Edit Profile Manager window, check the Dataless Endpoint Modeand click Change & Close (Figure 55). When you refresh the icon, theicon changes into a dataless profile manager.

Figure 55. Change to the dataless profile

• Define the subscriber. From the R3 Transports Profile Manager’s window,select Profile Manager -> Subscriber... Then, the Subscriber’s windowshows up. Choose the appropriate Managed Node or TMA Endpoints assubscriber.

• When you finish with the selection, click the Set Subscription and Closebutton to complete.

• Edit the file package properties. Right click on the R3 ABAP FilePackageicon and select properties. The File Package Properties window showsup.

• From the File Package Properties window, choose the appropriateplatform. For UNIX, select Edit -> Platform-Specific Options -> UnixOptions... (Figure 56). Then File Package Properties shows up.


Figure 56. Edit File Package properties

• Complete the File Package Unix Options (Figure 57). The ABAP filepackage must be distributed to the /usr/sap/trans directory, and it is thedestination directory for UNIX. The default destination directory forWindows NT is \sapmnt\trans. You can change the directory asappropriate.

• Enter the appropriate user login name or user ID in the user ownership offiles on subscribers field. Also, enter the appropriate group name or groupID in the group ownership of file on subscribers field. We recommend thatyou change the user ID and group ID at this point since the source files todistribute have root and system ownership as their user ID and group IDrepetitively. However, in our destination, we need to change the sourcefile’s user ID and group ID as sidadm and sapsys, respectively. In ourcase, our UID is IG3adm, and GID is 200 (Figure 57). Click the Set andClose button to complete the setting.


Figure 57. Unix Package Unix options

• Finally, distribute the transports. In the Profile Manager: R3 Transportswindow, right-click the R3 ABAP FilePackage icon and selectDistribute... to display the Distribute File Package window.

• Complete the window with the appropriate subscriber or other setting anddistribute the file package.

You need to define tsidadm and tsid. Be sure that the files are owned bytsidadm, and tsid is the system ID of the target R/3 system. You need tocreate different file packages if you are going to distribute to different R/3systems.

4.3.3.3 Importing the Function ModulesFirst check if the transport system is already configured and functioning. Goto the /use/sap/trans/bin directory and verify the existence and content of theTPPARAM file there (configuration file for transports). If the file is missing, thetransport 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 toTPPARAM, and adapt the content.

• Verify that there are no other imports waiting in the transport buffer byentering tp showbuffer <SID>, with the SID corresponding to your R/3system.


• 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.

• Verify that it is now in the buffer by entering tp showbuffer <SID>.

wwdn07:ig3adm 6> tp showbuffer IG3This is tp version 252.08.05 (release 40B) for DB2commonserver database

IG3 buffer:

BD1K900989|has already been imported completelyBD1K901024|has already been imported completelyBD1K900770|has already been imported completelyPD9K900680|has already been imported completelyBD1K901036|has already been imported 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 completelyAD1K900218|has already been imported completelyBD1K901366| | | 1 | | | | 4 | 1 | | |PD9K900714|has already been imported completelyPD9K900716|has already been imported completelySAPK001LDE|has already been imported completelyTV1K900057|has already been imported completelyTV1K900095|has already been imported completelyTV1K900096|has already been imported completelyIG3K900105|has already been imported completely

that makes 2 transports to be imported.

tp finished with return code: 0meaning:Everything OK

wwdn07:ig3adm 7> tp addtobuffer TV1K900187 IG3This is tp version 252.08.05 (release 40B) for DB2commonserver databaseAddtobuffer successful for TV1K900187tp finished with return code: 0meaning:Everything OK

In our example, we specified the transport number 187. However, pleaserefer to the latest Release Notes for the transport numbers.

Note


• Import the function modules by entering tp import TV1K900187 IG3. If youneed to put in the unconditional mode, the u4 option is only specified forthe R/3 release prior to 4.0A, and for 4.0B, only u1 and u2 are used.

If needed, you can also check the import log files in the directory/usr/sap/trans/log.

wwdn07:ig3adm 8> tp showbuffer IG3This is tp version 252.08.05 (release 40B) for DB2commonserver database

IG3 buffer:

BD1K900989|has already been imported completelyBD1K901024|has already been imported completelyBD1K900770|has already been imported completelyPD9K900680|has already been imported completelyBD1K901036|has already been imported 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 completelyAD1K900218|has already been imported completelyBD1K901366| | | 1 | | | | 4 | 1 | | |PD9K900714|has already been imported completelyPD9K900716|has already been imported completelySAPK001LDE|has already been imported completelyTV1K900057|has already been imported completelyTV1K900095|has already been imported completelyTV1K900096|has already been imported completelyIG3K900105|has already been imported completelyTV1K900187| 4 | 4 | 1 | | | | 10 | | 8 | |

that makes 3 transports to be imported.

tp finished with return code: 0meaning:Everything OK

wwdn07:ig3adm 9> tp import TV1K900187 IG3This is tp version 252.08.05 (release 40B) for DB2commonserver databaseThis is R3trans version 6.03 (release 40B - 08.05.98 - 13:03:12).R3trans finished (0004).sapparam(1c): No Profile used.sapparam(1c): No Profile used.This is R3trans version 6.03 (release 40B - 08.05.98 - 13:03:12).R3trans finished (0004).sapparam(1c): No Profile used.sapparam(1c): No Profile used.tp finished with return code: 4meaning:A tool used by tp produced warnings

wwdn07:ig3adm 10>

In our example, we specified the transport number 187. However, pleaserefer to the latest Release Notes for the transport numbers.

Note


After importing, you can also check the SAP system for the developmentclass being created, and also all objects should be activated. Use transactionse80 and display the development class J8C1, as shown in Figure 58 on page137.

Figure 58. Checking the development class J8C1

You can open each sub-tree by double-clicking it to check that their statusshould be saved and activated. For example, we opened the J_8C1_TIV1structure as shown in Figure 59 on page 138.


Figure 59. Checking active table structure

4.3.3.4 Creating a RFC UserWe have chosen to create a new user for the RFC interface access in order tohave 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 apassword.

• In the Profiles folder, add the S_A.ADMIN authorization profile.

• Save your entries and log off.


As you can see in Figure 60, we created a new User ID named TME10 andhave given the CPIC User type.

Figure 60. User list at SAPGUI

4.3.3.5 Configuring an R/3 System for AlertsR/3 alerts are transmitted to the Tivoli Manager for R/3 via the R/3 SysManinterface. These alerts are accessed by the SysMan from the R/3 sharedmemory 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 tobe accessible through the SysMan. This is the default allocation for R/3. Youcan check the allocation of segment key 13 by examining the R/3 applicationserver instance profile. The instance profile can be displayed and maintainedvia transaction rz10. The parameter ipc/shm_psize_13 controls the poolallocation for segment key 13. This parameter must have a value of -10 toensure that it is allocated to shared memory pool 10. This is shown in Figure61.

New users are normally required to change their password on the firstlogin. Therefore, if you make the user a CPIC user, you will never have thechance to modify the password. As an alternative to the proceduredescribed previously, you can make the user a dialog user first and thenchange the properties to CPIC once you have validated the permissionsand changed the password.

Note


Figure 61. Display R/3 instance profile

4.3.4 Configuring the Tivoli Manager for R/3 to the R/3 SystemWe need to create Tivoli objects for the R/3 system, application server, anddatabase server so that we can manage them though the Manager for R/3. Tocreate the R/3 objects, two different ways are provided: a manual methodfrom the Tivoli Desktop, or using the automatic discovery function.

We also introduce configuring roles and RFC in this section.

4.3.4.1 Configuring RolesOnce you have finished with your installation of R/3 Manager, three newresource roles are created: r3_user, r3_admin, and r3_senior (Figure 62).


Figure 62. Assigning the new TMR roles

Assign these new roles to your main Tivoli administrator as TMR roles andthen continue working with this administrator instead of using a new one.Make sure to restart the Tivoli Desktop after assigning the new roles to makethe change effective.

4.3.4.2 Creating R/3 SystemTo create an R/3 system object, follow these steps:

• In the Manager for R3 policy region window, select Create from the menubar and R3System... from the pull-down menu.

• In the Create R3 System window (Figure 63), enter the SID of the R/3system in the R/3 System Name (SID) field and select the R/3 release.

• Select the R/3 Database type and enter the R/3 Database hostname theR/3 database server is running. Enter the R/3 Database release asoptional.

• Click the Set and Execute button. This task creates a subregion for theR/3 system in the Manager for R/3 policy region.

In Version 1.5 of Tivoli Manager for R/3 configuration, the R/3 Release fieldrefers to the level of the SAPGUI that you want distributed by the TivoliManager for R/3. However, in Version 2.0 of Tivoli Manager for R/3configuration, the R/3 Release field refers to the actual release level of theR/3 system being managed.

Note


Figure 63. Create R/3 system from desktop

4.3.4.3 Creating R/3 Application ServerTo create an R/3 application server object, follow these steps:

• In the Manager for R/3 policy region window, double-click the appropriateR/3 system icon to open the selected R/3 system’s policy region.

• In the R/3 system’s Policy Region window, select Create from the menubar and R3AppServer from the pull-down menu.

• In the Create R3 application server window (Figure 64), enter the two digitR/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 theManaged Node name in the Managed Node Name field. If your applicationserver is running on a TMA Endpoint, enter the TMA Endpoint name in theTMA Endpoint Name field.

• Click the Set and Execute button. This task creates a subregion for theR/3 application server in the R/3 system policy region.


Figure 64. Create R/3 application server from desktop

4.3.4.4 Creating R/3 Database ServerTo create an R/3 database server object, follow these steps:

• In the Manager for R/3 policy region window, double-click the appropriateR/3 system icon to open the selected R/3 system’s policy region.

• In the R/3 system’s Policy Region window, select Create from the menubar and R3DBServer from the pull-down menu.

• In the Create R3 database server window (Figure 65), if your databaseserver is running on a Managed Node, enter the Managed Node name inthe Managed Node Name field. If your database server is running on aTMA Endpoint, enter the TMA Endpoint name in the TMA Endpoint Namefield.

• Click the Set and Execute button. This task creates a subregion for theR/3 database server in the R/3 system policy region.


Figure 65. Create R/3 database server from desktop

4.3.4.5 Creating R/3 object with Automatic DiscoveryAs 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 anR3AppServer object along with an R3System object. If database server isrunning on the same machine where application server is running, AutomaticDiscovery also creates the R3DBServer object.

The creation of the R/3 system, application server, and the database servercan be done by Automatic Discovery all at once. Therefore, you can eithercreate each R/3 object manually or use Automatic Discovery.

To use the Automatic Discovery function, run the Configure Autodiscoverytasks that are predefined in the R3 Configuration Tasks task library. The tasksare provided as platform-specific; therefore, you choose the appropriate tasksdepending on your platform type. In the following, we configure the UNIXcase.

• In the Manager for R3 policy region, double-click the R3 Configurationpolicy 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 theDisplay on Desktop check box.


• In the Available Task Endpoints list, select the Managed Nodes that areapplication servers of the R/3 system and move them to the Selected TaskEndpoints list.

• Click the Execute & Dismiss button.

• In the resulting window (Figure 66), enter the appropriate schedule in thefields. If you want to run Automatic Discovery immediately, leave all fieldsblank.

Figure 66. Configure Autodiscovery for UNIX

4.3.4.6 Configuring the RFCThe Tivoli Manager for R/3 users RFC to log on to each R/3 managed systemin order to run some tasks and monitors. For this access, it uses thepreviously defined RFC user. This user is defined here to the Tivoli Managerfor R/3 though the following task. The corresponding script is located on theTMR server, and it is named sap_config_rfc.sh.

If you run Automatic Discovery, you always must distribute the R3 ServerAutodiscovery Monitor profile manually.

Note


Figure 67. Task Library: R3 Configuration tasks

To configure RFC for each R/3 system, run the Configure Remote FunctionCall 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 theRFC user ID, enter the RFC user name (for example, TME10), itspassword, and the language used (Figure 68).


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


We recommend that you test that the RFC is correctly configured. This can bedone 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 wr3rfcprogram in the $LCF_BINDIR/../TME/SAP/2.2c directory if it is on the TMAEndpoint.

• For each Managed Node running an application server, and on eachEndpoint Gateway that manages a TMA Endpoint that runs an R/3application 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 thecalled function modules previously imported in the R/3 system.

The result of this command execution (in this case, from the TMR server) isshown in the following output.


4.3.4.7 Configuring the environmentIf your database is running on Windows NT, and if you plan to use thestart/stop database facility of the Tivoli Manager for R/3, you must create two

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 00J_8C1_BUFFER_NAMES.TXTInitializing 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 = BUFFERNAMESNAME = BUFFERNAMETYPE = TYPCLENGTH = 5FILE = stdoutOverriding cfg and cmd file options with command line options.

user = tme10client = 100language = Edestination = IG3hostname = wwdn07.pok.ibm.comsysnr = 00

Mallocing space required for import parameters.Preparing to open connection to SAP.

RFC OPTIONS:destination = IG3connopt = 2003e970client = 100user = tme10language = Etrace = 0

mode = RFC_MODE_R3ONLYconnopt_r3only address = 2003e970hostname = wwdn07.pok.ibm.comsysnr = 0Opening a connection to SAP.Connection successfully opened.

Calling the SAP Module J_8C1_BUFFER_NAMES with the following parameters.Exporting:

Importing:RFC Call completed.Listening for RFC Call to completeGetting the response from SAP.TTABFTABSNTABIRBDTABLTABLPPXACUAPRESCALEwr3rfc complete!


scripts containing the specific database commands that will start and stop thedatabase. These two scripts, named sap_start_db.exit.sh andsap_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 andthe %LCF_BINDIR%\..\generic_unix\TME\SAP directory if it is a TMAEndpoint. When called though the start/stop task, two parameters will beprovided to them. The first one is the database type, and the second one isthe SID. The scripts must return an exit code of zero for a successfulcompletion and a non-zero exit code for an unsuccessful completion.

Example of a Start Exit Routine for an Oracle DatabaseThe following is an example of a start exit routine for an Oracle database.

Example of a Stop Exit Routine for an Oracle DatabaseThe following is an example of a stop exit routine for an Oracle database.

Figure 70 shows the main created objects on the Tivoli Desktop after all theseTivoli Manager for R3 configuration steps.

#!/bin/shecho 'Starting Service'E:/orant/Bin/oradim80.exe -STARTUP -SID $2 -STARTTYPE srvcecho 'Sleeping'sleep 10echo 'Starting Instance'E:/orant/Bin/oradim80 -STARTUP -SID $2 -STARTTYPE inst -USRPWD \-PFILE E:\\orant\\Database\\init"$2".oraexit 0

#!/bin/shecho 'Stopping Instance'E:/orant/Bin/oradim80.exe -SHUTDOWN -SID $2 -USRPWD -SHUTTYPE \inst -SHUTMODE n &echo 'Sleeping'sleep 10echo 'Stopping Service'E:/orant/Bin/oradim80.exe -SHUTDOWN -SID $2 -SHUTTYPE srvcexit 0


Figure 70. Tivoli Manager for R3 configuration

4.3.5 Configuring event handlingThe Manager for R/3 provides new event classes and rule sets so that youcan view and work with R/3 events at your Tivoli Enterprise Console (TEC). Inorder to do so, you must configure the TEC event server, the TEC eventconsole, and the TEC event adapters. We explain these configurations in thefollowing section.

Manager for R3

In Figure 70, there are two Sentry profiles under the R/3 application server(wwdn07_IG3_00). These profiles are not there automatically. They onlyshow up after you distribute them.

Note


4.3.5.1 Configuring TECTivoli Manager for R/3 will monitor the R/3 systems through event adaptersrunning on each application server and a set of Tivoli Distributed Monitoringmonitors distributed to each application and database server (remotemonitors) and to the TMR server (central monitors). The TEC server willreceive events directly from the adapters and from the Tivoli DistributedMonitoring engines. In order to handle them, new events classes and rulesmust be imported into TEC. The following job will import them, thus, creatinga new rule base or extending an already existing one. The scriptcorresponding to the job that will be used here is located on the TMR server,and it is named sap_eventserver_config.sh.

To configure the event server, run the Configure Event Server job in the R3Configuration Tasks task library (Figure 71) and follow these steps:


• Double-click the Configure Event Server job.

The Configure Event Server for R/3 task updates your existing rule base ifyou specify no rule base to clone or creates a new rule base from anexisting rule base.

Note


Figure 71. Task Library: R3 configuration tasks (for Event Server)

• In the resulting window (Figure 72), enter the name of the new rule baseyou want to create or the name of the already existing one that you want tomodify (in the second case, enter the name of the rule base you want toclone and the path to its directory; in the first case, erase these entries).


Figure 72. Configure Event server

• For rule base name, you can enter the new one or existing one. If you wantto create a new rule base, enter the name, rule base to clone, and the pathfor the new rule base. If you do not create a new rule base, enter theexisting rule base name and leave the other two fields (rule base to cloneand path for new rule base) blank.

• If you want the TEC server to forward events directly to another TECserver, enter the name of this other event server in the Managed NodeName to forward Events field.


• Verify the task status window that you received no errors.

In our case, since we have not created a new rule base before, we use thedefault 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 someSAP R/3 specific rules into it and create a new rule base name called SAPand place it in the /usr/tec_rules/SAP directory. If you have not created arule base previously, use Default as the rule base to clone.

Note


4.3.5.2 Configuring an Event ConsoleAn event group or an event source consists of a filter on all events containedin the TEC database. This step creates an event group for each R/3 systemthat is to be managed in order to see the events per SAP system. It alsocreates an event source for adapter events (WR3MIB or WR3SLOG checkedin the dialog box). The script corresponding to the job that will be used here islocated 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 eachR/3 system.

The following steps must be repeated for each R/3 system that is to bemanaged.

Figure 73. Task Library: R3 Configuration tasks (for Event Console)

To configure the event console, run the Configure Event Console job in theR3 Configuration task library (Figure 73) and follow these steps:

• Open the R3 Configure Tasks task library.

• Double-click the Configure Event Console job.


• In the resulting window (Figure 74), enter the name of event group that youwant to create in the group name field. Select the Name of EventConsole that you want to configure. In the sources field, select at leastone source that you want to receive the events. In the group filter for R/3systems 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).


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_SAPis created in the Enterprise Console Event Groups window.


Figure 76. TME 10 Event server configuration (Event Group)

Also, as shown in Figure 77, you can find two R/3 specific event sourcescalled WR3MIB and WR3SLOG. To view the events generated from the alertevent adapter, open the WR3MIB event source icon. To view the eventsgenerated from the syslog adapter, open the WR3SLOG event source icon.


Figure 77. Tivoli Enterprise Console (for Event Source)

4.3.5.3 Configuring Event AdapterWe need to configure the alert event adapter and the syslog event adapter foreach application server. After configuration, each application server canprocess R/3 information and generate it into the TEC events. The scriptcorresponding to the task that will be used here is located on the TMR server,and it is called sap_config_adapter.sh.


Figure 78. Task Library: R3 Configuration Tasks (for Event Adapter)

To configure the event adapter, run the Configure Event Adapter task in theR3 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 theDisplay on Desktop check box.

• In the Available Task Endpoints list, select the Managed Nodes that areapplication servers of the R/3 system and move them to the Selected TaskEndpoint list.

• Click the Execute & Dismiss button.

• In the resulting window (Figure 79), select either Alert Adapter or SyslogAdapter for the adapter type. You can choose one of them at a time, butyou need to configure both so that you get events from both adapters.

• Enter the Hostname of the Event server.



Figure 79. Configure Event Adapter

• Verify in the task status window that you received no errors (refer to Figure80).


Figure 80. WR3MIB and WR3SLOG Event on TEC console

In most cases, you must manually start the Event Adapter using the StartEvent Adapter task. The exception is that the first time distribution of anEvent Adapter to Windows NT is started automatically. You must manuallyrestart Event Adapter on UNIX systems after a reboot. They areautomatically restarted after a reboot on Windows NT.

Note


Chapter 5. Managing SAP R/3 environment

In this chapter, we describe in detail how to use the managementenvironment for SAP R/3 that we have set up in the Chapter 4, “Planning andimplementation” on page 119. We also explain and provide backgroundinformation on how the management products communicate with the SAP R/3system and how to use the information provided by CCMS.

For R/3 system management products information, such as Global EnterpriseManager or Tivoli Application Performance Manager, please refer to theChapter 7, “Examples of new features in SAP R/3 Management” on page 271.

5.1 Version 2.0 of Tivoli Manager for R/3

In this section, we explore the different management functions provided byVersion 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 jobsIn this section, we explain how to control the R/3 environment using Tivolitasks, for example, how to take actions on your R/3 system, such as startingand stopping the system, application servers, database servers, clients, andmonitors, and how to show some performance information of the applicationserver.

To control your R/3 environment using Tivoli tasks, start by opening theManager for R3 policy region from the Tivoli Desktop, which brings you to the

All examples in this redbook regarding Version 2.0 of Tivoli Manager forR/3 are performed with the pre-GA version of the product. Therefore, somedetailed features may be changed without notice. Please check with yourIBM or Tivoli representative for further information.


Note


system-level view (you can see all defined R/3 systems here besides the R3Configuration policy region). Here, you will see three task libraries: R3 AppServer Tasks, R3 DB Server Tasks, and R3 System Tasks. Open R3 AppServer Tasks, and you will see 14 predefined tasks in this window as shown inFigure 81.

These tasks let you handle your R/3 application servers, varying from the taskof starting/stopping the server or starting/stopping the event adapter to tasksthat display some information, such as roll area, page area, operating system(OS) collector, batch job, and work process. For the work process and batchjobs, there is a task to cancel them, and for batch jobs, there is even a taskavailable 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 BatchJobs), and you will get an Execute Task window as shown in Figure 82.


Figure 82. Display Batch Jobs Execute Task Window

Choose an application server as the Task Endpoint to run this task. Aftercompleting, 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 requiresarguments, a window is displayed, and after you provide the requiredinformation, click Set & Execute. The output of this task is shown in Figure84.


Figure 84. Display Batch Jobs Output Window

To control your R/3 database servers using Tivoli tasks, open the Managerfor R3 policy region from the Tivoli Desktop and then open task library: R3DB Server Tasks. You will see a window as shown in Figure 85. If youexecute the task Start/Stop Database, you will get a pop-up window as aconfirmation before stopping the database server. When stopping a UNIXdatabase server, the stop processing also stops all application servers onthat server, thus, having the same SID. But stopping/starting a databaseserver running on Windows NT requires customer exit routines as describedin 4.3.4.7, “Configuring the environment” on page 149.

Besides tasks for stopping and starting your database server, there is also atask to start dbaccess on the specified database server. The status of thestart dbaccess job will be displayed in the Start dbaccess Output window, andthe dbaccess xterm window will also be displayed. You can use structuredquery language (SQL) commands to access your R/3 database. Press Ctrl-W


for help. Note that this function is now only supported with a Motif windowsmanager and an Informix database.

There is also a task library: R3 System Tasks available that has two tasks onit, Stopping and Starting R/3 System. You can run one of these tasks againsta selected Task Endpoint, which could be one of your R/3 Systems, to start orstop the whole R/3 system.

Figure 85. Task Library: R3 DB Server Tasks Collection

5.1.2 SAPGUI distributionIn this section, we are going to use the second functionality of Tivoli Managerfor R/3, which is automatic deployment of R/3 SAPGUI clients. In order tocomplete the configuration of our environment, we deploy SAPGUI to one ofour workstations in an environment. An R/3 client is a UNIX, Windows 95,Windows 98 or Windows NT machine running the SAP R/3 presentationgraphical user interface (SAPGUI) code. Once this code is installed on thetarget machine, a configuration is needed to define a specific SAPGUI for aspecific R/3 application server. This configuration is a part of the SAP R/3installation, 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 SAPGUIcode and which will be distributed to all the clients. The second phase is theprocess of distributing this file package, launched by using Tivoli SoftwareDistribution. To configure such a file package, two methods are available. Theconfiguration can be done using either a reference installation or an R/3native installation. You can create various file packages with different optionsand configurations. Each file package is identified by the name you specify


when you create the file package. This section also describes how todistribute the client software file packages. The distribution of the file packageis done via Tivoli Software Distribution, whatever the configuration methodused.

5.1.2.1 Configuring a R/3 Client using a Reference InstallationThis method proposes that you first install and configure a SAPGUI locally ona node, using the R/3 CD-ROM, to create a reference client machine for thedistribution of the code to other future clients. We performed this installationon a Windows NT running as a Managed Node.

Once the local installation is completed, you have to transfer the R/3 clientdirectories and files from the PC client to the TMR server to a specificdirectory. For example, we have created a directory named /Ref/NT/ on ourAIX TMR server as a repository for the R/3 client code for Windows NT. Thistransfer can be made using ftp. Using this method for the transfer can beapplied either between a UNIX TMR server and a Windows PC TMA orManaged Node, or between a Windows NT TMR server and a UNIX TMA orManaged Node. If your TMR server and your future SAPGUI clients arerunning on the same platform, you have to install the SAPGUI on the TMRserver instead of using ftp to transfer the code.

After creating the SAPGUI’s code repository, you can now configure the taskthat will put the code into a Tivoli Software Distribution file package ready tobe distributed to other machines. Use the following procedure to create theclient software file packages for distribution of SAPGUI:

• From the Tivoli Desktop, open the Manager for R3 policy region to displaythe Policy Region: Manager for R3 window.

• Open the R3 Configuration policy region to display the Policy Region: R3Configuration window.

• Open the R3 Configuration Tasks task library to display the configurationtasks.

• Edit the appropriate job for a reference installation by right-clicking on thejob icon. The job’s name is: Configure Client Install.

The configuration tasks to build the file package create profile managersand profiles as a result of their processing. For these actions to succeed,the administrator running these tasks must also have Tivoli super role.

Note


Figure 86. Edit Job for a Reference Installation

By default, the name of the task executed by the job is highlighted in the TaskName scrolling menu: Configure Client Install. The other default settings arecorrect, except for the Output Format. We recommend you also check theReturn 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, clickon the Change & Close button.

Then double-click on the job icon. A dialog box is displayed that allows you toset some parameters to perform the execution as shown in Figure 87.


Figure 87. Settings for the Job’s execution

The Configuration Name you will specify will be an identifier of the currentconfiguration. It will be, for example, the name of the profile manager createdby the job’s execution. The Source Information field must be filled with thepath where the client code is stored. For us, this is /Ref/NT/, on the TMRserver, as explained before. In the Destination Information section, you haveto specify the platform your target clients have, the directory where todistribute the code (we recommend also that you install the code in an SAPpcdirectory), and the required disk space (20 MB is the recommended size).Some information about the R/3 server for which the clients will be configuredis required. This information contains the Primary Application Server nameand the Instance Number. Then, click on Set & Execute to run the job. Aformatted 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 createsa Tivoli Software Distribution file package. In our example, this file packagecontains the SAPGUI code for a Windows NT R/3 client. This file package isincluded in a profile, itself added in a profile manager as shown in Figure 88on page 172. Both are created during the job’s execution.The name of theprofile manager is the one you associated with the file package when you runthe configuration task.


Figure 88. Result of the Job Execution

You can edit the Tivoli Software Distribution profile to see the content of thefile package by double-clicking on it (see Figure 89).

Verify that the package contains the R/3 client code for Windows NT, locatedin the /Ref/NT directory on the node pokibmxtmrb20, which is the TMRserver.

Distributing this file package to the target machine will create on it anSAPGUI icon in the Start Menu to access the R/3 system specified during theconfiguration of the job.


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 InstallationThis method assumes that the R/3 SAPGUI CD-ROM image is available onthe target machine. This image can be the CD-ROM itself, inserted in a targetmachine, 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 usingR/3 install tools and procedures.

Compared to the reference installation method, the R/3 native installationmethod avoids copying the SAPGUI code to the TMR server. The secondadvantage of such a method is the fully automatic icon customizing for theSAPGUI on the target machines. First of all, be sure that the SAPGUICD-ROM image is available on the target machines. Then, you have toconfigure the task that will extract the code from the image and put it into aTivoli Software Distribution file package, ready to be distributed to othermachines, whatever the platform of the targets is because the Tivoli Manager


for R/3 provides tasks for UNIX, Windows NT, and Windows 9x clients. Toconfigure the task, use the following steps:

• From the Tivoli desktop, open the Manager for R3 policy region to displaythe policy region: Manager for R3 window.

• Open the R3 Configuration policy region to display the policy region: R3Configuration window.

• Open the R3 Configuration Tasks task library to display the configurationtasks.

• Then, edit the appropriate job for a native installation by right-clicking onthe job icon. The job’s name is: Configure Windows NT Client Install.

Figure 90. Edit Job for a Native Installation


By default, the name of the task executed by the job is highlighted in the TaskName scrolling menu: Configure Windows NT Client Install. The other defaultsettings are correct except for the Output Format. We recommend you alsocheck the Return Code. Also check that the TMR server is selected as taskendpoint because the task must be executed on it. Once all settings arecorrect, click on the Change & Close button.

Then double-click on the job icon. A dialog box is displayed that allows you toset 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 currentconfiguration. It will be, for example, the name of the profile manager createdby the job’s execution. The Source Information fields must be filled in asexplained below. We give the settings only for mandatory fields. For theoptional fields, refer to the R/3 manuals (or the R/3 online help CD-ROM) forinformation.

• SAPGUI version: Indicates the level of SAPGUI being installed on thetarget. For us, we have selected the 4.0B version.


• Language: Enter the language you want to use chosen from theR/3supported languages list.

• Destination Information: Fill in the fields for the destination directory on thetarget machine where the code is going to be copied (we recommend thatyou install it into a SAPpc directory). This is the source directory where theimage is stored. It is either the CD-ROM drive itself, or a mount point if theCD-ROM is shared with other target machines. In both cases, the sourcepath must end with WINDOWS, for example, E:\GUI\WINDOWS. Do notspecify the subdirectory WIN32, for instance, because only a part of thecode will be installed. The third attribute you have to set in this section isthe path where the documentation will be copied.

• R/3 Server Information: Enter the hostname of the server name and itsInstance Number.

• Installation Options (Optional): This is for entering direct commands.These fields are useful for network mounting of the SAPGUI CD-ROM (forexample: net use, sleep, and so on).

• 4.0B Components: By default, the 32-bit option is set. For the otherparameters, 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 "TaskComplete!" in the standard output section. Then select Close. The job hasexecuted a task running a script that creates a Tivoli Software Distribution filepackage. This file package contains a set of R/3 installation tools andcommands to install the SAPGUI for Windows NT on the Windows NT targetsfrom the SAPGUI CD-ROM image. This set of R/3 tools and commands hasbeen 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, asshown in Figure 92. Both have been created during the job’s execution. Thename of the profile manager is the one you associated with the file packagewhen you ran the configuration task.


Figure 92. Result of the Job Execution

You can edit the Tivoli Software Distribution profile to see the content of thefile package by double-clicking on it (refer to Figure 93).

Verify that the package contains the set of R/3 tools and commands to installthe SAPGUI code on the Windows NT target. You can also see that this set islocated 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 anSAPGUI icon in the Start Menu to access the R/3 system specified during theconfiguration of the job.


Figure 93. Edit the Profile: Configuring the R/3 SAPGUI Client Native Installation

5.1.2.3 Distributing Client SoftwareThe file package created during the reference installation and the R/3 nativeinstallation of the R/3 SAPGUI clients, as described in the former sections,must be distributed to the target machines. Target machines must be definedas subscribers of the appropriate profile managers according to the type ofinstallation (reference installation or R/3 native installation) and the platformof the clients (UNIX, Windows NT, or Windows 95). For clients defined asManaged Nodes or PC Managed Nodes, you have to subscribe them to theprofile managers and then distribute the profile to these new subscribers. Weassume that the reader is familiar with Tivoli Software Distribution. Fordetailed information about Tivoli Software Distribution, refer to the redbooksNew Features in Tivoli Software Distribution 3.6, SG24-2045 and TME 10Deployment Cookbook: Courier and Friends, SG24-4976.

For clients defined as TMAs (Tivoli Management Agents), you need tochange the profile manager to a dataless profile manager. To do this, edit the


profile manager you wish to use and check the Dataless Endpoint Mode asshown in Figure 94.

Figure 94. Change to Dataless Profile Manager

Indeed, the client install and configuration job’s execution creates, by default,a standard profile manager. Only Managed Nodes and PC Managed Nodescan be subscribed to such a profile manager, but TMAs cannot be subscribedto it as they are dataless endpoints. A TMA can only be subscribed to adataless profile manager and not to a standard profile manager.

In case you need to distribute the file package profile for both the TMA andManaged Node, you can perform some customization that will be describedhereafter. The first step is to create a new profile manager with the datalessendpoint mode option. You must give it a different name from the one of thestandard profile manager, because Tivoli does not support two objects withthe same name. Then, from the default standard profile manager, clone theprofile to the new dataless profile manager. To do this, go into the standardprofile manager and select the profile. Then, in the profile manager window,select Edit from the menu bar and Profiles->Clone... from the pull-downmenu. In the window that appears, you will be asked to change the name ofthe cloned profile because of the Tivoli rule described above. Also select thedataless profile manager you have created as the target for the cloned profileand click the Clone & Close button. This window is shown in Figure 95.


Figure 95. Cloning Profile into Dataless Profile Manager

Now, you can subscribe your TMA to the dataless profile manager. Note thata dataless profile manager can have TMAs, Managed Nodes, or PC ManagedNodes as subscribers, but not a subscription list. So, you may not delete thestandard profile manager, because you may need to subscribe a subscriptionlist.

In our example, shown in Figure 96, we will use the originally created filepackage during the configuration because we will distribute it to a WindowsNT Managed Node. Then select the Windows NT node as a subscriber to thisprofile manager. Now, the file package can be distributed to the ManagedNode. To do so, select the file package from the Profiles section and theManaged Node from the Subscribers section. Then, from the menu bar,select Profile Manager and Distribute... from the pull-down menu. A windowwill appear to confirm the distribution. Click on the Distribute & Close button.


Figure 96. Distributing the SAPGUI Client File Package

For both methods, a reference installation or an R/3 native installation isused. Once the distribution is completed, the R/3 SAPGUI code is installed onthe client machine, and the SAPGUI icon for the appropriate R/3 system hasautomatically been created during the installation because the installationwas performed directly from the CD-ROM image. So, as the sapsetupprogram was automatically run with the right parameters, the Start menu ofthe PC client has been updated to provide direct access to the R/3 serverindicated during the job’s configuration. An example can be seen of thedesktop of a Windows NT SAPGUI client in Figure 97. From this menu, youcan create other SAPGUI icons for accessing other R/3 servers by clicking onthe SAPicon menu.


Figure 97. Example of SAPGUI Access on a Windows NT Client


5.2 Log files for troubleshooting

The following table (Table 8) shows the log files that are useful for problemdetermination and troubleshooting.

Table 8. Log Files for Troubleshooting

Type Name Location

Tasks name.log: Where namerepresents a file name thatincludes the name of the taskproducing the output.Example:wwdn07_IG3_sap_display_buffer_info_.log

UNIX: /tmpWindows NT Managed Node:$DBDIR/tmpWindows NT Endpoint:$LCF_DATDIR/tmp

Monitors name.log: Where namerepresents a file name thatincludes the name of the monitor.Monitor trace must be on.Example:wwdn07_IG3_sapsystem_monitor_.log

UNIX: /tmpWindows NT Managed Node:$DBDIR/tmpWindows NT Endpoint:$LCF_DATDIR/tmp

EventAdapters

adapter_name.log: Whereadapter_name is r3mibIID for thealert event adapter or r3slogIIDfor the syslog adapter.

UNIX: /tmpWindows NT:%SYSTEMROOT%\temp, where%SYSTEMROOT% is the drivewhere Windows NT is installed,usually the C: drive.If the \temp directory is not found,the event adapter log files arewritten in one of the followingdirectories:Managed Node:$BINDIR/TME/SAP/2.2CEndpoint:$LCF_BINDIR/../TME/SAP/2.2C

SAPGUI FilePackageDistribution

profile.log: Where profile is thename of the file package profile.

Managed Node:$BINDIR/../generic_unix/TME/SAP/fp/profilemgr, whereprofilemgr is the name of theprofile manager.


5.3 Monitoring functions of Tivoli Manager for R/3

The R/3 system has a general monitoring tool called Computer CenterManagement System (CCMS). It contains a set of alert monitors that monitorcritical elements of the R/3 system and notify administrators of potentialproblems. Starting with R/3 version 4, the CCMS offers a Multi-Systems andOver-the-Landscape monitoring possibility, which is, of course, a big leapcompared to single application server monitoring prior to that version. Anillustration of this new CCMS function, transaction RZ20, is shown in Figure98. You must click on each tree-leaf you want to see until you reach thebottom leaf, which then has the threshold value. But you must havecustomized this set of alerts first to get this tree-overview with all itsinformation. This kind of configuration must be done step by step for eachalert, for each threshold value, and for each host you want to include in yourmonitoring set. A help window is available to explain all the icons that youmight get as shown in Figure 99.

Figure 98. CCMS Alert Overview (Customized) - Transaction RZ20


Figure 99. Explanation for the Alerts and Icons

Alerts provided by CCMS are also shared with the external world by using aninterface, the SAP shared memory segment. Every SAP R/3 applicationserver does have a shared memory segment. It is called SAP ManagementInformation Base (MIB), or R/3 System Management (SysMan), whichcomprises all alert information from this application server. This alertinformation is monitored by the wr3mib program and a TEC event adapter,which translates the SysMan alerts to TEC events. More information on thealert 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, thesyslog event adapter, which processes the R/3 syslog and converts newentries into TEC events. Because this is also a TEC event adapter, thestandard Tivoli-provided filtering capabilities can be applied to these events.More information on the syslog event adapter will be given in 5.3.3, “SyslogAdapter” on page 189.

Another possibility for monitoring R/3 systems is using Tivoli DistributedMonitoring and the Remote Function Call. This Tivoli core applicationprovides synchronous monitoring functionality. Details on getting information


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 AdapterThe Tivoli Manager for R/3 provides an alert event adapter for eachapplication server. The alert event adapter polls or queries periodically theR/3 SysMan or MIB interface for new alert entries and forwards formattedevents to TEC. This is done by the r3mibIID program, where IID representsthe two-digit R/3 instance number. You can find a running process calledr3mibIID on each application server. The alert event adapter can generatemany events as listed in Appendix B, “Event classes for Tivoli Manager forR/3” on page 347. To minimize the number of events that are sent to TEC, youcan filter these events at the alert event adapter. To do this, add filterstatements to the r3mibIID.conf file. This file is created after you run theConfigure Event Adapter task and, therefore, exists only after you have runthis task at least once for the specific R/3 application server. Ther3mibIID.conf file is located in one of the following directories:

Managed Node $BINDIR/TME/SAP/2.2C

TMA Endpoint $LCF_BINDIR/../TME/SAP/2.2C

All R/3-related alert events received by the TEC server can be classified intotwo categories: Specific events and Generic events. Specific events containall pertinent information on the event and are forwarded directly to the TECevent consoles. On the other hand, generic events only give high-levelinformation as an indication of a problem. For these events, the Manager forR/3 will perform drill-down processing to gather more detailed informationabout the R/3 system through the RFC interface. In doing this, the originalevent will be discarded.

5.3.1.1 Drill-Down ProcessAfter reception, the TEC server dispatches the events to its rules engine. Therules specific for R/3 have been previously imported and loaded into the TECserver during the event server configuration. One of these rules will betriggered by generic events, which come from the R/3 alert event classes (seeAppendix B, “Event classes for Tivoli Manager for R/3” on page 347). It willinvoke a drill-down process and then drop the events. Figure 100 on page 187illustrates the TEC event processing. The drill-down process begins with theTEC 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 launchesa task with the application server as the task endpoint. The correspondingscript that is run on the remote application server is calledsap_alert_reader.sh and is located in


$BINDIR/../generic_unix/TME/SAP/2.2C/sh or, in case the application serveris running on a TMA, in $LCF_BINDIR/../../generic_unix/TME/SAP/2.2C/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/3application server and runs the J_8C1_ALERT_READER function moduleimported 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 correspondingdetailed information. Then, this detailed information is formatted into one orseveral TEC events (in most cases, only one event) and then sent to the TECserver. The rules engine will forward these specific events to the TEC eventconsoles.

If an error occurs during the execution of the sap_alert_reader.sh script, anevent of class AMS_WR3MIB_PROCESS_ALERT is sent to the TEC stating

sap_alert_reader.sh

sap_alert_reader_cb.sh

r3slogr3mib

wr3rfc

MIB RFC

FunctionModules

C C M S

Rules Engine

Event Console

drill-down

SAP InstanceTEC Event Server

R/3 Manager

SAP Application Server

specific eventsdrill-down events


sap_alert_reader.sh failed <error message>. The script also createsautomatically a log file residing in the /tmp directory (UNIX) or %DBDIR%\tmpdirectory (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 TECstating sap_alert_reader_cb.sh failed <error message>. The script alsoautomatically creates a log file contained in the /tmp directory of the TECserver. The log file is named sap_alert_reader_cb.log.

The following is an example of a drill-down process. The CUA buffer qualityhas decreased below the defined level. CCMS will generate an alert on theMIB notifying that some buffer is having a problem. The alert adapter readsthis 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 thisevent to the TEC server. The convert_mib_to_internal_alert rule of the TECtriggers on this generic event and launches a drill-down process. This rulealso drops the event. The drill-down will get the more detailed informationexecuting the Alert Reader task. This uses wr3rfc to read the internal alerttable of the SAP system, and then it determines which buffer is having aproblem and sends that message to the TEC server through an event of anSAP_ALERT_BUFF_CUA class. The TEC server will forward it to the eventconsoles.

5.3.2 Alert Control ProcessThis process can also be launched by rules that come with the Tivoli Managerfor R/3. For example, when an operator closes (on the TEC console) an eventcorresponding to an internal alert, a change rule will trigger in order to resetthe corrupting alert in CCMS inside the R/3 system. The process is similar tothe drill-down: When one of these rules triggers, it executes a script namedsap_alert_control_cb.sh located in $BINDIR/TME/TEC/scripts. This scriptruns on the TEC event server and launches a task with the application serveras task endpoint. The corresponding script that is run on the applicationserver is named sap_control_reader.sh and is located in$BINDIR/../generic_unix/TME/SAP/2.2C/sh or, in case the application serveris 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/3application server and runs the J_8C1_ALERT_CONTROL function moduleimported in the SAP system during the Tivoli Manager for R/3 configuration.The function module will reset or acknowledge the alert in CCMS.


If an error occurs during the execution of the sap_alert_control.sh script, anevent of class AMS_WR3MIB_PROCESS_ALERT is sent to the TEC statingsap_alert_control.sh failed <error message>. The script also automaticallycreates 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 TECstating sap_alert_control_cb.sh failed <error message>. The script alsoautomatically creates a log file contained in the /tmp directory of the TECserver. The log file is named sap_alert_control_cb.log.

5.3.3 Syslog AdapterThe Syslog Event Adapter monitors the R/3 syslog file for new entries andforwards formatted events to the Tivoli Enterprise Console (TEC). The SyslogEvent Adapter uses the same configuration values that were defined for theAlert Event Adapter. In particular, the Syslog Event Adapter polls R/3 at thepolling interval and this polling interval can be different from the intervalconfigured for the Alert Event Adapter. To display and change theconfiguration values for an Alert Event Adapter, run the Display EventAdapter Configuration and Configure Event Adapter jobs, respectively. Referto 4.3.5, “Configuring event handling” on page 151 about these jobs.

Because the syslog event adapter obtains syslog messages through the R/3remote function call (RFC) interface, the syslog event adapter must log on tothe R/3 system. The syslog event adapter uses the same R/3 user IDinformation as the wr3rfc-based function. To configure the RFC logonparameters, refer to 4.3.4.6, “Configuring the RFC” on page 145. TheManager for R/3 provides tasks to start and stop the syslog event adapter thatcan 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 eventadapter: r3slogIID.cl and r3slogIID.conf, where IID represents the two-digitR/3 instance number. These configuration files are created after you run theConfigure Event Adapter task and, therefore, exist only after you have run thistask at least once for the specific R/3 application server. The r3slogIID.cl andthe r3slogIID.conf configuration files are located in one of the followingdirectories:

Managed Node $BINDIR/TME/SAP/2.2C

TMA Endpoint $LCF_BINDIR/../TME/SAP/2.2C


The r3slogIID.cl defines the syslog events that are sent to the TEC. Eventsthat are not defined in this file cause the syslog event adapter to send eventswith the event class SAP_SYSLOG_MSG. Modify the entries in ther3slogIID.cl file to customize the syslog events to be sent to the TEC or addnew 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 inthe r3slogIID.cl file. Entries for many syslog events are defined in ther3slogIID.cl file for your convenience. Most of the entries are commented.Commented lines are preceded by a semicolon (;). To send additional syslogevents to the TEC, uncomment the appropriate event entries. Similarly, if youdo not want to send one of the default events to the TEC, precede theappropriate event entry with a semicolon (;), or you can add filter criteria tothe r3slogIID.conf file.

If you want to define additional syslog events to send to the TEC, add newsyslog 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-caseletters.

Severity Specifies the event severity and is optional but must bespecified if an event class is specified. This value, ifspecified, must be one of the following: 10, 20, 30, 40, 50, or60. 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 Specifies the event class and is optional. If you do notspecify an event class, the default class isSAP_SYSLOG_msgID, where msgID is the three-charactermessage ID. You must create a .baroc file and define theevent class similar to the event class definitions in thetecad_wr3slog.baroc file in the$BINDIR/../generic_unix/TME/SAP/baroc directory. The


recommended format for defining an event class isSAP_SYSLOG_msgID.

The r3slogIID.conf file contains TEC event filter statements. By default, allsyslog events that are not specified in the r3slogIID.cl file are classSAP_SYSLOG_MSG and are filtered out. Only those events that arespecified in the r3slogIID.cl configuration file are sent to the TEC. If you wantto see all syslog events, comment out the Filter statement in ther3slogIID.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 50 SAP_SYSLOG_A05;A07 30 SAP_SYSLOG_A07A08 50 SAP_SYSLOG_A08;AB0 30 SAP_SYSLOG_AB0;AB1 30 SAP_SYSLOG_AB1;B15 40 SAP_SYSLOG_B15


wr3slog.conf file

These examples are templates; so, if you would like to perform someprocesses using the Syslog Event Adapter, you need to modify these

#**********************************************************************## 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=0ConnectionMode=connection_less

ErrorLogLevel=MINORTracingLogLevel=LOW

FilterMode=OUTFilter: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=


template files. The next section introduces some examples of how the SyslogEvent Adapter can be used to automate operations of SAP R/3.

5.3.3.1 Examples of customizing Syslog Event AdapterThe new Syslog Event Adapter provides a valuable new way to monitor thestatus of your R/3 systems and can be a key component of R/3 eventautomation. The R/3 SYSLOG is a valuable source of information about thethe R/3 system because most activity within the R/3 system is reflected inSYSLOG entries. R/3 administrators typically use the SYSLOG to diagnoseproblems 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 becausethe traditional method of exposing SYSLOG events outside of R/3 (via theAlert Event Adapter) did not support multiple, simultaneous events, and eachdesired SYSLOG event had to be made "alertable" by changing R/3parameters via CCMS.

The new Syslog Event Adapter avoids these problems by bypassing the AlertEvent Adapter and, instead, directly accessing the R/3 SYSLOG via RFC.Also, since the filtering and event severity is controlled by the adapterconfiguration files, the administrator has considerable control over the eventsthat the Syslog Adapter sends to the TEC.

Below are two examples of how the Syslog Adapter can be used to automateoperations of SAP R/3.

Example 1: Operations mode changeMany customers automatically change SAP R/3 operation modes to tailor thedistribution of dialog and batch work processes to the expected R/3 workload,such as providing more batch work process during the night. The SyslogAdapter can be used to detect this operations mode switch and trigger a TECrule that could automate the release of batch jobs.

To make the Syslog Adapter detect operation mode changes, you must addevent "EEA" to Syslog Adapter Configuration file and to the Syslog baroc fileto allow these types of events to pass to TEC. Refer to section "CustomizingSyslog Events" in the Tivoli Manager for R/3 Users Guide Version 2.0,SC31-8411, for information on adding new syslog events to the SyslogAdapter.

If you change the tecad_wr3slog.cl file or the tecad_wr3slog.conf file, youmust stop and start the Syslog Event Adapter to incorporate the changes.

Note


Example 2: Customizing messagesABAP programmers sometimes write messages to the SYSLOG to providestatus or diagnostic information about the work being done within thatprogram. The Syslog Adapter can capture these events and forward them onto the TEC to aid in monitoring the workflow within the R/3 system. In thiscase, the Basis Administrator has added a new syslog identifier to "Z01" toR/3 (via transaction SE92), and the application has been modified to sendstatus messages using this "Z01" message class to the R/3 syslog. TheSyslog Adapter will also have to be configured to send "Z01" SYSLOG eventsto TEC. An example of the changes to the application code is as follows:

5.3.4 Tivoli Distributed MonitoringBesides getting alerts out of the SAP R/3 System using the event adapter, theTivoli Manager for R/3 provides a second way to collect information fromSAP: Tivoli Distributed Monitoring. The interaction between Tivoli DistributedMonitoring and SAP R/3 works as shown in Figure 101. There are two kindsof monitors available, the central monitors and the remote monitors. Theremote monitors, running on the SAP application servers, use two interfacesto access the SAP system, the RFC (wr3rfc), and the MIB (wr3mib). The

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'

EXPORTINGSL_MESSAGE_AREA = 'Z0'SL_MESSAGE_SUBID = '1'PRE_PARAM_LONG = 'ZSAPDEMO4 Started'

EXCEPTIONSOTHER_PROBLEM = 1.

WAIT UP TO 20 SECONDS. "Simulated workCALL FUNCTION 'RSLG_WRITE_SYSLOG_ENTRY'

EXPORTINGSL_MESSAGE_AREA = 'Z0'SL_MESSAGE_SUBID = '1'PRE_PARAM_LONG = 'ZSAPDEMO4 Processing 10000 records'



EXPORTINGSL_MESSAGE_AREA = 'Z0'SL_MESSAGE_SUBID = '1'PRE_PARAM_LONG = 'ZSAPDEMO4 Processing 20000 records'



EXPORTINGSL_MESSAGE_AREA = 'Z0'SL_MESSAGE_SUBID = '1'PRE_PARAM_LONG = 'ZSAPDEMO4 Processing Complete'



central monitors run on the TMR server where the Tivoli Manager for R/3 isinstalled, but they monitor a R/3 application server on another Endpoint. Theyonly use the RFC interface because only this interface can be accessedremotely. The MIB interface can not be accessed remotely. The remotemonitors and the central monitors are created from two distinct monitoringcollections: R3 Server Remote Monitors and R3 Server Central Monitors. Ifyou look at both monitoring collections, you will find that they have somemonitor sources in common:

• Page Area

• Roll Area

• Buffer information

• OS Collect Application Server

Besides these common sources, the R3 Server Remote Monitors collectionincludes:

• 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


Figure 101. Tivoli Distributed Monitoring in an SAP R/3 System

The remote monitors use both wr3mib and wr3rfc programs to access theMIB and the RFC interfaces of the SAP system. The performance informationand the SAP availability monitors get their information from the MIB interfaceand, thus, use wr3mib. As this program cannot be executed remotely, we onlyfind these two kinds of monitors in the Server Remote Monitor collection. Thecentral monitors only have the ability to access the SAP systems using theRFC interface. You can execute the wr3rfc from a central point, such as theTMR server. The Manager for R/3 does not always have direct access to theR/3 database server, and it never has direct access to OS/390, which is whythe corresponding monitors can only be created from the R3 Server CentralMonitors collection.

wr3rfc

RFC

FunctionModules

C C M S

SAP Instance

SAP Application Server

wr3mib

MIB

Rules Engine

Event Console

TEC Event Server

wr3rfc

CentralMonitors

Remote Monitors

Distributed Monitoring

TMR Server

R/3 Manager

R/3 Manager

Distributed Monitoring


Each time a central or remote monitor is running, the gathered SAP R/3information is compared to the pre-defined threshold. If the current thresholdis exceeded, a pre-defined action is executed. Typically, an event will begenerated and sent to the TEC event server. Each monitoring sourcecontained in the monitoring collections has an associated event class. Theseevent classes are used when a forward an event to the TEC action wasspecified as the action. The wr3rfc utility is the tool provided by the TivoliManager for R/3, which communicates with SAP R/3 through the RFCinterface. As described in 4.3.3.4, “Creating a RFC User” on page 138, theremust be an RFC user defined and a transport job executed before thecommunication can happen. This defined user is a CPIC (Common ProgramInterface Communication) user, which means that this user can only accessthe SAP R/3 system through the RFC. To prohibit unauthorized access to theSAP R/3 system with this user, they have no authorization to log on using aSAPGUI. The profile of this user only allows them to run the ABAPprograms/function modules with minimal a set of authorizations. Thetransport job imports some function modules that will be executed to getinformation from the CCMS. The wr3rfc program can be triggered from theTivoli Distributed Monitoring or by the drill-down. The necessary parameters(for example, user ID, password, client) for the wr3rfc execution are stored inthe TMR database after the configuration step Configure Remote FunctionCall. These parameters can also be entered in the wr3rfc_cfg file in thedirectory $BINDIR/../generic_unix/TME/SAP/2.2C/rfc on the machine onwhich 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. Thelast argument to wr3rfc is always the rfc_interface file, which contains thefunction module to execute and the export/import parameters needed by thisfunction module.

The objective of the Server Central Monitors collection is to run themonitors on a machine other than the application servers in order to avoidthe consecutive workload on the R/3 machines. But, as the load generatedby the monitors running on an application server is generally negligiblecompared to the load generated by the SAP application itself, werecommend that you use as often as possible the Server Remote Monitorscollection. Moreover, the events coming from central monitors will notcorrelate with those coming from remote monitors. However, for databasemonitoring and OS/390 monitoring, you must use the Server CentralMonitors collection, as this is the only one that provides this kind ofmonitor.

Note


When triggering wr3rfc with an rfc_interface file as the argument, thespecified function module will execute inside the SAP R/3 with the specifiedimport parameters. The function module will end up by assigning the exportparameters to wr3rfc. The collected information is now available outside theSAP R/3 system. Depending on which functionality the wr3rfc triggered, thedata will be directly sent to the TEC server (for a drill-down) or will becompared to thresholds by the Tivoli Distributed Monitoring engine. In thiscase, and if a threshold is crossed, the pre-defined consecutive action will betaken. The following function modules are provided by the Tivoli Manager forR/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 inthe $BINDIR/../generic_unix/TME/SAP/2.2C/rfc directory of the ManagedNode where the Tivoli Manager for R/3 is installed or, in case of the TMAEndpoint, on $LCF_BINDIR/../../generic_unix/TME/SAP/2.2C/rfc. Except forthe first two, these function modules are all used by the Tivoli DistributedMonitoring monitors.

The import and export parameters stanzas of the rfc_interface filecorrespond respectively to the export and import parameters of thefunction module in the SAP system.

Note


5.3.5 Default monitoringThe purpose of this section is to show and explain the default monitoringcapability provided by the Tivoli Manager for R/3, which is based on the TivoliDistributed Monitoring concept. Information contained in this section will givethe SAP administrator a view of the capabilities and an understanding of themonitoring of the R/3 system by the Tivoli Manager for R/3. The configurationof the Tivoli Manager for R/3, to enable the monitoring functions on one R/3system, results in an indicator collection, three profile managers, two newmonitoring collections, and two subscription lists. Remember that the<SAPhost>_<SID> is an alias for one R/3 system. This set of profilemanagers and subscription lists is created in the Manger for R3 policy regionin order to monitor separately the three components of an R/3 system. Thetwo monitoring collections provide a set of specific new monitors that allowthe management of an R/3 system. Monitoring collections are explained indetail in 5.3.5.2, “Monitoring Collections” on page 202. Each profile managercontains a Tivoli Distributed Monitoring profile, in which are added somepredefined monitors in order to provide, by default, a basic monitoringcapability immediately after the initial configuration of the Tivoli Manager forR/3. These monitors are created, by default, among the list of monitorsprovided by the two new monitoring collections. Profile managers and TivoliDistributed Monitoring profiles are described in the next section: 5.3.5.1,“Default Profile Managers, Subscription Lists, Profiles” on page 199, and thefull list of the available monitors is given in 5.3.5.5, “Monitoring SourcesAvailable from Monitoring Collections” on page 217.

5.3.5.1 Default Profile Managers, Subscription Lists, ProfilesFor the R/3 System policy region, each profile manager (created by default bythe 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 NodeMonitors. And depending on the monitoring method you want to use, thereare two possibilities: Remote monitoring and Central monitoring. Thehierarchy 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 PolicyRegion. Then it goes down to the R3 System sub-policy region and then theR3 App Server profile manager with its monitoring profiles and thesubscription lists. Notice that the R/3 Systems and the profile managers areon the same region. Also notice that the profile managers and the profilescontain no SID-specific information, which is really showing us the newarchitecture of this Manager for R/3.


Figure 102. Default Profile Managers, Subscription Lists and Profiles

The three default profile managers are:

R3 App Server Monitors Profile ManagerThe R3 App Server Monitors profile manager contains the followingapplication server profile:

• R3 Server Remote Monitors

• R3 Server Autodiscovery Monitors

• R3 Server Central Monitors

R3 Server Remote Monitors Profile The R3 Server RemoteMonitors profile containsmonitors for buffer qualityfor each of the differentbuffers, maximum percentused for roll and pageareas, R/3 response timefor different user

R3 DB Server Monitors R3 App Server Monitors R3 Managed Node Monitors

R3 Server Autodiscovery Monitors R3 Server Remote Monitors R3 Server Central Monitors

Default subscriber forCentral Monitors

App Server List

Profile Manager

Profile

Subscription Lists

Manager for R3R/3 Systemsub-policy region

R3_Indicators

Indicator Collection

TMR Server


processes, and applicationserver status.

R3 Server Autodiscovery Monitors Profile The R3 ServerAutodiscovery Monitorsprofile contains theapplication server statusmonitor. This monitorreturns the status of anR/3 application server.When you use automaticdiscovery to create yourR/3 system and serverobjects, this profile mustalways be distributed tothe application servers.

R3 Server Central Monitors Profile The R3 Server CentralMonitors profile enablesyou to use monitors fromthe R3 Server CentralMonitors and DistributedMonitoring collections.This profile is empty, andthe only valid subscriber isthe TMR server.Monitoring of remotemachines is performedfrom the TMR bydistributing the profile tothis subscriber.The reasonis that, as the TMR serverhas the Tivoli Manager forR/3 installed, it can run thewr3rfc program to executethe monitors remotely andthen work as a proxy in theCentral monitoringprocess.

You can distribute other monitors to your R/3 application servers duringdiscovery by adding the monitors to this profile.

Note


R3 DB Server Monitors Profile ManagerThe R3 DB Server Monitors profile manager contains the R3 DB ServerCentral Monitors profile.

R3 DB Server Central Monitors Profile The R3 DB Server CentralMonitors profile enablesyou to use monitors fromthe Server Centralmonitoring collection, inparticular, the monitors forOS/390 and for thedatabase server. Thisprofile is empty, and theonly valid subscriber is theTMR server. Monitoring ofremote machines isperformed from the TMRby distributing the profileto this subscriber.

R3 Managed Node Monitors Profile ManagerThe R3 Managed Nodes Monitors profile manager does not contain anydefault profiles and is provided so you can create monitor profiles fromDistributed Monitoring collections. The default subscriber is the TMR server.Subscribe the appropriate Managed Nodes to this profile manager. Pleaserefer to the Framework 3.6 User's Guide, GC31-8433 for more informationabout creating a profile from a profile manager.

5.3.5.2 Monitoring CollectionsThanks to these two monitoring collections, you get a wide set of internal andexternal 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 arecontained in the R3 Server Remote Monitors monitoring collection and in theR3 Server Central Monitors monitoring collection. These two monitoringcollections are available for each R/3 system you will manage in your TMR.The monitoring collections are run against R/3 application servers only. ForR/3 database servers, you have to use monitors provided by the monitoringcollections in the Tivoli database management products, for example, theTivoli Manager for Oracle. The following figure shows the two monitoringcollections added by the configuration of the Tivoli Manager for R/3 system.


Figure 103. Monitoring Collections Provided by the Tivoli Manager for R/3

The monitors from each of the two monitoring collections differ in where theyare supposed to be distributed and run. They do not differ in what they aremonitoring, as both monitoring collections have the same set of monitorsexcept for SAP availability, performance, and OS/390 monitors. Monitorsbelonging to the Server Remote Monitors collection must be run on a specificmachine and will monitor that machine directly. Such monitors are distributedand run on the R/3 application server. This means that the Tivoli DistributedMonitoring profile containing these monitors must have a R/3 App Server Listas subscriber. On the other hand, monitors from the Server Central Monitorscollection can be compared to proxies. This means they are distributed to amachine and monitor other machines remotely using the wr3rfc program.According to that characteristic, Server Central monitors have to bedistributed 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

The monitors run against the application servers, but there are OS/390DB2 database monitors in the central collections that can provide someOS/390 DB2 information.

Note


R/3 object is specified as a parameter when you create the monitor. Also,another difference between the two monitoring collections is the monitoring ofthe SAP system availability, the performance of an R/3 server, and themonitoring of OS/390. Indeed, only the Server Central monitoring collectionprovides monitors for the operating system running the database server, theDB2 database on OS/390, and OS/390 itself. On the other hand, the SAPsystem availability and performance monitors are provided only by the ServerRemote monitoring collection. In 5.3.5.5, “Monitoring Sources Available fromMonitoring Collections” on page 217, all the monitoring sources are describedalong with their functions and the monitoring collection they belong to.

5.3.5.3 Predefined Default MonitorsAfter you finish installing and configuring Tivoli Manager for R/3, you will seesome predefined default monitors ready to use and to start monitoring yourSAP system. You can find these default monitoring profiles in the R3 AppServer Monitors profile manager as shown in Figure 104.


Figure 104. The Default R3 App Server Profile Manager

There are only two pre-defined default monitors in the R/3 App Server profilemanager, that for remote monitors collections and for Autodiscovery monitors.The R3 server Central monitors profile is empty. To access pre-defineddefault monitors for servers, start by double-clicking the Manager for R/3icon from the Tivoli Desktop. You will see three profile manager icons, one forR3 App Server Monitors, one for R/3 DB Server Monitors, and one for theManaged Node Monitors. By clicking on the first icon, and then again on theAutodiscovery profile icon, you will see the pre-defined default monitors forR3 Server Autodiscovery Monitors as shown in Figure 105. You can also addsome monitors to this profile, which are needed to be distributed to the R/3application server during the discovery process.


Figure 105. Predefined R3 Server Autodiscovery Monitors

Then, still in the R3 App Server Remote Monitors profile manager, you canopen the R3 Server Remote Monitors profile that contains pre-defined defaultmonitors as shown in Figure 106.


Figure 106. Predefined R3 Server Remote Monitors

The R3 Server Central Monitors profile contains, by default, no pre-definedmonitors. Also, the other two profile managers do not have pre-definedmonitors in their profile. For the R3 DB Central Monitors profile, you can usethe 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, theTivoli Manager for DB2 or Oracle.

5.3.5.4 Distribution of Monitoring ProfileOnce you have enabled the default monitors you want to see in your TECEvent Console, or by creating new monitors on a new profile, you need todistribute this profile to the subscribers you have defined. This is done byselecting the profile in the profile manager and selecting the subscribers youwant to distribute to. Then select Profile Manager from the menu bar andDistribute... from the pull-down menu as shown in Figure 107.


Figure 107. Distributing Monitoring Profile

Also make sure the Alert event adapter is running because the wr3mibprogram is also part of the Distributed Monitoring mechanism in case of usingthe 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 fromthe icon pull-down menu as shown in Figure 108.


Figure 108. Starting Alert Adapter

After performing these steps, you now have your Distributed Monitoringmonitors running against your SAP system, in this case, the applicationserver. You can see these events on the TEC event console as shown inFigure 109.


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 openthe 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 selectingone of them and clicking the Edit Monitor... button, you will see moreinformation about this monitor as shown in Figure 110.


Figure 110. Modifying a Default Monitor

In this window, you can modify a set of pre-defined fields for this monitor inorder to customize the way you want to be notified when it occurs and alsothe way you want to react when it occurs. This second option can be done byclicking Run program and then selecting which program you want to run,either on the monitored host or on the Managed Node of your choice. Formore information on all fields you can modify and what they will do, simplyclick the Help button.

If you want to create a new monitor, you can start by opening a monitoringprofile you want to add your monitor to, for example, from the R3 ServerCentral Monitors profile. This window is shown in Figure 111. Then, justselect the Add Monitor... button to create a new monitor.


Figure 111. Profile Properties to Add a New Monitor

After this is done, you will see the Add Monitor to TME 10 DistributedMonitoring Profile window where you can select on the left the MonitoringCollections available, and on the right, the Monitoring Sources for eachMonitoring Collection. Depending on your selection of a Monitoring Source,sometimes you will also have a field where you can select the attribute to thisMonitor 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 Monitorsprofile manager and create a monitor there. We select the R3 Server RemoteMonitors as our Monitoring Collection, and we will create a Work process asour Monitoring Source. For some monitor sources, there are monitorarguments to fill in, as in this case here, as shown in Figure 112.


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 haveall available options for your monitor to customize as you want (see Figure113 for more details).


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 Collectionfor your new Monitor. This is shown in Figure 114.


Figure 114. Select Indicator Collection

You can simply choose the default R3 Indicators, or you can create anotherone if you want (refer to Figure 115).


Figure 115. Indicator Collection List

Do not forget to select Profile from the menu bar and then Save from thepull-down menu to finish creating your new monitor. After distributing thismonitoring profile, you can see the result of this monitor on the TEC EventConsole as shown in Figure 116.


Figure 116. Work Process Monitor Event on TEC

5.3.5.5 Monitoring Sources Available from Monitoring CollectionsThe purpose of this section is to show what the Tivoli Manager for R/3 canmonitor on a SAP R/3 system using Tivoli Distributed Monitoring monitors,coming from the two monitoring collections provided by the module. TivoliManager for R/3 provides 24 monitoring sources that monitor the R/3application itself, the operating system the R/3 application runs on, and thedatabase. For the R/3 application, the module offers the capability to monitorthe memory allocations, such as the different R/3 buffers, the spaceallocations, such as the pages, the response time performance, and theavailability of a SAP system. There are also several new monitoring sourcesin this new version of R/3 Manager, such as: work process, long runningprocess, and cancelled job. For the operating system, monitoring sources are


available to monitor the operating system of either the R/3 application serveror the R/3 database server. The monitoring of the operating system alsoincludes a monitoring source for the OS/390 operating system. Then, for thedatabase itself, Tivoli R/3 Manager proposes a monitor source to monitor theDB2 database running on OS/390. The following table lists these monitoringsources associated with their monitoring collection. Note that for eachmonitoring source a list of attributes is available to configure the monitor.These lists are presented in Appendix C, “Monitor sources and theirattributes” on page 361, and you can also refer to the SAP R/3 documentationfor details and explanations about these attributes.

Table 9. Monitoring Sources

Monitor Sources Server Remote Collection Server Central Collection

Roll Area X X

Page Area X X

Work Process X

Work Process DispatchQueues

X

Long Running Process X

CUA Menu and TextBuffer

X X

PRES Screen andDynpro Buffer

X X

TTAB Table DescriptionBuffer

X X

FTAB Field CatalogBuffer

X X

SNTAB Short NameTabBuffer

X X

IRBD Initial RecordsBuffer

X X

TABL Generic KeyBuffer

X X

TABLP Single KeyBuffer

X X

PXA Program Buffer X X


5.3.6 TEC event classes and rulesIn SAP R/3 monitoring, each event will be processed by using TEC eventclasses and TEC rules. In this chapter, we introduce these TEC event classesand rules as related to SAP R/3 monitoring.

5.3.6.1 TEC Event Classes and Event SourcesDuring the configuration of the TEC event server for the Tivoli Manager forR/3, new event classes defined in three baroc files are imported in the new orextended rule base:

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

sap_server_monitor_35.baroc Defines the event classes used by theTivoli Distributed Monitoring monitors forR/3. The name of this file depends on theversion of Tivoli Distributed Monitoringthat is used; sap_server_monitor.baroc isused for versions prior to 3.5.

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

OS Collect - ApplicationServer

X X

Application ServerStatus

X

Dialog Performance X

Update Performance X

Batch Performance X

Spool Performance X

OS Collect - DatabaseServer

X

OS/390 X

OS/390 DB2 X

Cancelled Job X

Monitor Sources Server Remote Collection Server Central Collection


These baroc files reside, by default, in the$BINDIR/TME/TEC/<RuleBaseDir>/TEC_CLASSES directory of the TECserver. Figure 117 shows the hierarchy of these event classes. A complete listof the event classes of the super classes SAP_Internal_Alert,SAP_MIB_Unique_Alert, SAP_MIB_Generic_Alert, andSAP_Server_Monitors can be found in Appendix B, “Event classes for TivoliManager for R/3” on page 347.

Figure 117. Event Classes

All event classes under the SAP_MIB_Alert super class correspond to theCCMS alerts placed by R/3 on its MIB interface. These alerts are read by thewr3mib program and converted to TEC events of the appropriate class. Someof them are only high-level indications of a problem and will require adrill-down process to get more information. These generic events have anevent class defined under the SAP_MIB_Generic_Alert. Other events coming

SAP_APM_HEARTBEATSAP_Alert

AMS_WR3MIB_PROCESS_ALERTSAP_Internal_Alert

SAP_ALERT_OSCO_LOAD

SAP_MIB_AlertSAP_MIB_Unique_Alert

SAP_ALERT_SAPSysUpSAP_MIB_Generic_Alert

SAP_SYSLOG_RFC_ERRORSAP_SYSLOG

SAP_SYSLOG_MSGSAP_SYSLOG_A05

Sentry2_0_BaseSentry3_5_Base

SAP_Server_MonitorsAPSRVR_STATUS_MONITORSAP_CANCELLED_JOB_MONITOR

sap_tecad.baroc

tecad_wr3slog.baroc sap_server_monitor_35.baroc

EVENT


from the MIB and not requiring a drill-down have an event class defined underSAP_MIB_Unique_Alert. Drill-down processes get detailed informationthrough the RFC interface of the R/3 system (using the wr3rfc program).Resulting information is formatted into TEC events of classes defined underSAP_Internal_Alert. Events of the class AMS_WR3MIB_PROCESS_ALERTare generated when the alert control and alert reader tasks encounter anerror.

All the events previously described (directly sent by the adapter, resultingfrom drill-down and resulting from reader or control routine error) are sent tothe TEC server with WR3MIB as the event source.

For reading the syslog, there is a separate r3slog adapter. All syslog alertsdetected by the adapter are forwarded to the TEC server with thecorresponding event class under SAP_SYSLOG_MSG. The event source forthis syslog event is WR3SLOG.

All alerts detected through the R/3 Remote or Central monitors are forwardedby the Tivoli Distributed Monitoring engine to the TEC server with thecorresponding 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, tothe BATCH_SERVICE_MONITOR, DIALOG_SERVICE_MONITOR,SPOOL_SERVICE_MONITOR, and UPDATE_SERVICE_MONITOR eventclasses use wr3mib to get the information from the SAP system. The SAPAvailability monitor is now becoming one of the special event class:APSRVR_STATUS_MONITOR (SAP_Status_Monitors class), and also useswr3mib. Events of the AMS_R3MONITOR_ALERT class are generated whena Tivoli Manager for R/3 Distributed Monitoring monitor encounters an error.All other R/3 monitors use wr3rfc. All the events described above (generatedthrough Tivoli Distributed Monitoring) are sent to the TEC server withSENTRY as the Event Source.

5.3.6.2 TEC RulesDuring the configuration of the TEC event server for the Tivoli Manager forR/3, new rules defined in three rules set files are imported in the new orextended rule base. The following are the overview of each rules set:

There is no description for the event classes SAP_ALERT_GenP5 toGENP14 because they map to R/3 Alert Classes that SAP has reserved forfuture use but that are not used at the moment.

Note


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 TivoliDistributed Monitoring (monitors for R/3, event source =SENTRY).

sap_default.rls For rules acting on events that need to be correlatedacross 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 aredisplayed for 60 seconds, then closed; internal harmless events areclosed immediately. There are three rules that support harmlessprocessing:

• harmless_set_timer

• drop_new_harmless

• harmless_still_open

2. Check for and remove duplicate events. There is one rule that supportsduplicate event removal:

• dup_sap_event

3. Performing drill-down processing. Drill-down is performed whenhigh-level generic events are received from the MIB. Drill-down goesback into R/3 to get more detailed event information. In doing so, theoriginal event is dropped, and only the drill-down event is presented onthe 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 alertacknowledgment/closure. This ensures that event/alert states arecoordinated across the two environments. This makes Tivoli behavemore like SAP when dealing with SAP events. There are two rules thatsupport 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, whenthe application server’s status changes from down to up, it will be goingout to get all existing alerts in that application server. This is done bythe rule:


• sapsysup_read_all_internal_alerts

6. Discarding buffer alerts if they occur within 35 minutes of an R/3operational mode switch. Generally, if an operational mode switchoccurs, the R/3 buffers are expected to remove old data and insert newdata. Poor buffer performance is expected during these times. There isone 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 isbecause R/3 only allows one R/3 syslog message to occupy the syslogalert status at a time. By closing the syslog alerts immediately, theprobability of getting the next syslog alert is increased. Since there isno drill-down process needed, all SAP syslog alerts should be receivedby the syslog event adapter. There is one rule that supports closingsyslog events using alert control processing:

• reset_syslog_alert

8. Forwarding events to alternate TEC servers. There is one rule thatsupports 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 tothe value of the R/3 system label, and the sub_origin slot is assigned tothe value of the R3 application server name as defined to Tivoli. Thereis one rule that supports system label assignment:

• set_r3sapname_slot

2. Check for and remove duplicate events. Also, increase the repeat countslot 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 DistributedMonitoring host machine coming up/going down. This entails closing allDistributed Monitoring outstanding events for the application server(s)on that Managed Node. There are four rules that support this statuscoordination:


• 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/goingdown. This entails closing all Distributed Monitoring outstanding eventsfor that application server. There are two rules that support R/3 statuscoordination:

• sap_system_up

• sap_system_down

5. Discard Distributed Monitoring events if they come in while thecorresponding application server is down. There is no need to processthese events since there is a larger underlying problem. There is onerule that supports Distributed Monitoring event discard:

• sap_system_down_no_more_entries

6. Discard Distributed Monitoring events if they occur within 35 minutes ofan R/3 application server coming up. Generally, when an applicationserver is starting, it is loading/refreshing its buffers; so, poorperformance is expected during these times. There is one rule thatsupports mode changes:

• drop_sentry_events_on_sentry_sysup

7. Handle operator acknowledgment or closure of Distributed Monitoringevents. When an operator acknowledges or closes a DistributedMonitoring 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 toevent slots, which are: R3JobName, R3JobId, and R3JobDate. Thereare 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 ofan R/3 application server coming up. Generally, when an application


server is starting, it is loading/refreshing its buffers; so, poorperformance is expected during these times. There is one rule thatsupports mode changes:

• drop_sentry_event_on_statechange

Please refer to Appendix D, “TEC Rules and Events” on page 373 for moredetailed information about TEC rules and events.

Note



Chapter 6. SAP R/3 Management scenarios

In this chapter, we present a number of management scenarios. Thesescenarios cover areas, such as Availability and Performance, to name buttwo. What follows is a detailed section on each scenario. Each section dealswith the problems faced in that particular area, the Tivoli solutions that can beused to build a robust and workable solution, and an explanation, orsuggestion, 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 themanagement of a whole enterprise structure. Tivoli achieves this by providingan array of products tailored to managing a specific part of the enterprise, butwhich integrate to provide a single solution however they are used. More andmore products are being added to the Tivoli solutions as time moves on, andnew features are being added to the current solutions as they are constantlydeveloped and upgraded.

In today’s world, organizations need a management solution capable ofmanaging everything in an enterprise, something capable of managing theentire enterprise stack from network to application level. The followingdiagram shows an example of the components that comprise an enterprisestack.


Figure 118. An example of the enterprise stack

The problem with this vision of enterprise management is that it is notintegrated. Each level of the stack is managed using a different solution (anisland solution) and, therefore, different software. The gaps between thelevels means that problems that arise can be difficult to spot. For example, aproblem on the network level may cause an effect to the availability of theapplication level. However, this can only be seen by examining both levels todecide where the problem lies. If this was an integrated solution, then thisstep would be unnecessary.

Tivoli products and solutions overcome this visibility problem by providing anintegrated solution for any organization’s needs. Tivoli takes a differentapproach to enterprise management, one that makes it easier to manage andcontrol enterprise resources. The following figure illustrates Tivoli’s model ofenterprise management. This gives some indication of how Tivoli products fitinto different solution designs.

A p p lic a t io n

S ys te m

D a ta b a s e

N e tw o rk

M u lt ip le S A PS ys te m s

In te rn e t

L o tu s N o te s

M Q S e r ie s

P o w e rs o ft

S yb a s e O ra c le In fo rm ix D B 2

W in d o w s N T U N IX

N e tw a re

W in d o w s 9 8

T C P / IPS N A

IP XN e tB IO S

O p e n V ie w S u n N e t S N M P


Figure 119. Tivoli Enterprise Management Approach

As can be seen from Figure 119, the Tivoli solutions all provide a particularpiece of a complete solution. However, the diagram also shows that individualproducts can be implemented to produce a solution for a particular scenario.Tivoli products can be combined to produce any solution an organizationneeds.

More importantly, all the products and solutions can be used to feed a singlepoint of control, enhancing the concept of an integrated solution. In Figure119, 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 asingle point of control for an enterprise management solution. Tivoli providesmanagement modules for a number of different applications, however, for thepurposes of this book, only the three listed are relevant. The next level dealswith the management of fundamental components and also forms the basisfor the scenarios presented in the remainder of this chapter. This level isdivided into different sections of the overall enterprise. All of these sectionsneed to be addressed equally for the success of the enterprise and anymanagement solution that is implemented to service it. The distributed objectframework level deals with the Distributed Object Framework that forms thecore of the Tivoli solutions. This level represents all the objects that are used

Fu ndam e n ta lM ana gem e n t

G lo b a l E n te rp rise M a n a g e r

Tivo li M a nag e r fo r ...S A P R /3 D ata base M Q S erie s

D e p loym en t O p era tion s A va ila b ility S e cu rity

B us inessS ys tem s

M a nag em en t

A pp lica tionsM an age m en t

D is tr ibu tedO b jec t

F ram ew ork

C om p u tingR eso u rces

E n terpriseC o nso le

W o rk loa dS ched u ler

O utpu tM anag er

S oftw a reD istribu tio n

D istrib u te dM onito rin g

D ec is ionS upp ort

A pp lica tionP erfo rm an ce

M ana ger

G loba lS ign-O n

S ecurityM a nage m e nt

P o licy

C om m un ica tio n

Ta sks

S ch e d u lin g

S e cu rity

C o lle c t io n s

C on figu ra tio n

D is tr ib u tio n s

S ys tem s N e tw o rk s D a tab as e s A pp lic a t ion s In te rn e t

SAP R/3 Management scenarios 229

to enable Tivoli to monitor and manage an enterprise. The final levelrepresents all the physical resources of the enterprise that Tivoli is designedto monitor and control.

6.2 SAP R/3 Management scenarios

The management scenarios presented in the remainder of this chapter willdemonstrate some possible solutions of Tivoli products when applied todifferent areas of an enterprise. The problems facing any organization thatwishes to use Tivoli products are how best to use them and which ones touse. 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, adetailed scenario description, a suggested software solution for thatparticular scenario, suggestions on how and why to implement the chosensoftware, 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 dailyoperations 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 itis usually turned over to an Operations group of some description. Operationsis an important department in any large organization. They are the first line ofdefence against system failure and, therefore, against revenue loss. For anoperations group to work efficiently, they need to have reliable and easy touse tools. Operations can usually be split into several key sections. These areas 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


Quite often companies do not invest in training their operations groups toohighly. This is for a number of reasons. The main reason being that theturnover of operations staff is high; therefore, investment in training is lostwhen staff leave. Another reason is that large organizations have second andthird level support departments specialized in the above areas; therefore,educating operators on the same subjects would be a waste of time andmoney.

Companies usually choose instead to invest in some form of monitoring andmanagement solution, as this stays constant while staff come and go.Operations staff then receive at least basic training in all the above areas andare taught how to use the organization’s management solution. Unfortunately,because the technical level of operations staff is kept as low as possible, itmeans that second or third level support staff need to be called for themajority of problems regardless of the severity, or usually, the time. In anorganization with a large array of machines and applications, this can causehighly 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 managementsolution that will help ease the day-to-day tasks they perform and also enablethem to perform the basic tasks, and more, without needing to call support forevery problem. This not only improves the worth of an organization’soperators but also frees up the highly skilled support staff to deal with morecomplex problems.

6.3.2 Detailed scenarioAs listed previously, there are five main areas of operations. All of these needto provide adequate monitoring and management to prevent problems frombeing missed or not correctly addressed. The five sections can be expandedon, and more, precisely defined as follows.

6.3.2.1 Network monitoring and problem determinationThis means the monitoring of the devices that form the network infrastructureof an organization. A network is not just a collection of cables connectingmachines, it also includes components, such as:

• Hubs

• Routers

• Repeaters

• Switches


All of these need to be monitored and managed to ensure the integrity of theconnections between servers and end-users. In an ideal world, it is alsouseful to monitor a network for response times to see where and when it isoverloaded and where bandwidth needs to be expanded or componentsupgraded.

However, when things do go wrong, an operator needs to be able to correctthe problem quickly and efficiently. This requires some ability to understandthe network, its connections and layout, the devices being used, and mostimportantly, a method of gaining access to the device in question.

6.3.2.2 Hardware Monitoring and Problem DeterminationWhereas the section above embraced the monitoring of both the networkhardware and software, this section only deals with the monitoring andproblem determination of server hardware.

Whether an organization is running mostly RS/6000s, AS/400s, or PCServers, they are all made up of a number of components that the machineinternally monitors during normal operations. The problem is that if anorganization has a lot of machines, it is impossible to check each oneindividually. This means that centralized methods of problem alerting andlogging are required in order to manage the hardware correctly.

For example, if a server has a SCSI disk array and one fails, the operationsgroup needs to know about this. Ideally, they need to know which disk it wasand a probable reason for the failure. With this information, the correctsupport personnel can be contacted to solve the problem or replace the disk.However, if this kind of advanced alerting is not available, then a centralmethod of logon is required to allow quick access and PD procedures to becarried out.

6.3.2.3 Operating System Monitoring and Problem DeterminationEvery server in an organization has some form of operating system installedon it. This needs to be monitored, and where necessary, reconfigured ortuned to meet the demands an application or users make of it.

At the operating system level, several things need to be monitored. Thefollowing is a list of possible monitoring point; however, this will differ in lengthand composition depending on the operating system:

• File systems

• Native Operating System Applications

• Error Logs


• User Logs

• Daemons

• Background Processes

• Virtual Memory (Swap Files)

At the base level, an operating system is similar to hardware. It is reallyconstructed of many components that all need to run perfectly for theoperating system to function correctly.

Monitoring is required in order to watch all the vital components of anoperating system and provide some kind of an alert to inform operations of aproblem. Ideally, a monitoring solution is required that will evaluate the natureof the problem and attempt a solution of some kind before alerting operationsto the problem.

For example, if a daemon was to fail, the monitoring solution could attempt toautomatically restart it. If this was unsuccessful, then an alert would be sentto the operator indicating the problem. Another example is a file systemreaching a particular capacity. Again, the monitoring solution could attemptcorrective action before informing the operator. This, of course, also requiressome form of capacity management to track the growth of a file system fromday-to-day.

6.3.2.4 Application Monitoring and Problem DeterminationObviously, the most important task of any operations group is the effectivemonitoring and problem determination of an organization’s business criticalapplications. These days, the protection of their applications is anorganization’s prime goal. When applications fail to perform, or areunavailable, both time and money are lost. Although the areas mentionedpreviously are very important, after all a failure in any of them can render anapplication unavailable, the most important part is the monitoring of theapplication itself.

There are many applications that organizations use; however, this scenariowill focus on a standard implementation of SAP R/3.


Figure 120. Typical SAP R/3 Implementation

Figure 120 shows a typical SAP R/3 environment with two servers, in thiscase RS/6000s, both running AIX. One is performing the role of databaseserver for SAP R/3, and the other is running a single SAP R/3 applicationserver.

First, looking at the SAP R/3 application server, it may be a requirement tomonitor 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 theapplication is running correctly.

The other component or application in the system is the database, in thiscase, DB2 for RS/6000. The following list indicates some of the items thatneed to be monitored with regards to this application:

• Tablespaces (usage, growth and capacity)

• Threads (deadlocks, conflicts)

• Logs

A IXS AP R /3

A IXD B2 fo rR S /6000

R S /600 0 R S /6000


• Load

• Response

From this list, and the one for SAP R/3 shown previously, it can be seen that anumber of items need to be measured per application. When an organizationis only running a few servers or applications, this can be performed manuallyat regular intervals. However, when an organization has many servers andmultiple applications, this becomes an impossible task. Some form ofmonitoring solution is needed, one that will monitor the application either inreal-time or at set intervals, detect any problems, and inform the operationsgroup so that prompt action can be taken.

6.3.2.5 Batch Scheduling, Monitoring, and Problem DeterminationEvery organization, especially those using SAP R/3 or similar ERP packages,employ some form of batch, or background, processing. This can take manyformats, such as daily reports for management, bulk processing of customerorders, bulk invoicing, and so forth. Some organizations run their batchprocessing during normal business hours; however, this is really only feasibleif batch processing is light. Most organizations perform their batch processingoutside core business hours, usually because the batch processing places atremendous load on the system and would render it unresponsive or slow forusers.

Usually batch schedules are time critical. Any failure can place the wholeschedule 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, andmonitoring tools, and they work well. However, they all require someone to belogged on to the machine in order to use them. As said previously, if anorganization only has a couple of systems, then this is not a problem; but ifthere are a lot of servers and SAP R/3 applications, then this becomes animpossible task. When batch processing schedules are time critical, thisbecomes potentially damaging. Job failures can go unnoticed for long periodsof time if manual checking is being performed. Therefore, a monitoringsolution for batch processing is of paramount importance to any organizationthat relies on time critical batch schedules.

For example, an organization has a factory that produces products based onthe output of a batch job. This job reports the supply and demand informationfrom the previous day. This means that this report needs to be availablebefore the start of business on any particular day; otherwise, how does thefactory know what to manufacture? Therefore, if the batch job that isresponsible 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.


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 actionsbefore reporting the failure of the job to the operations group. A good solutionneeds to monitor the execution and progress of the schedule as well as theindividual jobs that make up that schedule.

Certain organizations use cross-platform batch schedules, for example, whenparticular batch jobs on an SAP R/3 system complete they could transfer filesto an MVS system where processing continues. In this case, the organizationwould 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 batchschedules, then it is not really cost effective to implement an industry mademonitoring solution. Instead, it is easier and more efficient to monitormanually. However, how many organizations in present times actually haveonly one or two systems? The answer is not many. Most have severalsystems that perform batch processing and require the constant attention of anumber of operators. Therefore, any monitoring solution needs to be able tomonitor multiple schedules on multiple systems and platforms as well.

The final part of the equation is that any monitoring solution must also providean easy to use interface, and screens and panels that enable an operator togain an overview of the situation with a glance.

6.3.3 Operations software solutionHaving defined the roles and tasks faced by an operations department, thissection will suggest the Tivoli solutions that should be implemented to enablethe smooth and efficient running of an operations department. For thepurposes of this scenario, the following software should be implemented:

• Tivoli Distributed Monitoring

• Tivoli NetView

• Tivoli Manager for R/3

• Tivoli Workload Scheduler

• Tivoli Database Manager Products

• Tivoli Global Enterprise Manager


• Tivoli Enterprise Console

6.3.4 Solution implementationHaving defined the Tivoli solutions to be used for this scenario, the next stepis to explain, or suggest, the best ways to implement them to provide aneffective operations monitoring solution. What follows is a product by productdescription of how each piece of software would slot in to the overall solution.

6.3.4.1 Tivoli Distributed MonitoringThis is a core piece of the solution, as it enables the distribution of all themonitoring profiles to all the servers within the organization. DistributedMonitoring allows the monitoring of the hardware and operating systemsinvolved in any enterprise. System errors and events are forwarded to theTivoli Enterprise Console for the appropriate operator action. The explanationfor this piece of software is purposefully brief. It is merely included becausewithout it some of the other components of the solution would not function.

6.3.4.2 Tivoli NetViewThis product performs a number of functions. Most importantly, it provides away of graphically modeling the environment. This includes both the serversand the network components. NetView enables the servers and network stateto be reviewed at a glance. The icons representing servers and networkcomponents change color depending on the status. This enables an operatorto quickly see problems as they arise. If NetView’s Management InformationBase (MIB) Browser ability is configured correctly, this allows the operator toquickly gain vast amounts of information about a system that has indicated aproblem without the need for logging onto it. NetView also provides a nativetelnet 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 applicationmonitoring. This is because specific scripts have to be written and installedon a local system in order for NetView to receive application alerts. Thesealerts have to be correctly formatted locally before forwarding onto theNetView focal point. However, this failing is a minor one, and when NetView iscombined with other Tivoli solutions, an insignificant one. NetView isunsurpassed in its network management ability.

6.3.4.3 Tivoli Manager for R/3This component is explained in much greater detail in Chapter 2, “What isnew: Tivoli Manager for R/3 Version 2.0” on page 49. The benefits in an SAPenvironment are enormous. Like all the other components, events can beforwarded onto the Tivoli Enterprise Console. Because it also monitors the


SAP system log, this reduces the need for an operator to log on to eachphysical system to check for errors. An operations group only needs to waitfor alerts to appear on the Tivoli Enterprise Console, then action theseaccordingly.

6.3.4.4 Tivoli Workload SchedulerTivoli Workload Scheduler is an important part of any large scale SAPoperations solution. Traditionally, when monitoring SAP batch schedules, anoperator would have to be physically logged into a system to monitor theschedule. This means that if there are multiple systems to monitor, theoperator must have multiple windows open and keep switching between theseto monitor the batch schedules. Tivoli Workload Scheduler removes this timeconsuming and potentially dangerous problem. Because Tivoli WorkloadScheduler can managed batch schedules across different applications,systems, and platforms, only one window is needed. Also, an operator doesnot need to go looking for problems, as these are reported to the TivoliWorkload Scheduler focal point automatically.

There are only two types of batch job inside SAP. These are System or UserCreated jobs. System jobs are those native to SAP. They perform some kindof system maintenance or statistics collection. For example, theREORGJOBS batch job, which deletes old batch job logs from SAP toconserve 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 itcan fail for a number of reasons. When this job fails, it stops clearing downthe batch job logs. As a result, they keep growing unchecked until theyeventually fill the file system they reside in. This can cause the SAP R/3application to crash; so, this job and other system jobs need to be monitoredconstantly to ensure that they are working as planned. This can beaccomplished with the aid of Tivoli Workload Scheduler.

The other type of SAP batch jobs are User created jobs. These are jobs thathave either been written by ABAP developers to perform specific functions foran organization, or they could be standard system jobs that have beenrenamed and adjusted to perform a particular task. In either case, when thesejobs are correctly defined to Tivoli Workload Scheduler, they can bemonitored like any other.

Because Tivoli Workload Scheduler works across different platforms, itmeans that if some of the organizations batch schedules actually run outsidethe SAP R/3 application system, they can still be monitored as a part of thewhole schedule. For example, if some of the processing is carried out on anOS/390 mainframe, this can be monitored by Tivoli Workload Scheduler.


The benefits of Tivoli Workload Scheduler to the stability and reliability of anorganization’s batch processing are many. When configured correctly, it hasthe ability to remove operator error from batch processing. Failed batch jobscan no longer be accidentally overlooked, as they are alerted on when theyfail. This means that prompt corrective action can be taken. Multipleschedules can be monitored and controlled at once. Jobs can be deleted andadded to schedules without the need to actually log onto SAP to do this. Froman operations point of view, Tivoli Workload Scheduler is a great asset andgives peace of mind to both the operations department and organizationmanagers.

6.3.4.5 Tivoli Database Manager ProductsAs demonstrated in Figure 120 on page 234, there are two parts thattraditionally make up an SAP R/3 system. These are the SAP applicationitself and the RDBMS that is used by the application. Like the SAPapplication, 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 requestedby the system administrator. Tivoli Database Management Products enablethe SAP R/3 application database to be monitored in real-time. When aproblem occurs, the Tivoli module detects this and issues an appropriatealert. This means that problems can quickly be identified and solved. Themodule enables the monitoring of databases logs, log archiving, tablespacesize and capacity, deadlocks, and conflicts, to name some of the features itprovides. Sometimes, when problems occur within the SAP application, it canbe traced to a problem in the database system and not the application itself.The Tivoli Database Manager identifies a lot of these problems before theybecome visible to users. This means that the problems can be caught quickerand solved before they cause an interruption of service to the application.

6.3.4.6 Tivoli Enterprise ConsoleThe Tivoli Enterprise Console is the product that brings all of the previouslydescribed products together. It provides a single point where all the events,problems, and information from the other products eventually end up. Thestrength of the Tivoli Enterprise Console is that it is truly a focal point for thewhole enterprise. All the events in an enterprise are filtered by the individualTivoli products and then forwarded onto the Tivoli Enterprise Console. Theseindividual levels of filtering mean that if an alert actually reaches the TivoliEnterprise Console, then it should be genuine and not a false alarm.

6.3.4.7 Tivoli Global Enterprise ManagerThe Tivoli Global Enterprise Manager enables all the different sections to beviewed as a complete business system, whether this means the


representation of the components in a single system or all the systems in anenterprise. The Global Enterprise Manager provides an easy to use andeffective GUI that operators can utilize to monitor and control the entireenterprise. Coupled with the Tivoli Enterprise Console, the Global EnterpriseManager can provide a single solution for an operations department.Because of the way it displays system and component information, it helpsany operator understand how the systems work and interact. It also helpsremove the need for in-depth training in individual components, as thedifferences between all of these are hidden from the operator by the Tivoliproducts and solutions.

6.3.5 Scenario summaryHopefully, this scenario has demonstrated how Tivoli solutions and productscan be employed to provide a robust and workable Operations monitoring andPD solution. In any organization, Operations is the first line of defenceagainst system failure and revenue loss. Most organizations these daysemploy some form of operations group to look after their systems. Therefore,most organizations also have some form of Operations monitoring and PDsolution. Tivoli products enable the Operations solution in any company to becombined with other solutions, for example the Help Desk, to provide anintegrated environment for the management of all systems. The installation ofan Operations solution can be the starting point for the integration of otherTivoli products to enable the management of the whole enterprise.

6.4 Availability and performance scenario

Today, business applications are critical elements of practically everybusiness and organization. Determining whether these applications arefunctioning properly is the single most important issue for systemsmanagement. But applications management is not merely the applicationitself; 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 andhealth are critical to every aspect of efficient operations. Because of this, thequestion should be asked: How can you understand what exists in yourenterprise to efficiently and effectively keep applications updated andavailable? In this context, availability and performance management is theprocess of monitoring an application and its environment while the applicationis running and automatically taking preventive or corrective actions.


6.4.2 Detailed scenarioAs an example scenario, a result of monitoring implementation will be given inthis and the following sections. Prior to every implementation process, a lot ofrequirement analysis should be done first to be able to collect allrequirements and to be able to define the scope of the implementation. Thiscan include, but is not limited to: Business process, systems managementprocess, and functional requirement. The output of these requirementanalysis should then be used as an input for the architecture and designphase before entering the actual implementation phase.

In this scenario, a systems management infrastructure is built andimplemented that enables a Service Delivery organization to monitor andcontrol 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 solutionEnsuring the availability and the performance of your applications requiresthat you have the ability to quickly and easily view and understand the healthof your enterprise. Depending on the systems management organization andtheir need for certain functions, these software solutions should beconsidered for the availability solution:

• Tivoli Enterprise Console

• Tivoli Distributed Monitoring

• Tivoli NetView

• Tivoli Manager for R/3 and other application modules

• Tivoli Database Manager Products


• Tivoli Application Performance Manager

• Tivoli Decision Support


6.4.4 Solution implementationFor availability and performance management, the key process is monitoring.Periodically checking an application and the infrastructure on which itdepends is a good way to detect problems as they occur or as they develop.For monitoring purposes, the Tivoli Enterprise Console and the TivoliDistributed Monitoring are considered the base of the solution. Rememberthat the R/3 Manager, if considered only by the event-sources, is adding theDistributed Monitoring type and two TEC event adapter types of monitoringcollections.

In the monitoring process, just like a common communication process, thereare senders and collectors. Now consider all elements in your infrastructureenvironment that could have generated TEC events from an event source, thesenders. Try to collect all of them and see how many events could have beenpossibly generated from a specific event source. The result could beinteresting. An example of the amount of possible events out of some eventsources 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 willlist 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

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


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

Element List: All Applications Event Source


The following table (Table 11) shows event sources related to networkdevices.

Table 11. Element List: Network Devices

The following table (Table 12) shows event sources related to other systemsand devices.

Table 12. Element List: All Systems

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

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

3494 Tape Library and Magstar drives snmp_MIB

3494 Tape Library and Magstar drives adsm

Magstar Tape drive nt_event_log

External Tape unit errpt


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

Element List: All Systems Event Source


These three tables clearly give an idea of the complexity of your environmentin terms of monitoring. To create a workable solution, first most of theseevents must be reduced in amount. Secondly, how could we manage thisenvironment in terms of: What is the root-cause of the problems if severalevents are sent to TEC at almost the same time? How could you effectivelymonitor 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 couldnegatively affect your organization. To manage the environment, and somanaging the events, some methods must be used. So, in this case, we willbe using a methodology that was previously called: Event ManagementDesign Methodology. Now this methodology is called: Event ManagementDesign/Monitoring Design. A brief explanation about this method will be givenin the next section. And after this section, the monitoring result will bepresented.

6.4.4.1 Event Management Design/Monitoring Design (EMD/MD)The Event Management and Monitoring Design Methodology is an IBMdesign methodology that analyses a client's IT environment and creates atailored design for processing and correlation of the client's systems andnetwork events. More detailed information on this method can be found in theredbook entitled Designing Tivoli Solutions for End-to-End Systems andService Management, SG24-5104.

This method provides a step-by-step approach to prepare and configure theTivoli environment to receive, display, correlate, and perform actions onfiltered events from event sources as data is gathered in the EMD/MDworksheets, an event relationships network including all the customization forthe agent adapters, a distributed manager, and TEC. The stages are asfollows:

• Selecting, Integrating, and Customizing the Event Sources: Once an eventsource is selected for integration and analysis into the framework, theEMD/MD and implementation methods begin being executed in parallel.The event source is integrated into the framework by installing andconfiguring any required TEC adapters and modules. The event source isalso analyzed to determine the repertoire of events it is capable ofproviding. This information is used to code the baroc class definitionswithin TEC and is also used for the filtering analysis in EMD/MD. At thispoint, the event source(s) is fully configured to send selective events upthrough any respective distributed managers or directly to the TEC. TheTEC is receiving only events deemed to be enterprise significant based onestablished policies.


• Customizing the TEC rules (dup-detection, correlation, and automation):The TEC rules writer uses a pre-defined rules template and rule logicflowcharts to create a number of custom templates, one for each type ofevent.

• Outputs (Deliverable): Customized event adapters and event sources,baroc class definitions implemented in TEC, and event rules for eachenterprise significant event (implemented in TEC).

6.4.4.2 The Next StepsBasically, the method offers two ways to come towards the monitoringsolutions. The first one is filtering, which should be done at the event sourcewherever possible. Then try to correlate the resulting events that will be sentto the TEC that has different event consoles for different groups in theorganization. This is illustrated in the following figure.

Figure 121. Illustration of Event Management Design and Monitoring Design

During the filtering activity, for each area on the element lists, the SubjectMatter Experts (SME) must be consulted to identify the most important eventsfor their specific area. To come back to our scenario, and especially fordetermining the monitoring requirements of SAP-related events, weperformed the following steps:

Event Server

systems

network

applications

Helpdesk

Operations

Level 2

Level 3

events

Rules forautomatic actions

& filtering


• Selected the most important events from all event sources that can beused for indicating availability.

• The default monitoring collections regarding the performance indicator(Buffer, Performance, Roll, and Page Area as described in 5.3.5, “Defaultmonitoring” on page 199) will not be used, but instead, they createdthresholds from SAP that actually will be read by the wr3mib adapter. Thisis only the starting point because the SAP SMEs will be able to change forthemselves different monitoring thresholds for the Development (DEV),Quality Assurance (QAS), and Production (PRD) SAP servers. Also, this isthe 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 theextent-growth in the Oracle Tablespaces.

6.4.4.3 The Distributed Monitoring SolutionsIn this section, we give the monitoring solutions to use for specificenvironments to cover the availability and performance monitoring. This willbe presented in several tables. Also, an example of an event worksheet asone of the deliverables from the Event Management Methodology is providedin Figure 122 on page 258.

The following table (Table 13) shows an example of monitor definitions for theR/3 Manager.

Table 13. Tivoli Manager for R/3 Monitors

Monitor Description Parameters Timing

SAP SystemAvailability

Availability monitor:Becomesunavailable: FATAL,Becomes available:HARMLESS toreset

N/A Every 1 minute

Sentry2_0_countstr

Occurrence of anerror ORA-0600 inthe ORACLE alertlog:FATAL

Pattern: ORA-0600 Every 1 minute

Sentry2_0_countstr


Pattern: ORA-1653 Every 1 minute


The following table (Table 14) shows an example of monitor definitions forDomino Manager.

Table 14. Tivoli Manager for Domino/Notes Monitors

Sentry2_0_countstr


Pattern: ORA-1654 Every minute

Sentry2_0_filechk Extent-growth inrelation to max.extents:>10% WARNING,>20% CRITICAL

Output file ofsapdba -check(All Tablespaces)

Every day

Sentry2_0_filechk Number of extentsin relation to max.extents:>70% WARNING,>80% CRITICAL

Output file ofsapdba -check(All Tablespaces)

Every day

Daemon Status Availability monitorfor SAP WR3MIB:Becomesunavailable:CRITICALBecomes available:HARMLESS toreset

Daemon:Tecad_wr3mib

Every five minutes


Program Status Availability monitoron Notesprocesses:Becomesunavailable:CRITICALBecomes available:HARMLESS toreset

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



The following table (Table 15) shows an example of monitor definitions for theUNIX monitoring collection (default monitoring).

Table 15. UNIX Monitoring Collection: Default


Percent Spaceused

Threshold monitoron file system:>80% WARNING>90% CRITICAL<80% HARMLESSto reset

File systems:/var, /var/log, and/tmp

Every 10 minutes

Percent Spaceused

Threshold monitoron file system:>90% WARNING>98% CRITICAL<90% HARMLESSto reset

File systems:/home

Every 10 minutes

Percent Spaceused

Collect monitor onfile system

File systems:/var, /var/log, /tmp,and /home

Every hour

Daemon Status Availability monitoron default UNIXdaemons:Becomesunavailable:CRITICALBecomes available:HARMLESS toreset

Daemons:errdemon, inetd,errpt, portmap,cron, qdaemon,syslogd, snmpd,srcmstr, syncd, init,tecad_logfile

Every five minutes

Available swapspace

Threshold monitoron UNIX swapspace:<20 Mb WARNING<10 Mb CRITICAL>40 MbHARMLESS toreset

N/A Every five minutes

Available swapspace

Collect monitor onUNIX swap space

N/A Every hour


The following table (Table 16) shows an example of monitor definitions for theUNIX monitoring collection (specific monitoring).

Table 16. UNIX Monitoring Collection: Specific


Daemon Status Availability monitoron UNIX daemonfor ADSM:Becomesunavailable:CRITICALBecomes available:HARMLESS toreset

Daemon:dsmserv, dsmadmc

Every five minutes

Percent Spaceused

Threshold monitoron file systems forSP/2 CWS:>80% WARNING>90% CRITICAL<80% HARMLESSto reset

File systems:/spdata, /tftpboot

Every 10 minutes

Daemon Status Availability monitorfor SP/2 CWSBecomesunavailable:CRITICALBecomes available:HARMLESS toreset

Daemons:hardmon, hbd, hrd,kerberos, sdrd,splogd

Every five minutes

Daemon Status Availability monitorfor SP/2 nodesBecomesunavailable:CRITICALBecomes available:HARMLESS toreset

Daemon:Fault_service_Worm_RTG_SP

Every five minutes


The following table (Table 17) shows an example of monitor definitions for theUniversal monitoring collection.

Table 17. Universal Monitoring Collection

Daemon Status Availability monitorfor all SP/2 nodesand CWS:Becomesunavailable:CRITICALBecomes available:HARMLESS toreset

Daemons:haemd, hagsd,hagsglsmd, hatsd,xntpd, sp_configd

Every five minutes

Daemon Status Availability monitorfor HACMP:Becomesunavailable:CRITICALBecomes available:HARMLESS toreset

Daemons:clstrmgr, clsmuxpd

Every five minutes


Remote Oservstatus

Threshold monitordistributed to theTMR server:Becomesunavailable:CRITICALBecomes available:HARMLESS toreset

All TME servers inthe environmentare monitored fromthe TMR server

Every 10 minutes

Remote Oservstatus

Threshold monitordistributed to allTME servers in theenvironment:Becomesunavailable:CRITICALBecomes available:HARMLESS toreset

All servers in thenetwork local to theTME server aremonitored by thisTME server.

Every 10 minutes



The following table (Table 18) shows an example of monitor definitions forTME monitoring.

Table 18. TME Monitors

Application status Availability monitor:Becomesunavailable:CRITICAL(including a Sentrynotice)Becomes available:HARMLESS toreset

Applications:All oracle-daemons

Every 15 minutes

Application status Availability monitor:Becomesunavailable:CRITICAL(including Sentrynotice)Becomes available:HARMLESS toreset

Applications:All TEC-daemons

Every 15 minutes


No of Oserv errors Threshold monitorIncrease by 15:CRITICAL

N/A Every 15 minutes

Tivoli DB DirSpace Threshold monitor<20Mb CRITICAL<40Mb WARNING>40MbHARMLESS toreset

N/A Every hour

Tivoli DB DirSpace Collect monitor N/A Every hour



The following table (Table 19) shows an example of monitor definitions for theOracle monitoring collection.

Table 19. Oracle Monitoring Collection

The following table (Table 20) shows an example of monitor definitions for theWindows NT monitoring collection (default monitoring).

Table 20. Windows NT Monitoring Collection: Default


Oracle TablespacePercent Spaceused

Threshold monitoron TEC OracleTablespace:>90% WARNING>98% CRITICAL<90% HARMLESSto reset

TEC_DATA_TS Every 1 hour


Collect monitor TEC_DATA_TS Every 1 hour


Threshold monitoron Inventory OracleTablespace:>90% WARNING>98% CRITICAL<90% HARMLESSto reset

TIVOLI_DATA_TS Every 1 hour


Collect monitor TIVOLI_DATA_TS Every 1 hour


Percent FreeSpace

Threshold monitoron Logical Disk>80% WARNING>90% CRITICAL<80% HARMLESSto reset

Logical Disk C: andD:

Every 10 minutes

Percent FreeSpace

Collect monitor onLogical Disk

Logical Disk C: andD:

Every hour


NT Service Status Availability monitoron defaultWindows-NTservices:Becomesunavailable:CRITICALBecomes available:HARMLESS toreset

Services:Computer Browser,TCP/IP NetBIOSHelper, TimeHelper, TivoliRemote ExecutionService,Workstation,EventLog, Alerter,McAfee TaskManager, McAfeeAlert Manager,Messenger, Plugand Play, RemoteProcedure Call(RPC) Service,Server,TECNTAdapter,ADSM CentralScheduler Service,Net Logon

Every five minutes

Paging File PercentUsage

Threshold monitoron Windows-NTpaging file:>80% WARNING>90% CRITICAL<60% HARMLESSto reset

Paging fileC:\pagefile.sys

Every five minutes

Paging File PercentUsage

Collect monitor onWindows-NTpaging file

Paging fileC:\pagefile.sys

Every 1 hour

Percent ProcessorTime

Collect monitor N/A Average during anhour

Interrupts/sec Collect monitor Processormonitored

Average during anhour

Disk Queue Length Collect monitor Logical Disk C: andD:

Average during anhour

Packets OutboundErrors

Collect monitor Network Interface 1 Average during anhour

Packets ReceivedErrors

Collect monitor Network Interface 1 Average during anhour



The following table (Table 21) shows an example of monitor definitions for theWindows NT monitoring collection (specific monitoring).

Table 21. Windows NT Monitoring Collection: Specific

Processor QueueLength

Collect monitor N/A Average during anhour


Percent FreeSpace

Threshold monitoron Logical Disk E:on all TME servers>80% WARNING>90% CRITICAL<80% HARMLESSto reset

Logical Disk E: Every 10 minutes

Percent FreeSpace

Collect monitor onall TME servers

Logical Disk E: Every hour

NT Service Status Availability monitoron Windows-NTADSM service onADSM servers:Becomesunavailable:CRITICALBecomes available:HARMLESS toreset

Service:ADSM Server

Every five minutes

NT Service Status Availability monitoron Windows-NTservices on:· AccountBDCs· ResourceBDCs

Becomesunavailable:CRITICALBecomes available:HARMLESS toreset

Services:KiXtart RPCService, DirectoryReplicator

Every five minutes



The following figure (Figure 122) also shows an example worksheet thatincludes the information about AIX errlog event definitions.

NT Service Status Availability monitoron Windows/NTservices on:· AccountPDCs· ResourcePDCs

Becomesunavailable:CRITICALBecomes available:HARMLESS toreset

Services:Spooler, NetfinitySupport Program,Quota Manager

Every five minutes



Figure 122. Example of a Worksheet for Event Source: AIX errlog

6.4.5 Scenario summaryThe scenario that we introduced is based on the event management by usingDistributed Monitoring and the Tivoli Enterprise Console. The following is thesummary of this scenario for each Tivoli application.


6.4.5.1 Tivoli Distributed MonitoringDistributed Monitoring allows remote system resources to be monitored. Arange of key measurements can be tested by using Tivoli DistributedMonitoring including measurements from user-provided scripts. The result ofthese measurements are tested against user-specified criteria. Based on theresults of the test, automation scripts can be invoked, operations notified, orevents forwarded to the Tivoli Enterprise Console. Control of all thesemeasurements and responses can be accomplished from a central console.Distributed Monitoring may also be used to collect performance informationfrom remote systems. This information can then be read into a suitableapplication to provide reports, graphs, and analysis of key system metrics.

6.4.5.2 Tivoli Enterprise ConsoleTEC provides an interface to the central event repository. A server portionacts as the collection point for events within the enterprise, which includesevents generated by the distributed monitoring components. As events arriveat the server, they are subjected to a rule based analysis to determine whataction, if any, should be taken. This action may, for example, include startingan automated response, merging events due to a single failure, and basing anaction on a timed result. Events are stored in a RDBMS event repository. TECuses event adapters to reside on the local machine whose resources arebeing 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 theevent repository. The view can be customized for a user or group of users toallow 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 theefficient 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 moneyworrying about security. Applications and, more importantly, data need to beprotected from unauthorized, and possibly illegal, access. However, whatorganizations sometimes over look is that unauthorized access can comefrom internal sources as well as external. There is concern about hackersaccessing data or systems, and to prevent this, complex security measuresare established to foil unauthorized external access. Meanwhile, internalaccess is merely handled by the issuing the correct user IDs and passwords.Sometimes, these User IDs are issued from different departments, each one


responsible for a particular section or application, or from a singledepartment, which is not fully aware of how the organization fits together.

Any organization today should implement security policies and proceduresthat aim to control security enterprise wide, on all levels, from the networkthrough applications to the end user. Tivoli solutions goes a long way inproviding enterprise wide management of security and resources, or moreimportantly, the security of resources.

In computing terms, an organization’s resources include:

• Hardware

• Software

• Data

All of these need be controlled and made secure in any organization. Theyneed to be allocated correctly, and access to them needs to be checked andcontrolled at an enterprise level, not at a departmental level. This is difficult toachieve in any organization; however, Tivoli provides a number of productsand solutions to make these necessary tasks easier and, most importantly,centralized. When designing any solution, the goals and targets must bedefined in advance. This means that the resources to be controlled must beidentified while at the same time identifying the security measures each onerequires. This is paramount; otherwise, any solution will not work effectively,and gaps and loopholes will be left, which can be exploited by internal andexternal sources.

6.5.2 Detailed scenarioAs stated in the previous section, an organization’s resources can be dividedinto three areas. Security in each of these areas needs to be addressedenterprise wide. The following are detailed descriptions of each area andsome of the problems faced in each one.

6.5.2.1 HardwareThe computing hardware in an organization can be split into different groupsthat can include both the computers themselves and the output devices andperipherals associated with them. For example, the following components canbe counted as computing hardware:

Servers RS/6000, OS/390, PC Servers

Workstations Dumb Terminals, X Stations, Power PCs, PCs

Printers All types and models


Security of an organization’s hardware has to be physical, whether it involveslocking machines in secure rooms, securing workstations to the floor, orinserting anti-theft devices, such as dye markers, into smaller componentsand peripherals. Therefore, a software security and resource managementsolution is not going to be of any use in actually preventing the theft ofhardware. However, if a security solution could prevent unauthorized accessto an organization’s data after it was stolen, by means of encryption, forexample, then it does make a software security solution a viable deterrentagainst the theft of hardware, at least in certain ways.

6.5.2.2 SoftwareSoftware resources can be anything from word processing applications, suchas Microsoft Word, right up to, and including, large ERP applications, such asSAP R/3. Most organizations standardize their software solutions onparticular 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 dataprocessing and management needs. Usually, though, a solution will fallsomewhere between the two. Day-to-day running of the core processes of theoperation will be handled by SAP R/3, but letters and e-mail will still behandled by solutions, such as those provided by Microsoft. The reason, ofcourse, is simple. No single application or suite of applications can doeverything.

Access to an organization’s software resources are controlled at a number ofdifferent 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 andpasswords that allow the relevant access to the required resources. Usually,these user IDs are issued from different departments, each responsible forthe control of a particular level. The IDs then have to be combined to provideaccess to the required resources. Sometimes, when logging on, users willhave to provide a user ID and relevant password to unlock the machine, thenthe same again to access the network and, finally, once more to access theapplication they need to work with.

This is not only time consuming, but sometimes difficult to manage. It canalso take a long time to correct when something goes wrong, which means


that staff are unable to work to full capacity while the relevant access methodis 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 relevantmachines and users. This would make changes and updates a lot simpler.Also, the solution would need to be centralized, thus, making theimplementation of user IDs and security requirements easier across theentire organization.

6.5.2.3 DataData can be catergorized as the large RDBMS systems used with products,such as SAP R/3, right down to the documents produced by theaforementioned word processing packages. All of this data needs to bestored, transmitted, and produced securely without unauthorized access,either external or internal.

Organizations rely on data stored in various applications and formats to runtheir business and keep them ahead of their competition. This informationneeds to be secure, and, for the most part, all of the measures put in place toensure 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 theapplication it was created in and locked in behind a wall of native security. Assoon as that data is removed or copied from the application, for printing ahard copy, for example, then it is no longer secure. At this point, it can beintercepted or printed in the wrong place and, therefore, be seen by peoplewho 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 anorganization’s network routing is not very reliable, then a document can beprinted in the wrong place. For example, if someone in Human Resourceswas to print confidential information, and it ended up being printed in theAccounts department, then it could be disaterous. The other problem thatplagues networks is data disappearing altogether. It doesn’t get printed forsome reason; however there is no way of telling why until it is not in theprinter when someone goes to look for it.

For data to be secure at all times while it is inside the computer network, thensecure and controllable output channels need to be created; and again, theseneed to be centrally managed for the solution to be successful.


6.5.3 Security and Resource Management Software solutionNow that the types of resources and the security they need have beenidentified, this section suggests which Tivoli solutions and products should beimplemented to provide the best security solution possible. What follows is alist of which Tivoli products should be implemented:


• Tivoli Security Management (Lockdown Modules)

• Tivoli User Administration

• Tivoli Global Sign-On

• Tivoli Output Manager

6.5.4 Solution implementationThe list in the previous section shows which Tivoli products and solutions areparticularly suited in providing a security and resource management scenariofor SAP R/3. The aim of this section is to explain, or suggest, the best ways toimplement them to provide an effective enterprise wide solution. Thefollowing is a description of the functions and benefits each piece of softwarewould bring to the overall solution.

6.5.4.1 Tivoli Global Enterprise ManagerTivoli Global Enterprise Manager is Tivoli’s solution for managing applicationsand systems from a business perspective. Once an application isinstrumented from Tivoli Global Enterprise Manager, Tivoli allowsmanagement of this component in the wider context of a business system.

Global Enterprise Manager provides an easy to use and effective GUI thatoperators can utilize to monitor and control the entire enterprise. It enablesthe arrangement and management of resources by viewing them as a wholeenterprise. This makes it much easier to manage even a large enterprise, asresources of all types can be arrange, manipulated, and viewed at randomwith little trouble. It also enables better management of the resources as awhole as problems can be spotted easily, as can security issues. Tivoli GlobalEnterprise Manager simplifies and streamlines the management of anyenterprise or business system making it easier and more efficient to manage.This give administrators more time to concentrate on defining andimplementing security and resource control policies and procedures.

6.5.4.2 Tivoli Security ManagementTivoli Security Management enables the management of security acrossdifferent platforms through the use of a role-based security model. With


role-based security, it is possible to determine what resources people haveaccess to based on the job tasks, or roles, that they need to perform. In TivoliSecurity Management, these resources can be of different types includingfiles, printers, applications, or TCP services. They can also reside on differentplatforms. This is useful, as SAP R/3 is naturally distributed across one ormore platform and involves a number of different components, all of whichneed identifying and then controlling. Resources can even reside on OS/390systems protected by the OS/390 RACF. This is especially useful inimplementations of SAP R/3 that use an OS/390 database system. TivoliSecurity Management enables the identification of all resources in theenterprise that are required to complete a particular task. Once this processhas been completed, the resources can be listed in a role and the relevantaccess rights given. It even means that individual files can be secured toprevent unauthorized access even if the machine that the file resides on isremoved from the network. Once roles have been identified, Tivoli securitygroups can be formed based around a job title. These groups can then begiven all the roles they need in that position.

This solution provides centralized management of both security andresources once it is configured. An administrator does not have to beconcerned with granting access to a user or resources of many different typeson many different systems. Instead, the administrator just adds the user tothe Tivoli Security group, and all the access rights are granted during the nextsecurity profile distribution. This is useful when an organization has a numberof SAP systems, as the correct access to each can be granted easily.

This solution means that the enterprise is better secured because loopholesare less likely to appear, and users will only get the resource access theyneed and no more, therefore, reducing the chances of data being accessedby the wrong people.

6.5.4.3 Lockdown ModulesThe purpose of a lockdown module is to provide a way of defining a securityprofile that can be easily altered, expanded, and, most importantly, be reusedin another location. Some lockdown modules are available ready-made forproducts, such as Windows NT, Lotus Domino, and SAP R/3. A lockdownmodule includes the definition of roles that provide the required level ofaccess to perform different tasks with the subject application or operatingsystem.

Lockdown modules enable the easy, enterprise wide management of systemsand applications. They provide specific Tivoli Security Profiles that can beeasily modified to match an environment, applied to an endpoint, and then


tested to lockdown a specific system or application. This again reduces thetime an administrator needs to manage a security solution and reduces therisk of loopholes and unauthorized access.

Lockdown Modules make Tivoli Security Management simpler and faster touse, whether the are developed within the organization or obtainedready-made. Tivoli Security Management address a number of the issues thatarise in a security management solution. It is centralized, covers a wide rangeof resources and platforms, and is an effective way of preventingunauthorized access, therefore, controlling day-to-day access to all types ofresources.

6.5.4.4 Tivoli User AdministrationTivoli User Administration extends the capabilities of the Tivoli environment toallow the management of user accounts on a number different platforms andapplications including SAP R/3.

Tivoli User Administration provides a network computing environment with anumber 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 consistentapproach to administrative policy definition. As said before, this reduces therisk of loopholes and makes the management of the security in a wholeenterprise a lot easier.

6.5.4.5 Tivoli Global-Sign OnTivoli Global Sign-On is a very useful product in large enterprises. It providesa secure and easy-to-use solution that grants users access to the computingresources they are authorized to use with just one logon. Much like TivoliOutput Manager, only Tivoli Global Sign-On deals primarily with applicationsand systems. It is designed for use in large organizations, which consist ofmultiple applications and systems, within heterogeneous, distributedcomputing environments. Global Sign-On removes the need for end-users tomanage multiple user IDs and passwords.


This means that problems where users are not able to access a particularresources because they have forgotten their password, or it has expired, arereduced. Also, because the whole process is centralized, it means that anyproblems a user may have can be identified and solved quickly so that littletime and productivity is lost over the correction and management of user IDsand passwords.

6.5.4.6 Tivoli Output ManagerTivoli Output Manager is a powerful tool for enterprise-wide output control. Itenables the coordination of routing paths, delivery, and, above all, security ofdata.

As stated previously, enterprise applications, such as SAP R/3, rely on theoutput environment to deliver critical reports to single users and managementteams. Usually, an enterprise output manager is responsible for orchestratingthe delivery of these reports according to the business rules that have beendefined. Tivoli Output Manager can perform the following tasks and providethe following benefits:

Centralized Output ManagementThis is very important. As stated previously, by centralizing all operations ofthis type, the chances of loopholes are reduced, and the overall solutionshould be more robust and coherent across the enterprise. The structure andoperation 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 networkor being printed to the wrong location.

Controlled Access of Output ResourcesBoth administrators and users are defined across all output resources forglobal policy adherence and consistency. These definitions are distributedand activated throughout the output network and are done by administratorswith the necessary security profile.

This means that users have to go through the relevant authorization layers touse the output network. This enables the use of user-to-user notifications andreliable access control of the resources in the output network.

It almost removes the risk of documents being printed to the wrong area, as auser in the Human Resources department would probably not have theauthority 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 beenpassed from R/3 onto the output network, it is easily accessible to anyone


with the relevant packet sniffing software. This is also applicable to mostapplication’s output; however, R/3 is not unique in this.

Routed Output ResourcesBecause Tivoli Output Manager is structured around a rule based foundation,it means that when certain resources are down, fault tolerant routing rulescan be used to still deliver and notify the appropriate people of the differentpath that was used. This is, of course, all calculated within the rules definedfor access to each resource type.

The rule engine can also respool and extract archive documents to outputresources if duplicates are detected. This is very useful for streamlining theoutput environment and prevents large reports from duplicating over slownetwork links between distribution centers.

Reliable and Secure Output ChannelsThe delivery path from the user’s workstation to the output resource is alwaysin an encrypted form. This means that data is secure, and even if packets areintercepted, then the data contained in them is useless. This feature isespecially useful for delivering data across the Internet safely and securely.

Tivoli Output Manager provides definitions for secure output resources. Thisallows the users to rely on the output network for delivery to all the securedevices if a particular device is off-line.

Automated Delivery ChannelsThis option of Tivoli Output Manager allows the definition of rules on certainoutput resources, for example, aggregate all printing from a certain printserver and archive the data onto disk.

Although, at first glance, this attribute seems inappropriate, when it comes toenterprise security and rerouting of output devices, it make sense. Withautomated delivery channels, you can track headers and apply audit rules toall or some of the output channels.

6.5.5 Scenario summaryThis scenario has hopefully demonstrated some important ways in whichTivoli solutions can be implemented to provide centralized and reliablesecurity and resource management. Security is a major issue in anyorganization and should never be overlooked or placed low down the list ofpriorities. However, this can happen sometimes, as solutions can beexpensive and difficult to implement and even more difficult to administer andkeep consistent after implementation. This need not be the case if Tivolisolutions are used and implemented correctly to manage the security of an


enterprise and its resources as a whole. It provides centralized control andadministration, support over a wide range of platforms and applications, andthe ability to secure all forms of data from unauthorized external or internalaccess.




Chapter 7. Examples of new features in SAP R/3 Management

Tivoli releases a variety of SAP R/3 management products to manage alarge-scale and complicated SAP R/3 systems environment efficiently. TivoliSAP R/3 management solutions are not only Tivoli Manager for R/3, but alsoother Tivoli products. This means that a customer can implement a variety ofSAP R/3 management solutions by using Tivoli for each specific systemsenvironment. Tivoli products line can be a powerful solution to manage SAPR/3 systems for all customers.

In Chapter 1, “Introduction” on page 1, we introduced the overview of eachTivoli product that manages the SAP R/3 environment. In this chapter, wefocus on the following new Tivoli products for managing SAP R/3 systems andintroduce more detailed information.

• Tivoli Application Performance Manager

• 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, itenables you to perform seamless management and operations.

7.1 Tivoli Application Performance Manager

The following sections detail the installation and configuration of the TivoliApplication Performance Manager (TAPM). TAPM was installed on a WindowsNT 4.0 server running an evaluation version of Sybase Adaptive ServerEnterprise 11.9.2. For more information on machine specifications andrequired Tivoli software, please refer to Chapter 3, “Our SAP R/3 Systemenvironment” on page 107.

TAPM consists of five main components, each of which needs to be installedor configured individually. The components are as follows:

The version of Tivoli Application Performance Manager used during thecourse of this redbook was a beta code version. Functions, features, andsupported environments for this product are subject to change withoutnotice any time before or after general release.

Note


Graphical User Interface (GUI)This is integrated into the Tivoli Desktop and can be launched and operatedfrom any machine that has the Tivoli Desktop installed. All setup and controlof the data gathering session is performed via the GUI. Selections and controlactions made at the GUI are checked for completeness and validity beforebeing translated automatically into system commands for local execution atthe Tivoli Management Server or for transmission to specified Endpoints orthe Endpoint Gateway.

TAPM Front-EndThis is located on the Tivoli Management Server and achieves the actualimplementation of the operations that are performed through the GUI. Inaddition, it implements a CLI to accomplish administrative tasks. CLIs are analternative method of controlling TAPM.

TAPM Back-EndThe TAPM Back-End resides in each active remote Endpoint that is to bemanaged by the TAPM application. The back-end relies and depends on theservices of the Tivoli Management Agent, and it is responsible for receivingrequests that are passed on to the TAPM engine. The back-end also carriescommunication from the engine to the Tivoli Management Server and theEndpoint Gateway.

TAPM EngineThis is the actual collector of application performance data. An engineresides on each Endpoint where the application performance must bemeasured. The engine receives data directly from the application through theapplication response measurement (ARM) interface. Data is then gatheredand aggregated in order to produce valuable information. The engine alsoreceives requests to perform management tasks from the TAPM back-endcomponent as a result of administrative operations issued at the managementserver.

Upcall CollectorThis resides at the Endpoint Gateway. It acts as a collector of data producedby the TAPM engines and is responsible for storing them in a centralizeddatabase.

The following diagram shows how the five components combine to providethe overall application performance management solution.


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 configuredwhen needed. The following sections detail the installation of TAPM and itsother components. The order of installation of the components is not inflexibleand can be changed a lot. However, for the purpose of our installation, thetasks 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

DatabaseUser Interface

Tivoli ManagementServer

TAPM Front-End

Tivoli ManagementAgent (Endpoint)

TAPM Back-End

TAPMEngine

Applications

Tivoli ManagementGateway

Upcall Collector

Engineresponses

Profile pushand CLIs

Datacollectionupload

Recordupload

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 TivoliFramework is installed. However, it will not be fully configured until TAPM isinstalled. The previously ordered listed only shows the steps we took to installTAPM and is not a recommended installation method.

7.2.1 Installation and configuration of TAPMOnce the installation of the Tivoli Management Framework and DistributedMonitoring had been completed on the POKIBMTAPM machine, the followingTAPM components were then installed using the Software Installation Service(SIS):

• Tivoli Manager for Application Performance Monitor ComponentVersion 1.0

• Tivoli Manager for Application Performance Server Component

7.2.1.1 Adding the Notice Group to the AdministratorThe first task is to add the TAPM Notice Group to the Tivoli Administrator sothat notices will be received and viewable if anything goes wrong in thefollowing configuration steps or when TAPM is fully configuring and runningunder normal operation. The following figure briefly shows how to add theNotice Group to the Tivoli Administrator:


Figure 124. Adding the TAPM Notice Group to the Administrator

7.2.1.2 Adding the new monitoring profile to the policy regionThe next important task is to add the new monitoring profile, known as theMarProfile, to the managed resources of any existing policy regions. Thefollowing figure shows how to do this.


Figure 125. Adding Marprofile to the pokibmtapm Policy Region

Once this task is completed, it is suggested that a separate Policy Region iscreated 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 alsoneeds to have MarProfile added to its managed resources.

The next step is to create a Profile Manager in the new Policy Region. Thefollowing figure shows how to achieve this.


Figure 126. Creating a TAPM Profile Manager

We gave this Profile Manager the name tot16, as this was one of theEndpoints that we were going to use to measure application performance.Please note that the Dataless Endpoint Mode check box must be selected toallow the rights to distribute to Endpoints.

7.2.1.3 Registering applicationsAny applications that are to be monitored must first be declared to the TAPMregistry. This is a once only operation. Once an application has beenregistered, you do not need to repeat this task in the future. This task can beperformed 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 batchfile. For example, to register the SAPGUI application, we typed thecommand line:

wmarregapp -a sapgui.exe


2. Step 1 must then be repeated for all the applications that need registering,then Step 3 shows how to register API instrumented applications andsimulation 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 havebeen registered.

7.2.1.4 Creating monitoring profilesAfter all the applications have been registered, the next step is to create amonitoring profile for any applications that need to be monitored. Thefollowing figure shows how to create the blank monitoring profile.

Figure 127. Creating a Blank Monitoring Profile


When creating a TAPM profile, the MarProfile must be selected, assuming ithas been added to the Managed Resources of the Policy Region as shown inFigure 125 on page 276.

The profile has now been created and is identified by the special TAPM profileicon.

It is now necessary to add into the profile which applications are tobe monitored before it is distributed to the relevant Endpoints. The followingfigure illustrates how to do this:

Figure 128. Adding Applications to a Profile

Before an application can actually be added for monitoring, it must first begiven a schedule of when to run and collect data. This is achieved by


selecting the application required and clicking the Schedule button. This willgive 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 datecannot be less than the current date, and the end date must be more than thecurrent date.

The collection interval can be set in increments of ten minutes, starting fromten and going up 60 minutes, or once an hour. For the schedule to beaccepted, it must include at least one scheduling rule. To add a schedulingrule, click the New Rule button and fill in the schedule as shown in thefollowing figure:


Figure 130. Adding a Monitoring Rule to a Schedule

Once the schedule has been completely defined, click the Add & Closebutton in the main schedule dialog as shown in Figure 129 on page 280. Thiswill 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. Thedatabase settings are found on the Add Entry to the Profile dialog as seen inFigure 128 on page 279. Clicking the Database Settings button will producean dialog as follows:


Figure 131. Database Settings Dialog

The default settings are as shown in Figure 131. Change them to any desiredvalues and then click Add & Close to apply those settings. It is important toremember that the greater the level of detail selected, the faster the databasewill grow in size.

The final act is to click the Add & Close button on the Add Entry to the Profiledialog as shown in Figure 128 on page 279. This will cause the ApplicationAvailability Profile dialog to be displayed again. It should now look somethinglike as follows:


Figure 132. Application Added to Application Availability Profile

Clicking on the Enable and Disable buttons will allow the activation anddeactivation of individual monitoring profiles. The final act in creating theprofile is to close this dialog by selecting Profile and then Close.

7.2.1.5 Adding subscribers and distributing the monitoring profileThe final two actions that need to be taken before the profiles actuallybecome active, is to add subscribers for the profile and then distribute it tothose subscribers. Adding subscribers is achieved as shown in the followingdiagram:


Figure 133. Adding Subscribers to the Profile

Once all the desired subscribers have been selected, click the SetSubscriptions & Close button to apply those subscribers.

The final task is to distribute the profile to relevant Endpoints. This isachieved as demonstrated in the following figure:


Figure 134. Distributing the Monitoring Profile

This will cause the profile created about to be distributed to the specifiedEndpoints. Monitoring will begin immediately; however, as specified above,data will only be upload to the database once every day. The default time ismidnight.

7.2.1.6 Installation of Sybase Adaptive Server EnterpriseThe next step we performed was the installation of Sybase Adaptive ServerEnterprise 11.9.2. This was an evaluation copy downloaded from the SybaseWeb site on a limited license. We then created a database called tapm_db onour Sybase server and changed the sa users password to be tapmtapm. Fordetailed instructions of how to install Sybase and create a new database,please see the relevant Sybase documentation and manuals.

Click this button todistribute the profile

All the commands examples in the following section were executed from abash shell.

Note


The next step was to create the RDBMS Interface Module (RIM) object sothat TAPM could communicate with the database and configure it. The formatof the command to create a RIM object is as follows:

wrcrtrim [-i] [-v vendor] [-h hostname | -o host_oid] [-d database] [-uuser] [-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

Therefore, the format of our wrcrtrim command was:

wcrtrim -i -v Sybase -h pokibmtapm -d tapm_db -u sa -H d:\Sybase -spokibmtapm tapm

This command created the RIM object, and we verified the correct creation bytyping:

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 nextstep was to run the database configuration script.

wcrtrim Parameter Value

Vendor Sybase

Hostname pokibmtapm

Database tapm_db

User sa

RDBMS Home d:\Sybase

Server ID pokibmtapm

rim_name tapm


The configuration of the database is achieved by the use of a script that canbe found in the directory listed in the information box above. To execute thescript, type the following command:

./cr_tapm_db.sh

This script is mostly automatic. It tries to retrieve the RIM object attributesand, if successful, configures the database. However, under certaincircumstances and configurations, it may be necessary to provide it with extrainformation. For more detailed information on how to install and configure aTAPM database, please refer to the relevant documentation.

The script creates a number of tables in the TAPM database. The followingscreenshot 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 WinrunnerWinrunner-Quicktest for R/3 is a software testing tool optimized for testingR/3 systems. Quicktest for R/3 launches the SAPGUI and records the userinteraction with the client. It allows the recording of interaction with the R/3client software. This can then be played back with many sets of data to verifythe business logic.

Although we created our RIM object manually, there is a script that can beused to help with this process. It attempts to get RIM object attributes. Anythat it cannot discover, the user is prompted to enter.

The script can be found in $BINDIR/TME/MAR/SQL directory and can beexecuted by typing:

./cr_tapm_rim.sh

Information


Installation of Winrunner-Quicktest for R/3 is straightforward. Run the setupprogram from the TAPM CD-ROM. Once installed, start the program byselecting it from the Windows Start Menu. It should start with a user interfacethat 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 thisproduct. The first step is to actually decide what business processes are to besimulated. For the purpose of this project, we decided to use a simple set offunctions that an administrator might perform to check the system in themorning. This was just to test the functionality of TAPM itself. Winrunner willallow the complete simulation of business processes. It will even simulate theentry of different sorts of data from prepared data files. For the purpose ofthis test, we decided to simulate the following:

• Logon

• Checking batch processing (sm37)

• Checking the system log (sm21)

• Checking the application servers (sm51)


• Log off

To create a basic test case in Winrunner is easy. All that is required is that anew 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 thisprocess. 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 beseen in Figure 137 just below the R/3 Connect step. Adding this step is


achieved in the same way. The only difference is in the values that need to beentered.

To record another business process, it is necessary to add another blankbusiness process to the test case. This one was renamed sm37, as this wasthe transaction that was used for this step. The recording of user interaction issimple. Once a step has been created, a user just needs to press the recordbutton.

Then, return to a running SAP session and execute the steps that are to berecorded. For example we recorded the following for this step from the initialGUI 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:


Figure 138. sm37 Step From Winrunner Testcase

The processes detailed previously has to be repeated for each businessprocess 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 allthe 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 withWinrunner 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 thetest case is saved. This registered the VUS and meant that it could then beadded to a TAPM profile for distribution to the Endpoints. When adding asimulation script to a profile by the process shown in Figure 128 on page 279,the Simulation Settings button will become available. Clicking this button willproduce a dialog box as follows:


Figure 139. Simulation Settings Dialog Box

This dialog allows the setting of a Simulation Interval, that is, how often thescript will be run during the pre-defined monitoring periods. Set the desiredinterval time and click the Add & Close button to save this information.

Once the distribution has been completed, it can be found on the Endpoints inthe C:\tivoli\lcf\dat\1\Mar\vus directory as a tar file.

7.2.1.8 Installing Loadrunner on an EndpointFor any virtual user script to execute successfully, a program calledLoadrunner must be installed on each Endpoint that is going to run the virtualuser script. Loadrunner can be found in the Loadrunner directory on theTAPM CD-ROM. Run the setup program to install this program.

7.2.1.9 Final notes on TAPMOnce all the above steps have been completed, the monitoring of the SAPR/3 application performance should be possible. As stated before, datacollected 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 onthe Endpoint. This data can then be accessed by Tivoli Decision Support toprovide accurate data for the defining of service levels, availability profiles,and, of course, performance.


7.3 Tivoli Decision Support for SAP R/3

Tivoli Decision Support (TDS) provides a powerful mechanism to aid its usersto dive into complex database structures and to explore them in differentscopes, levels of details, and from different perspectives. It also allows itsusers related data in multiple dimensions. Collectively, these features enablethem to gain a deeper understanding of, and insight into, the relationshipbetween the data stored in different systems that affect the businessoperation 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 theinformation needs of different users for conducting analyses and decisionmaking from technical analysts through line managers to executives.

Finally, Tivoli Decision Support handles the delivery of, and access to, thedata. It facilitates knowledge discovery and user access to information. Datacollected can be shared with others in the organization using deliverymechanisms including hard-copy printouts, files, and push content. In thelatter case, content that has been collected by one user can be sent to acentral repository on a company’s intranet from which other users can gainaccess to the content.

7.3.1 Tivoli Decision Support componentsTivoli 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 forusing the TDS Discovery Guides. The base product is composed by thefollowing 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 intospecialized categories. Each category contains a series of topics that


correspond to the different aspects of that category. Each topic contains anumber of views that are associated with the data elements being examined.

Tivoli Decision Support uses the TDS Discovery Guides to aid in discoveringkey information. With this information, Decision Support becomes a powerfulend-user solution. This solution provides users with a comprehensive set ofviews into their enterprise’s data.

Figure 140 shows the relationship between the Tivoli Decision Support BaseProduct and 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 frequentlyannouncing availability of new Discovery Guides, please refer to

http://www.tivoli.com

for the latest information of Discovery Guide availability. In this redbook, wewill describe in more detail the Tivoli Decision Support for SAP R/3.

7.3.2 Supported platformsThe following are the platforms supported by Tivoli Decision Support:

Tivoli Decision Support Discovery Guides:


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 architectureTypically, Tivoli Decision Support is implemented in network mode. A networkmode installation makes it possible for multiple users to access TDS in thevarious areas of the enterprise.

TDS Discovery Interface and Cognos PowerPlay are installed on the clientmachines. The client also requires the installation of both the Client Databaseand the ODBC Driver in order to have access to the data stored in thedatabase server.

The TDS Server component is installed on a file server that the clientmachines have access to a shared drive that will contain all the informationneeded to retrieve the reports.

A separate machine is used as the administrator system where the TDSDiscovery Administrator module is installed along with Cognos PowerPlay.The Administrator system should access the shared drive in the TDS FileServer. In addition, it also requires the database client and the ODBC driverin order to have a connection to the database. The Discovery Administratorhas access to the database in order to gather and maintain all the data usedby Decision Support. The Discover Administrator can be customized toautomatically gather the data, which are stored into special files called Cubes(that is, populates this special file with current data from your organization’sdatabases), at pre-defined intervals or enables you to perform suchoperations manually. The Cube files created by the Discovery Administratorare stored on the TDS File server.

The diagram in Figure 141 shows the Tivoli Decision Support Architecture inthe network mode.


Figure 141. TDS Architecture Diagram

7.3.4 Tivoli Decision Support work flowWe can generalize the TDS functionality in three basic steps:

Data CollectionIn this step, TDS Discovery Administrator performs a pre-defined set of SQLqueries against the Tivoli product database collecting the data. It is donethrough an ODBC connection. The resulting data is exported and stored intocomma separated value (csv) files. Exporting may also include calculation toadd value to the data.

Cube BuildingIn this step, TDS Discovery Administrator calls the Cognos PowerPlayTransformer to calculate and aggregate the values according to theTransformer model and build the Powerplay Cube. Each Discovery Guideinstalls its Transformer model(s) to the TDS File Server during installation.Transformer loads the model from the TDS File Server while building theCubes. The Cube building process may be scheduled to off hours, especiallyworking with large databases, since it may take considerable workload tocomplete.

Data PresentationThe data is presented through a topic-specific navigation aid by means ofrelevant business questions on the TDS Discovery Interface. The user can do

File server runningserver components

including guides,cubes and models

System runningAdministrator and client

Enterprisedatabase system

ODBC

Client systemrunning Discovery

Interface


Interface


Interface

Shared File Access

INVENTORY

DM

TEC

DATABASES

ODBC


multi-dimensional interactive analysis, such as slice, dice, drill up/down, orfilter, as well as other functions on the presented data. An important point toconsider is that the data can be historical or online. For historical data, TDSuses the Cubes to present the data while, for online data, Crystal Reports isused. Therefore, the database client and an ODBC connection is required toexist in the TDS Discovery Interface workstations.

7.3.5 Tivoli Decision Support for SAP R/3The Tivoli Decision Support for SAP R/3 allows data collected from the R/3servers and R/3 system activity to be displayed into reports responding to acustomer’s need to identify trends and predict future demands on a system’sresources and by helping them to make decisions on their SAP R/3environment. This corresponds to the need of a customer and serviceprovider to be able to monitor the systems performance against a ServiceLevel Agreement (SLA).

The purpose of this Discovery Guide is to supply data to help plan the R/3resource’s growth. Most of the performance problems are results of systemworkload gradually growing to the point where it exceeds the capacity of thesystems or because soft errors gradually increase in volume until acatastrophic hard error occurs.

Based on the numbers of variables involved in deciding what systems tomonitor, dates and times to retrieve data, the variations in SLA values, and inorder to extract data from the database repository, TDS for SAP R/3 makesuse of a tool called R/3 Collector. The R/3 Collector is a Windows NT-basedtool that allows the input of the necessary information required to retrievedata from each server that the analysis is required. It also allows the input ofthe necessary information to exclude transactions, programs, or user IDs thatare 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 reportsthat address issues, such as performance, service level agreement, serverworkload, and transaction tuning.

Tivoli Decision Support for SAP R/3 was a work-in-progress during thisproject. The features and functions described in the following section aresubject to change without notice any time before or after general release.

Note


• Presenting transaction and dialog information.

• Automated data gathering.

7.3.6 TDS for SAP R/3 Cubes and Related ReportsA PowerCube contains data organized in dimensions and measures. TheTDS for SAP R/3 provides cubes which contain queries (refer to the Figure142). Each query creates a comma separated value (.csv) data file for theCognos Transformer, and the resulting .cvs files are used by the Cognosmodel to build a PowerCube. Each of the queries extracts data from therelational database through an ODBC driver. R/3 Guide cubes includes thefollowing information.

Figure 142. Cubes and related reports

R/3 Performance Trends Provides information to identifytrends in system performance,including drill-downs to serversin a system and transactionsprocessed on the servers.

R/3 Load Balance Analysis Provides information about howmuch load is placed on eachsystem. This cube helpsdetermine which users areconsuming the most resources


and what transactions they areprocessing.

R/3 Capacity Planning Analysis Provides information to assist incapacity planning. The cubeallows drill-down into server andtransaction values to identifytrends in dialog volumes. Thiscube allows administrators todetermine if additional capacityis needed for increased userdemand.

R/3 Workload Type Analysis Provides information aboutdialog performance over time.

R/3 Transaction Performance Provides information abouttransaction and programperformance.

R/3 Transaction Response Components Provides a breakdown oftransaction response time intobase components of CPU time,database time, and other time.The cube provides informationon transactions that are wellbalanced, or are database orCPU intensive.

R/3 Service Level Agreement Provides information aboutwhether the Service LevelAgreement is met or missed.

7.3.7 Examples of using TDS for SAP R/3 AnalysisIn this section, we introduce some examples of using Tivoli Decision Supportfor SAP R/3.

Example 1The following chart (Figure 143) shows R/3 load balance analysis. This is ahelpful view for determining which systems and servers are busy.


Figure 143. Example 1: R/3 load balance analysis

Example 2The line chart (Figure 144) displays the percentage of dialog steps that areless than the dialog response time entered in the TDS for R/3 CollectorService Level Agreement configuration section. This chart displays eachsystem as a different line with data points being taken each day.


Figure 144. Example 2: R/3 Service Level Agreement

Example 3The following report (Figure 145) shows each transaction code by averageresponse time.


Figure 145. Example 3: R/3 response time

Example 4The following chart (Figure 146) shows R/3 load balance analysis. In thischart, we focus on the data of 1999/09/21.



Example 5As you can see, the following chart (Figure 147) shows the data of1999/09/21 by servers.



7.4 Tivoli Global Enterprise Manager

Tivoli Global Enterprise Manager (GEM) plays a vital role in Tivoli solutionsfor application management, for example, SAP R/3 or database. Tivoli GEMnot 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 willimprove your application management dramatically, especially SAP R/3management.

In this section, we introduce the overview of Tivoli GEM, how to configureTivoli GEM for managing SAP R/3 systems, and how Tivoli GEM works withSAP R/3 managed resources.


7.4.1 Overview of Tivoli GEMTivoli GEM consists of at least four different components, and each TivoliGEM component plays the following role:

Tivoli GEM Console Enables you to monitor, manage, and controlyour business systems and applications. TivoliGEM Console GUI is based on Java interface,and it is user-friendly.

Tivoli GEM Server Interacts with instrumented businesscomponents, for example, SAP R/3, for thedistributed environment through TivoliManagement Framework. It providesinformation for display on the Tivoli GEMConsole. The Tivoli GEM Server receivesheartbeat events from instrumented businesscomponents and determines the businesssystem in which a component belongs. It alsoqueries the instrumented businesscomponents for related business componentsand for the status of its monitors.

Tivoli GEM Instrumentation Provides information about the specificapplications (for example, SAP R/3), systemsoftware, or components to a managementsystem, such as Tivoli GEM. You caninstrument either a business system orstand-alone application.

Event Enablement Is installed on the TEC server. It enables TECto forward events to, and receive events from,the server. Event enablement defines eventclasses and rules for handling TivoliGEM-related events.

These Tivoli GEM components work interactively (refer to Figure 148).


Figure 148. The Interactions between Tivoli GEM Components

In the following sections, we introduce the installation and configurationprocesses for each Tivoli GEM component and how it works.

7.4.2 Installing Tivoli GEM for SAP R/3 managementThe installation processes of Tivoli GEM are complicated because Tivoli GEMconsists of many components, and Tivoli GEM GUI is based on a Javainterface. Before installing Tivoli GEM components, you need to install theJava 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 planningThe installation procedures of Tivoli GEM depend on whether your R/3system is configured on TMA or not. In this redbook, we introduce the TivoliGEM configurations with TMA. In case of configuring your R/3 system with

Tivoli GEMServer TEC Server

Tivoli GEMConsole

Tivoli GEMConsole

Tivoli GEMConsole

Events

SAP R/3 Server

Tasks Events


TMA, each Tivoli GEM component contains the following software (refer toFigure 149):

Figure 149. Software Configurations on Each Tivoli GEM Component

The following table (Table 23) shows detailed information about the softwareconfigurations for the Tivoli GEM environment.

Table 23. Tivoli GEM Software Configurations

Tivoli GEMComponent

Required Software Version

Tivoli GEM Console Tivoli GEM Topology Console 2.2.1

Java Development Kit 1.1.7

Tivoli GEM Server Tivoli GEM Topology Server 2.2.1

Tivoli Framework 3.6.1

Tivoli GEM Instrumentationfor Tivoli Manager for R/3

+TEC ACF

+Software Distribution

+Framework

Java+

TEC ACF+

Software Distribution(Gateway Module)

+Distributed Monitoring

+Framework

Tivoli GEMTopology Server

+Framework

Tivoli GEMTopology Console

+Java

TEC ServerTivoli GEM

Console

Events

TasksEvents

SAP R/3 Server

downcall upcall

Java

Tivoli GEMEvent Enablement

+TEC Server

+Distributed Monitoring

+Framework

TMR ServerTivoli GEM

Server

Managed Node

Managed Node(Endpoint Gateway)

Endpoint

TMR Server

Managed Node


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/3properly.

As you can see, each component of Tivoli GEM requires many prerequisitesincluding non-Tivoli modules; so, the installation processes of Tivoli GEMenvironment is a bit complicated. In this project, we installed each Tivoli GEMcomponent 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 forR/3.

TEC Event Server Tivoli GEM Event Enablement 2.2.1

TEC Event Server 3.6.1

Distributed Monitoring 3.6.1


Endpoint Gateway Java Development Kit 1.1.7

TEC Adapter Configuration Facility 3.6.1

Software Distribution 3.6.1

Distributed Monitoring 3.6.1


Endpoint Java Development Kit 1.1.7

Tivoli Management Agent (lcfd daemon) 3.6.1

TMR Server Tivoli GEM Instrumentation for Manager for R/3 2.0

TEC Adapter Configuration Facility 3.6.1

Software Distribution 3.6.1


Tivoli GEMComponent

Required Software Version


The following sections introduce the overview of each software installation.

7.4.2.2 Java Development Kit installationTivoli GEM implements Java interfaces. Therefore, when you configure TivoliGEM, 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 JDKfrom 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 toFigure 150):

Since our Version 2.0 of Tivoli Manager for R/3 environment has beenalready completed, we are not going to explain installation andconfiguration related to the R/3 Manager in this chapter.

Note


Figure 150. Downloading Java Development Kit

At the download page, you can download the latest version of JDK. The JDKis provided for each platform; so, you need to download the appropriate JDK.

After downloading JDK, you install JDK on each Tivoli GEM component thatyou 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 installationThe Tivoli GEM Topology Server provides the main engine of Tivoli GEM. Aswe mentioned, the Tivoli GEM Server is required to be installed in thefollowing Tivoli GEM component.

When you use the IBM Java Web site that we introduced, you need toregister your information before downloading. Then, you will be able to getthe user ID for accessing the Web page. This registration process will takeapproximately one day.

Note


• Tivoli GEM Topology Server

The Tivoli GEM Server must be a Managed Node. In this project, weconfigured the Tivoli GEM Server on the Windows NT Managed Node. Theinstallation process is quite simple. You install the Tivoli GEM TopologyServer 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 GEMinstallation CD-ROM. If you complete the installation successfully, thefollowing messages are displayed (refer to Figure 152):


Figure 152. Tivoli GEM Topology Server Installation Completion

7.4.2.4 Tivoli GEM Event Enablement installationTo communicate with the TEC server, Tivoli GEM provides the Tivoli GEMEvent Enablement module. As we mentioned, the Tivoli GEM EventEnablement 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 TivoliGEM installation CD-ROM. The Tivoli GEM Event Enablement can also beinstalled by using Tivoli Desktop as follows (refer to Figure 153):


Figure 153. Tivoli GEM Event Enablement Installation

If you complete the installation successfully, the following messages aredisplayed (refer to Figure 154):


Figure 154. Tivoli GEM Event Enablement Installation Completion

7.4.2.5 Tivoli GEM Topology Console installationTo display or control your SAP R/3 systems environment, Tivoli GEM providesa Java based GUI (Tivoli GEM Topology Console module). It is a rathersophisticated and user-friendly GUI. As we mentioned, you can configure theTivoli GEM Console on the following platforms even if the system does notjoin the TMR.

• AIX 4.1.5 or later

• HP-UX 10.20

• OS/2 Warp 4

• Windows 95

• Windows 98


• Windows NT 4

• Sun Solaris 2.6

In this project, we configured Tivoli GEM Console on the Tivoli GEM Servermachine. You can find the Tivoli GEM Topology Console V2.2.1 module in theTivoli GEM installation CD-ROM. The Tivoli GEM Console can also beinstalled by using Tivoli Desktop (for Managed Nodes) or by usingInstallSheld (for non Managed Node). The following figure (Figure 155) showsthe Tivoli GEM Topology Console installation screen on Tivoli Desktop.

Figure 155. Tivoli GEM Topology Console Installation



Figure 156. Tivoli GEM Topology Console Installation Completion

Once you complete the Tivoli GEM Console installation, you can find theTivoli GEM Console icon on Tivoli Desktop as follows (refer to Figure 157).


Figure 157. Tivoli GEM Topology Console Icon

7.4.2.6 Tivoli GEM Instrumentation for R/3 Manager installationTivoli GEM Instrumentation for R/3 Manager provides information about SAPR/3 applications. Tivoli GEM Instrumentation plays a vital role in SAP R/3application management. As we mentioned, the Tivoli GEM Instrumentationfor R/3 Manager module is required to be installed in the following Tivoli GEMcomponent:

• TMR Server

You can find the Tivoli GEM Instrumentation for Tivoli Manager for R/3 V2.0module in the Tivoli Manager for R/3 V2.0 installation CD-ROM. The TivoliGEM Instrumentation for R/3 Manager can also be installed by using TivoliDesktop as follows (refer to Figure 158):


Figure 158. Tivoli GEM Instrumentation for R/3 Manager Installation



Figure 159. Tivoli GEM Instrumentation for R/3 Manager Installation Completion

Once you complete the Tivoli GEM Instrumentation for R/3 Managerinstallation, you can find the new policy region and three new task librariesthat are contained in the new sub-policy region in Tivoli Desktop as follows(refer to Figure 160):


Figure 160. Instrumentation Task Libraries

These task libraries are used for Tivoli GEM operations. The followingsections introduce the configuration processes of Tivoli GEM.

7.4.3 Configuring Tivoli GEM for SAP R/3 managementTo 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 littlecomplicated. In this project, we configured the Tivoli GEM environment in thefollowing order:


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.

The following sections introduce the overview of each configuration process.

7.4.3.1 Configuring TEC Event ServerTo import the TEC new classes and rules, you need to run the ConfigureEvent Console task that is provided by the Tivoli Manager for R/3. When youuse Tivoli GEM for managing your SAP R/3 systems by using Tivoli GEMInstrumentation for R/3 Manager, this configuration is necessary to includeadditional R/3 Manager Instrumentation event classes and rules(sap_gemevents.rls) in the TEC rule base even if you have already configuredTEC Event Server for R/3 Manager. The Tivoli GEM Instrumentation for R/3Manager rule file (sap_gemevents.rls) includes TEC rules that forward all R/3Manager 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).

This configuration order is just an example, and you can change this order.However, some configurations must be done before the specificconfiguration. Therefore, if you do not have a special reason, werecommend you follow this order.

Note


Figure 161. Configuring TEC Event Console

Then, the additional event classes and rules for Tivoli GEM Instrumentationfor R/3 Manager (sap_gemevents.rls) are imported and updated in the TECrule base.

7.4.3.2 Configuring Event EnablementAfter Tivoli GEM Instrumentation for R/3 Manager is installed, you need toconfigure the workstation environment for use with instrumented businesscomponents on the Tivoli GEM Server. To do this, you need to perform thefollowing processes on the Tivoli GEM Server.

1. To update the TEC rules and event classes for event enablement, run theihsttec.sh script that is located in the following directories:

• %BINDIR%\TDS\EventService (for Windows NT)

• $BINDIR/TDS/EventService (for UNIX)


To forward events to one or more servers, edit the ihsttec.cfg file to specifythe 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 isinstalled.

7.4.3.3 Setting up the Tivoli GEM Console user accountsTo log in to the Tivoli GEM Console, the user ID and password must bedefined on the machine where the Tivoli GEM Server is running. The TivoliGEM 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 withadministrator access. If the user ID belongs to the user group, you cannot login with administrator access.

In this project, we configured the Tivoli GEM Server on the Windows NTmachine; therefore, we created and configured the tsadmn and tsuser usergroup on Tivoli GEM Server by using the Windows NT User Manager utility asfollows:

1. Create the Tivoli GEM user groups:

• tsadmn

• tsuser

Figure 162. Creating Tivoli GEM Console User Group


2. Create users for Tivoli GEM Console operations.

3. Add the users to the tsadnm and tsuser user groups.

7.4.3.4 Configuring the Windows NT serviceTo 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. Todo 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. Ifthe account belongs to the local domain, you can specify.\UserName.

password The corresponding password for the specifiedaccount_name.

After performing this operation, the Tivoli GEM Server process is installed astwo Windows NT services. These are the server and the topologycommunications server. Then the startup option is set manually. Therefore, tostart the Tivoli GEM Server process (server and topology communicationsserver) automatically each time the Tivoli GEM Server machine is rebooted,you need to change the startup option from manual to automatic by using theWindows NT service control applet.

7.4.3.5 Importing the BDF, CDF and Icon filesAt this point, you will be able to open the Tivoli GEM Console on eachmachine that the Tivoli GEM Topology Console is set up on. Tivoli Manager

In this configuration, you can configure the already existing user as a TivoliGEM Console user. For example, you can configure Administrator user asa Tivoli GEM Console user on Windows NT system.

Note

When you need to remove the service related to the Tivoli GEM Server(server and topology communications server), you can use the followingcommand that is contained in the %BINDIR%\TDS\server\bin directory:

service delete

Note


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 importthe BDF, CDF, and icon files, you need to load the application managementpackage (AMP) file.

To do this, select File -> New AMP on the Tivoli GEM Console (refer to Figure163). Then, specify the AMP file name (\GEMFILES\sapr3.pkg) in the R/3Manager installation CD-ROM.

Figure 163. Importing Application Management Package File

7.4.3.6 Setting up the Tivoli GEM heartbeatTo monitor up-to-date status of your SAP R/3 systems, you need to set up theTivoli GEM heartbeat. To set up the Tivoli GEM heartbeat, you need to runthe Send GEM Heartbeat task (refer to Figure 164) that is provided by TivoliManager for R/3.

New AMP


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.


Figure 165. Executing the Send GEM Heartbeat Task

As you can see, to monitor the up-to-date status of all SAP R3 managedresources, we specified all SAP R/3 managed resources (R3System,R3AppServer, and R3DBServer) as the target of the task. As a result, theTivoli GEM heartbeat will be performed to all SAP R/3 managed resources inthe TMR. If the task is completed successfully, the following messages aredisplayed (refer to Figure 166).


Figure 166. The Send GEM Heartbeat Task Completion

You can also confirm the setting of the Tivoli GEM heartbeat on the TECconsole as follows (refer to Figure 167).


Figure 167. TEC Events of the Send GEM Heartbeat Tasks

7.4.4 Using Tivoli GEM for SAP R/3 managementAt this point, your Tivoli GEM environment should work fine. Therefore, in thissection, we introduce some tips on the SAP R/3 management by using TivoliGEM.

When you do not run the Send GEM Heartbeat task on the specified SAPR/3 managed resource, the SAP R/3 managed resource may be displayedas unknown status on the Tivoli GEM Console because there is no way tomonitor the up-to-date status of that SAP R/3 managed resource. To avoidthis situation, we recommend you to run the Send GEM Heartbeat task onall SAP R/3 managed resources in your management environment. We willintroduce the unknown status in “Using Tivoli GEM for SAP R/3management” on page 329.

Note


7.4.4.1 Starting Tivoli GEM ConsoleFirst of all, you need to start the Tivoli GEM Console on the machine that theTivoli GEM Topology Console is installed. When you start the Tivoli GEMConsole, the following Tivoli GEM sign on screen will be displayed (refer toFigure 168).

Figure 168. Tivoli GEM Console Sign On Screen

Therefore, you need to enter the appropriate information (user ID andpassword) that you defined in the Tivoli GEM configuration processes. Then,the following screen (refer to Figure 169) will be displayed if the user ID andpassword are correct.


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 projectbusiness system prior to instrumentation. It also enables you toaccess the Tivoli Module Designer.

Build This function enables you to access the Tivoli Module Builder.

Verify After completing the instrumentation of your business system, youcan use this verify function to view your business system anddetermine whether it has been defined properly and meets yourexpectations.

Control This function enables you to view and manage the businesssystem.

The screens of each function are as follows:


Plan Mode ScreenThe following figure (Figure 170) shows the screen that appears when youchoose the plan mode in the life cycle toolbar.

Figure 170. The Plan Mode Screen of Tivoli GEM Console

Verify Mode ScreenThe following figure (Figure 171) shows the screen that appears when youchoose the verify mode in the life cycle toolbar.


Figure 171. The Verify Mode Screen of Tivoli GEM Console

Control Mode ScreenThe following figure (Figure 172) shows the screen that appears when youchoose the control mode in the life cycle toolbar.


Figure 172. The Control Mode Screen of Tivoli GEM Console

To monitor or control your SAP R/3 managed systems, normally you use thecontrol mode screen. The following sections introduce how you can managethe SAP R/3 managed systems by using the control functions of Tivoli GEM.

7.4.4.2 Displaying the topology informationIf you configure Tivoli Manager for R/3 and Tivoli GEM properly, Tivoli GEMcan automatically display the topology information of your SAP R/3 managedresources graphically on the Tivoli GEM Console. This is very user-friendlyand easy to understand in managing your complicated SAP R/3 environment.

The following figure (Figure 173) shows the topology information of our testenvironment in this project.


Figure 173. SAP R/3 Managed Resources Topology Information


As you can see, Tivoli GEM displays the topology information by using thebusiness tree. In this screen, the lower layer in the tree shows more specificinformation, and the upper layer in the tree shows the entire information.

For example, in our case, we configured the R/3 application server anddatabase server on the same system. Therefore, the upper layer shows theR/3 systems (wwdn07_IG3 and is1n05_PD9) that we configure our TMR, andthe lower layer shows the R/3 application server (wwdn07_IG3_00) and R/3database server (wwdn07_IG3_DB) that are configured in the wwdn07_IG3R/3 system.

In this example, SAP R/3 environment is not complicated. However, in alarge-scale SAP R/3 systems environment, it will be very complicated. TivoliGEM can manage this kind of SAP R/3 systems environment easily andefficiently by using the user-friendly GUI.

7.4.4.3 Displaying the SAP R/3 Resource PropertiesIn the Tivoli GEM Console, you can refer to the SAP R/3 resource propertieseasily. At the SAP R/3 resource that you can refer to its properties, click yourright mouse button to show the pull down menu. On this menu, select theresource properties menu. The following figure (Figure 174) shows thisprocesses.


Figure 174. Displaying SAP R/3 Resource Properties

As you can see, Tivoli GEM provides the pull-down menu bar, and we canrefer 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 thatcan be obtain from the menu bar.


Figure 175. The Pull-Down Menu Bar of SAP R/3 Application Server

7.4.4.4 Displaying Event informationIn the Tivoli GEM Console, you can display the events related to your SAPR/3 systems or the specific SAP R/3 system easily. For example, if you wouldlike to check the events related to the specific R/3 system, you can displaythese events by selecting the Event Viewer menu on the pull-down menu ofthe R/3 system icon. The following figure (Figure 176) shows all the eventsrelated to the R/3 system (wwdn07_IG3_00).


Figure 176. Tivoli GEM Console Event Viewer Screen

As you can see, in the Tivoli GEM event viewer, you can monitor the sameevents that are displayed on the TEC console. In this event viewer, you canalso change its properties. For example, to filter the displayed events, you canmodify the severity attributes by using the following screen (refer to Figure177).


Figure 177. The Tivoli GEM Event Viewer Properties

7.4.4.5 Executing Tivoli TasksIn the Tivoli GEM Console, you can also run some tasks by using thepull-down menu bar. On the pull-down menu bar, you just need to select theappropriate task and click the menu. Then, the specified task will beexecuted. To see the result of the task execution, open the Tivoli GEM log(Options -> Tear Away Log). The following figure (Figure 178) shows how todisplay the Tivoli GEM log and the result of the Display_Buffer_Info taskexecution.


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 theTivoli GEM Console is absolutely same as the result of the task execution onTivoli Desktop. You can use the same way to run other tasks on the TivoliGEM Console.

7.4.4.6 Displaying the Monitor StatusIn the Tivoli GEM Console, you can also display all running monitors on thespecific SAP R/3 server. To do this, you just need to double-click the icon ofthe specific R/3 server that you would like to display all running monitors.Then, the following running monitor’s status are displayed (refer to Figure179).


Figure 179. The Running Monitors Status of SAP R/3 Application Server

In this example, we displayed all running monitors on the R/3 applicationserver (wwdn07_IG3). As you can see, the status of all running monitors aredisplayed.

7.4.4.7 R/3 Server unknown status considerationsIn the Tivoli GEM configurations sections, we introduced the Send GEMHeartbeat task. To monitor the up-to-date status of each R/3 server, this taskplays a vital role. Basically, Tivoli GEM sends a heartbeat to each SAP R/3managed resource and detects its status.

If you do not execute this task on some SAP R/3 managed resources, it willbe displayed as the unknown status in the Tivoli GEM Console. The followingfigure (Figure 180) shows how the unknown status object is displayed on theTivoli GEM Console.


Figure 180. The Unknown Status SAP R/3 Objects

As you can see, in this example, the R/3 system (wwdn07_IG3) and R/3database server (wwdn07_IG3_DB) are displayed with a shadow. Normally, ifthe status is normal, the R/3 object is displayed without a shadow.

To avoid this situation, we recommend you to run the Send GEM Heartbeattask on all your SAP R/3 managed resources. Then, the Tivoli GEM keepmonitoring the up-to-date status of each object and displays them properly.

7.4.5 ConclusionAs you can see, Tivoli GEM is able to provide a lot of information and enablesyou to perform a lot of operations on the Tivoli GEM Console. Basically, mostof the information and operations are based on TEC or Tivoli Manager forR/3. However, in other words, you can do almost everything about SAP R/3management operations on the Tivoli GEM Console instead of Tivoli Desktop.The Tivoli GEM Console GUI is user-friendly and highly configurable, andeach of the functions are integrated into the Tivoli GEM Console smartly. Itallows you to perform seamless management.


Tivoli GEM provides the next generation of SAP R/3 management andapplication management style.


Appendix A. Winrunner-Quicktest for R/3 test case

The following (Figure 181 and Figure 182) is a snapshot of the complete testcase that was used for testing TAPM.

Figure 181. Winrunner-Quicktest for R/3 test case (1/2)


Figure 182. Winrunner-Quicktest for R/3 test case (2/2)


Appendix B. Event classes for Tivoli Manager for R/3

The Manager for R/3 provides a set of TEC event classes. These eventclasses are categorized according to where events originate from and howthey are used. The event classes that are provided are:

R/3 Alert Event Classes These event classes arise fromalerts placed by R/3 onto itsSysMan interface. Events for theseclasses are generated by thewr3mib program.

R/3 Operational Event Classes These event classes represent allthe events that result from R/3SysMan events after drill-downprocessing is performed.

R/3 Syslog Event Classes These event classes representevents that result from monitoringthe R/3 syslog file.

Distributed Monitoring Event Classes These event classes areassociated with the Manager forR/3 monitors.

Special Event Classes These event classes supportinternal Manager for R/3processing.

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/3system.

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.


SAP_ALERT_SlogFreq An excessive number of events have been written to theR/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 hasbeen turned on.

SAP_ALERT_DpQueue The length of a dispatch queue hasbeen exceeded.

SAP_ALERT_PerfDia A dialog work process has experienced excessiveresponse time or excessive wait time.

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

SAP_ALERT_PerfBtc A batch work process has experienced excessiveresponse time or excessive wait time.

SAP_ALERT_PerfSpo A spool work process has experienced excessiveresponse time or excessive wait time.

SAP_ALERT_AbapUpd An error has occurred in an ABAP update process.

SAP_ALERT_AbapErr An error has occurred in an ABAP dialog or backgroundprocess.

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 istriggered when a discrepancy is detected duringperiodic comparison of the physical database with thelogical model stored in R/3.

SAP_ALERT_DbFreSp The database is filling up. This is triggered based on aperiodic check and forecast of the growth rate.

SAP_ALERT_DbArcSt There is not enough space in the database archivedirectory.

SAP_ALERT_DbBckup Database backup alert.

SAP_ALERT_Spo Spool alert.

SAP_ALERT_Arch Archive alert.



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

SAP_ALERT_GenP3 Background task is off.

SAP_ALERT_GenP4 The application server profile in the profiles directorydoes not match the profile in the database.

SAP_ALERT_GenP5 General alert class. No specific meaning identified.










SAP_ALERT_GenP15 For Oracle databases, optimizing statistics are beingcollected.


SAP_ALERT_ABAP_ERR This event results from drill-down ofSAP_ALERT_AbapErr.

SAP_ALERT_ABAP_SQL This event results from drill-down ofSAP_ALERT_AbapSql.

SAP_ALERT_ABAP_VB This event results from drill-down ofSAP_ALERT_AbapUpd.

SAP_ALERT_BUFF_CUA This event results from drill-down ofSAP_ALERT_Buf.

SAP_ALERT_BUFF_DBST This event results from drill-down ofSAP_ALERT_Buf.


Event classes for Tivoli Manager for R/3 349

SAP_ALERT_BUFF_FTAB This event results from drill-down ofSAP_ALERT_Buf.

SAP_ALERT_BUFF_IRBD This event results from drill-down ofSAP_ALERT_Buf.

SAP_ALERT_BUFF_PRES This event results from drill-down ofSAP_ALERT_Buf.

SAP_ALERT_BUFF_PXA This event results from drill-down ofSAP_ALERT_Buf.

SAP_ALERT_BUFF_SNTAB This event results from drill-down ofSAP_ALERT_Buf.

SAP_ALERT_BUFF_TABL This event results from drill-down ofSAP_ALERT_Buf.

SAP_ALERT_BUFF_TABLP This event results from drill-down ofSAP_ALERT_Buf.

SAP_ALERT_BUFF_TTAB This event results from drill-down ofSAP_ALERT_Buf.

SAP_ALERT_DB_ARCSTUCK This event results from drill-down ofSAP_ALERT_DbArcSt.

SAP_ALERT_DB_BACKUP This event results from drill-down ofSAP_ALERT_DbBckup.

SAP_ALERT_DB_FREESPC This event results from drill-down ofSAP_ALERT_DbFreSp.

SAP_ALERT_DB_INDICES This event results from drill-down ofSAP_ALERT_DbIndcs.

SAP_ALERT_DB_OPTMSTAT This event results from drill-down ofSAP_ALERT_GenP15.

SAP_ALERT_DPQU_BTC This event results from drill-down ofSAP_ALERT_DpQueue.

SAP_ALERT_DPQU_DIA This event results from drill-down ofSAP_ALERT_DpQueue.

SAP_ALERT_DPQU_ENQ This event results from drill-down ofSAP_ALERT_DpQueue.

SAP_ALERT_DPQU_SPO This event results from drill-down ofSAP_ALERT_DpQueue.



SAP_ALERT_DPQU_V2 This event results from drill-down ofSAP_ALERT_DpQueue.

SAP_ALERT_DPQU_VB This event results from drill-down ofSAP_ALERT_DpQueue.

SAP_ALERT_ENQU_ENQ This event results from drill-down ofSAP_ALERT_Enqueue.

SAP_ALERT_GENP_03 This event results from drill-down ofSAP_ALERT_GenP3. This event usually indicatesthat SAPMSSYS_RSALSUP5 was disabled.

SAP_ALERT_GENP_04 This event results from drill-down ofSAP_ALERT_GenP4. This event usually indicatesthat a profile was not maintained.

SAP_ALERT_GENP_05 This event results from drill-down ofSAP_ALERT_GenP5.













SAP_ALERT_GENP_ARCH This event results from drill-down ofSAP_ALERT_Arch.

SAP_ALERT_GENP_SPO This event results from drill-down ofSAP_ALERT_Spo.

SAP_ALERT_OSCO_FILE Operating system file space threshold has beenexceeded.

SAP_ALERT_OSCO_LOAD Operating system load average thresholds havebeen exceeded.

SAP_ALERT_OSCO_PAGE Operating system paging thresholds have beenexceeded.

SAP_ALERT_OSCO_SWAP Operating system swap thresholds have beenexceeded.

SAP_ALERT_PERF_BTC This event results from drill-down ofSAP_ALERT_PerfBtc.

SAP_ALERT_PERF_DIA This event results from drill-down ofSAP_ALERT_PerfDia.

SAP_ALERT_PERF_ENQ Performance thresholds for the enqueue processhave been exceeded.

SAP_ALERT_PERF_SPO This event results from drill-down ofSAP_ALERT_PerfSpo.

SAP_ALERT_PERF_V2 This event results from drill-down ofSAP_ALERT_PerfUpd.

SAP_ALERT_PERF_VB This event results from drill-down ofSAP_ALERT_PerfUpd.

SAP_ALERT_RLPG_PAG This event results from drill-down ofSAP_ALERT_Rollpag.

SAP_ALERT_RLPG_ROL This event results from drill-down ofSAP_ALERT_Rollpag.

SAP_ALERT_SAPsysDown This event comes directly from wr3mib.

SAP_ALERT_SAPsysUp This event comes directly from wr3mib.

SAP_ALERT_SLOG_FREQ This event results from drill-down ofSAP_ALERT_SlogFreq.

SAP_ALERT_SLOG_ID This event results from drill-down ofSAP_ALERT_SlogId.



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

SAP_ALERT_StateChange This event comes directly from wr3mib.

SAP_ALERT_TRSW_TRSW This event results from drill-down ofSAP_ALERT_Trace.

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 temporaryauxiliary memory.

SAP_SYSLOG_BV3 SQL error &5 occurred (poss. network pros.?) Work processis 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 databaseadministrator.



SAP_SYSLOG_BYM SQL error &5 (possibly a network error); WP in reconnectstatus.

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&5bytes).

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.



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 (Spooladministration).

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.



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 connectionreached.

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.



B.4 Distributed monitoring event classes

The following table (Table 27) shows all Distributed Monitoring Event Classes.

Table 27. Distributed Monitoring Event Classes

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 $$$$.

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 - ApplicationServer

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

SAP_CANCELLED_JOB_MONITOR Cancelled Job

SCREEN_BUFFER_MONITOR PRES Screen and DynproBuffer

SHORT_NTAB_BUFFER_MONITOR SNTAB Short NameTabBuffer



B.5 Special event classes

The following table (Table 28) shows all Special Event Classes.

Table 28. Special Event Classes

B.6 Tivoli GEM event classes

The following table (Table 29) shows all Tivoli GEM Event Classes.

Table 29. Tivoli GEM Event Classes

SINGLE_RECORD_BUFFER_MONITOR TABLP Single Key Buffer

SPOOL_SERVICE_MONITOR Spool Performance

TABLE_DEF_BUFFER_MONITOR TTAB Table DescriptionBuffer

UPDATE_SERVICE_MONITOR Update Performance

WORK_PROCESS_DISPATCH_QUEUE_MONITOR Work process dispatch queue

WORK_PROCESS_MONITOR Work process


APSRVR_STATUS_MONITOR This event generates application server status.

SAP_APM_HEARTBEAT This event is generated when an R/3 object iscreated.

AMS_R3MONITOR_ALERT This event is generated whenever one of theManager for R/3 monitors encounters an error.

AMS_WR3MIB_PROCESS_ALERT This event is generated whenever the alertcontrol or alert reader routines encounter anerror.

SAP_SYSLOG_RFC_ERROR This event results from a communication errorwithin the wr3slog program to the R/3 system.


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 monitorexceeds the threshold.

Event Class Monitoring Source




Appendix C. Monitor sources and their attributes

This appendix lists all of the monitor sources and their attributes. Each tableheading has the following meanings:

Attribute Description of the monitor as initially seen when creating amonitor.

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 directR/3 equivalent, this column explains how the field isderived 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 utilizationuser %

CPU Utilizationsystem (%)

SYSTEM_CPU_UTIL st06 / CPU utilizationsystem %

CPU Utilization idle(%)

IDLE_CPU_UTIL st06 / CPU utilizationidle %

System Calls persecond

SYSTEM_CALLS_SEC st06 / Systemcalls/sec

Interrupts persecond

INTERRUPTS_SEC st06 / Interrupts/sec

Number of CPUs NUMBER_CPUS st06 / Count

Load Average (1min)

LOAD1_AVG st06 / Load average 1min (rounded)

Load Average (5min)

LOAD5_AVG st06 / Load average 5min (rounded)


Load Average (15min)

LOAD15_AVG st06 / Load average15 min (rounded)

Context switchesper second

CONTEXT_SWITCH_SEC st06 / Contextswitches/sec

Physical Memory PHYSICAL_MEMORY st06 / Physical memavail kb

Physical MemoryFree

FREE_MEMORY st06 / Physical memfree kb

Pages in per second PAGE_INS_SEC st06 / Pages in/sec

Pages out persecond

PAGE_OUTS_SEC st06 / Pages out/sec

Kilobytes paged inper second

KB_PAGED_IN_SEC st06 / Kb pagedin/sec

Kilobytes paged outper second

KB_PAGED_OUT_SEC st06 / Kb pagedout/sec

Configured swapspace size

CONFIG_SWAP st06 / Configuredswap kb

Free swap space FREE_SWAP st06 / Free inswap-space kb

Maximum swapspace

MAX_SWAP st06 / Maximumswap-space kb

Actual swap spacesize

SIZE_SWAP st06 / Actualswap-space kb

Disk utilization (%) DISK_UTILIZATION st06 / Disk Utilization

Disk average waittime

DISK_WAIT_TIME st06 / Disk Avg waittime ms

Disk kilobytestransferred persecond

DISK_DATA_TRANSFER_SEC st06 / Disk Kbtransferred/sec

Disk response time DISK_RESPONSE_TIME st06 / Disk Responsetime ms

Disk average queuelength

DISK_QUEUE_LENGTH st06 / Disk Queue



C.2 Roll area source

The following table (Table 31) shows all Roll Area Sources.

Table 31. Roll Area Source

Disk averageservice time

DISK_SERVICE_TIME st06 / Disk Avgservice time ms

Disk operations persecond

DISK_OPERATIONS_SEC st06 / DiskOperations/sec

LAN packets in persecond

LAN_PACKETS_IN_SEC LAN Packets in/sec

LAN packets out persecond

LAN_PACKETS_OUT_SEC LAN Packets out/sec

LAN collisions persecond

LAN_COLLISIONS_SEC LAN Collisions

LAN packet in errorsper second

LAN_PACKET_IN_ERRORS_SEC LAN Errors in/sec

LAN packet outerrors 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 samplingperiod.


Roll Area FreeSpace

ROLL_AREA_FREE Not directly available.ROLL_AREA_SIZEminusROLL_CURRENTLY_USED

Roll Area PercentFree

ROLL_AREA_PERCENT_FREE Not directly available.ROLL_AREA_FREEdivided byROLL_AREA_SIZE

Roll Area SharedMemory

ROLL_AREA_SHARED_MEMORY st02 / Roll area / Inmemory (Kb)

Roll Area Size ROLL_AREA_SIZE Not directly available.Total size of roll area.


Monitor sources and their attributes 363

C.3 Page area source

The following table (Table 32) shows all Page Area Sources.

Table 32. Page Area Source

Roll Currently Used ROLL_CURRENTLY_USED st02 / Roll area / Currentuse (Kb)

Roll Area PercentUsed

ROLL_AREA_PERCENT_USED Not directly available.ROLL_AREA_USEDdivided byROLL_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 Not directly available.ROLL_MAX_USEDdivided byROLL_AREA_SIZE


Page Area Free Space PAGE_AREA_FREE Not directly available.PAGE_AREA_SIZE minusPAGE_CURRENTLY_USED

Page Area Percent Free PAGE_AREA_PERCENT_FREE

Not directly available.PAGE_AREA_FREEdivided byPAGE_AREA_SIZE

Page Area SharedMemory

PAGE_AREA_SHARED_MEMORY

st02 / Paging area / Inmemory (Kb)

Page Area Size PAGE_AREA_SIZE Not directly available. Totalsize of page area.

Page Currently Used PAGE_CURRENTLY_USED

st02 / Page area / Currentuse (Kb)



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)

Table 34. Work Process Source (Attribute 2)

Page Area Percent Used PAGE_AREA_PERCENT_USED

Not directly available.PAGE_AREA_USEDdivided byPAGE_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

Not directly available.PAGE_MAX_USEDdivided byPAGE_AREA_SIZE

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


Free Free sm50 / Status

Waiting Waiting sm50 / Status

Running Running sm50 / Status

Stopped Stopped sm50 / Status

Completed Completed sm50 / Status



C.5 Work process dispatch queue source

The following table (Table 35) shows all Work Process Dispatch QueueSources.

Table 35. Work Process Dispatch Queue Source

******* ******* sm50 / Status

All All sm50 / Status


All All sm51 / queue information

Dialog Dialog sm51 / queue information

Update Update sm51 / queue information

Update2 Update2 sm51 / queue information

Batch Batch sm51 / queue information

Spool Spool sm51 / queue information

Enqueue Enqueue sm51 / queue information

Nowp Nowp sm51 / queue information



C.6 Long running work process source

The following tables (Table 36 and Table 37) show all Long Running WorkProcess Sources.

Table 36. Long Running Work Process Source (Attribute 1)

Table 37. Long Running Work Process Source (Attribute 2)

C.7 Buffer source

The following table (Table 38) shows all Buffer Sources.

Table 38. Buffer Source


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


Threshold in seconds Specified threshold value sm51 / elapsed time


Allocated Memory ALLOCATED_MEMORY st02 / Allocated (Kb)

Available Memory AVAILABLE_MEMORY st02 / Available (Kb)

DB Accesses DB_ACCESSES st02 / Databaseaccesses

DB Accesses Saved DB_ACCESSES_SAVED st02 / DB accessessaved

Frames Swapped FRAMES_SWAPPED st02 / Framesswapped

Free Directory Entries FREE_DIR_ENTRIES st02 / Free directory(Entries)


Free Directory EntriesPercent

PERCENT_FREE_DIR_ENTRIES Not directly available.FREE_DIR_ENTRIESdivided byMAX_DIR_ENTRIES.

Free Memory FREE_MEMORY st02 / Free space (Kb)

Free Memory Percent PERCENT_FREE_MEMORY Not directly available.FREE_MEMORYdivided byAVAILABLE_MEMORY.

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 accessquality %

Requests REQUESTS st02 / Requests

Total Resets TOTAL_RESETS st02 / Resets - Total

Used DirectoryEntries

USED_DIR_ENTRIES st02 / Directory entries- Used

Used DirectoryEntries Percent

PERCENT_USED_DIR_ENTRIES Not directly available.USED_DIR_ENTRIESdivided byMAX_DIR_ENTRIES

Used Memory USED_MEMORY st02 / Size - Used

Used MemoryPercent

PERCENT_USED_MEMORY Not directly available.USED_MEMORYdivided byAVAILABLE_MEMORY



C.8 Performance source

The following table (Table 39) shows all Performance Sources.

Table 39. Performance Source

C.9 OS/390 DB2 source

The following table (Table 40) shows all OS/390 DB2 Sources.

Table 40. OS/390 DB2 Source


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


Active pages of buffer poolwith maximum active

MAX_ACTIVE_BP_PAGES

st04 / Max active pages(%)

Hit ratio of buffer pool withminimum 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 (%)



32K Buffer Pool hit ratio BP32K_HIT_RATIO st04 / Buffer Pool Activity /BP32K Hit Ratio (%)

Buffer Pool shortage - anyactive pool

BP_SHORTAGE st04 / Buffer pool shortage

Hiper pool concern - anyactive pool

BP_HIPER st04 / Hiper pool concerns

Buffer Pool 0 maximumactive pages

BP0_MAX_ACTIVE_PAGES

Not directly available. Canbe seen as Max activepages (%) when this bufferis the one with the highestactive pages.








32K Buffer Pool maximumactive pages

BP32K_MAX_ACTIVE_PAGES


Deadlocks DEADLOCKS st04 / Deadlocks

Lock Suspensions LOCK_SUSPENSIONS st04 / Suspensions

Lock Timeouts LOCK_TIMEOUTS st04 / Timeouts

Failures due to EDM poolfull

EDM_POOL_FULL_FAILURES

st04 / EDM pool full

EDM pool utilization (%) EDM_POOL_IN_USE st04 / EDM pool / Pages inuse (%)

Dynamic cache hit ratio DYN_CACHE_HIT_RATIO st04 / Dynamic StatementCache / Hit ratio (%)

Number of timesMAXKEEPD wasexceeded

MAXKEEPD_EXCEEDED st04 / MAXKEEPDexceeded

Indication of deferred closethreshold reached

CLOSE_THRESHOLD_REACHED

st04 / Deferred closethreshold 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


CPU Utilization (%) CPU_UTIL os07 / Avg. Processor Utili.

CPU Utilization - system(%)

SYSTEM_CPU_UTIL os07 / MVS CPUUtilization

Paging Rate PAGING_RATE_SEC os07 / Avg. System PagingRate

Pages In per second PAGE_INS_SEC os07 / Pages paged in/sec

Pages Out per second PAGE_OUTS_SEC os07 / Pages pagedout/sec

Pages Into Private persecond

PAGE_INS_PRIVATE_SEC

os07 / Priv. pages pagedin/s

Pages Out of Private persecond

PAGE_OUTS_PRIVATE_SEC

os07 / Priv. pages pagedout/s

Pages to ExpandedStorage per second

PAGES_TO_EXPSTOR_SEC

os07 / Pages to exp.storage

Pages from ExpandedStorage per second

PAGES_FROM_EXPSTOR_SEC

os07 / Pages from exp.storage

Blocked pages paged in BLOCKED_PAGES_PAGED_IN

os07 / Blocked pagespaged in

Blocks paged in BLOCKS_PAGED_IN os07 / Blocks paged in

Unused interval count UNUSED_INTERVAL_COUNT

os07 / High UIC count

Available frames inexpanded storage

EXPSTOR_AVAILABLE_FRAMES

os07 / Avail. exp. stor. slots

Migration age MIGRATION_AGE os07 / Migration age

Total available frames TOTAL_AVAILABLE_FRAMES

os07 / No. of availableframes



Appendix D. TEC Rules and Events

This appendix shows TEC rules and events that are contained Tivoli Managerfor R/3 products.

D.1 Event Classes: Distributed Monitoring based

This section shows Distributed Monitoring based event classes.

• SAP_Status_Monitors

• APSRVR_STATUS_MONITOR

• SAP_Server_Monitors

• SAP_Cancelled_Job_Monitors

• SAP_CANCELLED_JOB_MONITOR

• 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 eventclass. It replaces and enhances theSAP_SYSTEM_MONITOR class from 1.5.

SAP_Server_Monitors SAP_Cancelled_Job_Monitors is a new class with2.0. This class includes additional slot values forreporting job information. Within the other DMevents under the SAP_Server_Monitors are newclasses for the new Manager for R/3 2.0 workprocess monitors. These process classes do notinclude 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)


• SAP_Alert_Buffer (10)

• AMS_WR3MIB_PROCESS_ALERT

The SAP_Alert class hierarchy is quite similar to Version 1.5 of R/3 Manager.The major changes are:

• The introduction of the SAP_Alert_Buffer class and the movement of theten buffer alerts from the SAP_Internal_Alert class to theSAP_Alert_Buffer class.

• The removal of the Heartbeat_event (and its six associated rules).

The event classes that appear on the TEC console are the:

• SAP_MIB_Unique_Alert

• SAP_Internal_Alert

• SAP_Alert_Buffer


The SAP_MIB_Unique_Alert class includes the SAPsysUp, SAPsysDown,and StateChange events. The first two are issued when the application serverstarts up and shuts down, respectively. The last one is issued when onoperational 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_RFC_ERROR

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 wherexxx corresponds to an R/3 3-character message ID. If customers are adding


syslog event classes, it is recommended that they follow this namingconvention.

SAP_SYSLOG_RFC_ERROR is an error event. It defines special slot valuesto provide information on the nature of the error. Occurrences of this errorshould 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 GEMAPM_HEARTBEAT event. The SAP_APM_HEARTBEAT is used to supportdelay 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 DMmonitors, 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_sourceslot.

Events for a particular application server are correlated by application servertriplet. Manager for R/3 provides this in both the hostname and sub_originslots. The event adapters set these slots. For DM monitors, the triplet ispassed in the "info" slot. A rule is provided that extracts the triplet from theinfo slot and assigns it to the hostname and sub_origin slots.

The new extraction rules remove the 1.5 restriction that monitors mustoriginate 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

• APSRVR_STATUS_MONITOR

• 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 ofslots. Manager for R/3 provides rules to detect duplicate events and dropduplicates.

All the true duplicate event processing applies to DM-based events. Thecancelled jobs events and the status events are new with 2.0. For theseevents, the original is kept, its duplicate counter incremented, and the newevent is dropped. Processing of DM events from 1.5 was not changed; the oldevent is dropped and the new event is kept. Note that it is particularlyimportant to keep the most recent status event.


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 (incrementingits 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 analert by the R/3 system when a problem clears. Since the problem is goingaway, the TEC rules endeavor to either close the harmless in 60 seconds (tominimize 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 andSAP_Alert_Buffer events on the TEC console for 60 seconds instead ofclosing 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 incorrectreferencing SAP_Server_Monitors.


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 applicationserver starts, we essentially want to reset its alert state. This means we wantto close all outstanding events for that application server and refresh its eventstate with a new status of "up" and refresh the problem alerts with all alertsnow 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 area problem independent of startup/shutdown.

• App Server Up - first 35 minutes

• Drop all SAP_Server_Monitor events except for Cancelled BatchJobs

• 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, itwill take it some time to reach "steady state". This settling down interval isassumed 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 areassumed to be attributed to the application server startup. For example,buffer attributes, response times, and storage area values are all subject tofluctuation during this time.



• 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 sameas 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. Sincethe application server is restructuring its Dialog and Batch processes, it maytake it some time to reach "steady state". This settling down interval isassumed to be 35 minutes in the TEC rules. During this time, the R/3 systemitself might be detecting buffer problems. These alerts are automatically resetin the R/3 system (telling R/3 to discard this alert but continue to monitor forthe same threshold levels), and they are closed in TEC. In addition, allDM-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 sameas 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).


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 anapplication server stops, we essentially want to reset its alert state. Thismeans we want to close all outstanding events for that application server andrefresh 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 area 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_MIB_Unique_Alert


• SAP_Alert_Buffer

• SAP_SYSLOG


• Drop



• SAP_MIB_Generic_Alert

• SAP_Internal_Alert

• SAP_SYSLOG_RFC_ERROR

The application server is down. We do not expect, nor want, any eventsrelated to the application server except for those relating to state change. Theonly event classes that will convey a state change areSAP_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 theapplication server is down, we should not be getting any of these eventsanyway.

We are especially concerned about dropping SAP_Server_Monitors andSAP_SYSLOG_RFC_ERROR events since the function may be still berunning, but since there is no application server available, we may be gettingfalse events.


• sap_system_down_no_more_sentries (sap_monitor.rls/14)

Rule 14 should really exclude the SAP_Alert_Buffer, SAP_SYSLOG, andAMS_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 TECserver. These rules support the forwarding of all events and the forwarding ofoperator acknowledgements and closures. This functionality is essentiallyunchanged from 1.5.



• 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. Theseactions map the TEC actions of close/acknowledge to the R/3 actions ofreset/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)


These rules need to include SAP_Alert_Buffer class also. In 1.5 they wereSAP_Internal_Alert’s 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 thatR/3 will generate a harmless alert for the condition being acted upon. Thesame harmless alert is generated whether the R/3 administratoracknowledged the alert or closed the alert. The harmless alert looks identicalto the original problem alert except for the different status. The original alertmay have been critical; the closed alert is harmless. This allows the TECrules 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 keptin its place. This is not a true duplicate. Since the new event is harmless, theevent 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/3system through transaction RZ06. When an alertable message is written tothe R/3 syslog, R/3 intercepts the message and also places an alert on the


SysMan for a Critical Syslog Message. As long as this alert is posted, R/3 willnot 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 thealert in an effort to allow subsequent syslog alerts to be generated. Even withthis TEC rule in place, it was still possible to miss syslog alerts.

The syslog adapter overcomes this shortcoming. The syslog adapter willretrieve all syslog messages regardless of their alert status. With the syslogadapter, 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 areonly high level indications of a problem in some area. They are not specific asto the nature of the problem. For example, the SysMan will report a bufferproblem, but it will not indicate which R/3 buffer has the problem. To get thedetailed information, Manager for R/3 provides a drill-down rule. This rulelaunches a TEC task (that launches a second task) to read the R/3 internalalert information. The result of this process is a specific SAP_Internal_Alertthat provides the detailed alert information. For example, in response to thebuffer 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.



• 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 JobDate. A rule is provided to extract these values from the "info" slot and placethem in their respective slots. This is to facilitate the customer writingadditional rules that can perform processing based on these slot values. Forexample, 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



• Convert SAP_APM_HEARTBEAT to APM_HEARTBEAT and send toGEM

GEM events require the sub_source slot to match the product identifier. Rulesare 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 slotis set to the R/3 instance. This is done for all events of SAP_Server_Monitorsand SAP_Status_Monitors before they are sent to GEM.

The conversion of the SAP_APM_HEARTBEAT to APM_HEARTBEAT is doneto introduce a timing delay in the system between the creation of Manager forR/3 objects and the creation of those objects in GEM.


• sap_gemevnts_rule1 (sap_gemevents.rls/1)




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 tothe R/3 system. When this daemon is down, R/3 is unable to report these OSvalues. Manager for R/3 provides implements a DM monitor for daemonstatus. These rules complement that monitor by managing the events comingfrom 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 modifiedto 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


• Drop new event

The host monitor was provided in 1.5 as a means to check the availability ofan R/3 server machine. It used the DM host monitors. This function wasdropped in 2.0, but the rules for handling the monitor results are still in theproduct.

These rules are not really selective and will process any host status. There isno way to make these R/3 specific.


• sentry_host_up (sap_monitor.rls/8)

• sentry_host_down (sap_monitor.rls/9)



Appendix E. Special notices

This publication is intended to help system designers and technical users ofTivoli products to understand more about the Tivoli Manager for R/3 and howto manage SAP R/3 systems with Tivoli products. The information in thispublication is not intended as the specification of any programming interfacesthat are provided by Tivoli. See the PUBLICATIONS section of the IBMProgramming Announcement for Tivoli for more information about whatpublications are considered to be product documentation.

References in this publication to IBM products, programs or services do notimply that IBM intends to make these available in all countries in which IBMoperates. Any reference to an IBM product, program, or service is notintended to state or imply that only IBM's product, program, or service may beused. Any functionally equivalent program that does not infringe any of IBM'sintellectual property rights may be used instead of the IBM product, programor service.

Information in this book was developed in conjunction with use of theequipment specified, and is limited in application to those specific hardwareand software products and levels.

IBM may have patents or pending patent applications covering subject matterin this document. The furnishing of this document does not give you anylicense to these patents. You can send license inquiries, in writing, to the IBMDirector of Licensing, IBM Corporation, North Castle Drive, Armonk, NY10504-1785.

Licensees of this program who wish to have information about it for thepurpose of enabling: (i) the exchange of information between independentlycreated programs and other programs (including this one) and (ii) the mutualuse of the information which has been exchanged, should contact IBMCorporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.

Such information may be available, subject to appropriate terms andconditions, including in some cases, payment of a fee.

The information contained in this document has not been submitted to anyformal IBM test and is distributed AS IS. The use of this information or theimplementation of any of these techniques is a customer responsibility anddepends on the customer's ability to evaluate and integrate them into thecustomer's operational environment. While each item may have beenreviewed by IBM for accuracy in a specific situation, there is no guaranteethat the same or similar results will be obtained elsewhere. Customers


attempting to adapt these techniques to their own environments do so at theirown risk.

Any pointers in this publication to external Web sites are provided forconvenience only and do not in any manner serve as an endorsement ofthese Web sites.

The following terms are trademarks of the International Business MachinesCorporation in the United States and/or other countries:

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, PlanetTivoli, and Tivoli Enterprise are trademarks or registered trademarks of TivoliSystems Inc., an IBM company, in the United States, other countries, or both.In Denmark, Tivoli is a trademark licensed from Kjøbenhavns Sommer - TivoliA/S.

C-bus is a trademark of Corollary, Inc. in the United States and/or othercountries.

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Sun Microsystems, Inc. in the United States and/or othercountries.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States and/or other countries.

PC Direct is a trademark of Ziff Communications Company in the UnitedStates and/or other countries and is used by IBM Corporation under license.

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of IntelCorporation in the United States and/or other countries.

UNIX is a registered trademark in the United States and other countries

ADSTAR AIXAS/400 CICSDB2 IBMMQSeries NetViewOS/2 OS/390RISC System/6000 SAPTivoli Tivoli EnterpriseTivoli Ready TME


licensed exclusively through The Open Group.

SET and the SET logo are trademarks owned by SET Secure ElectronicTransaction LLC.

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

Special notices 391


Appendix F. Related publications

The publications listed in this section are considered particularly suitable for amore detailed discussion of the topics covered in this redbook.

F.1 IBM Redbooks publications

For information on ordering these publications see “How to get IBMRedbooks” 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 Tivoli’s TME 10, SG24-4948

• Designing Tivoli Solutions for End-to-End Systems and ServiceManagement, 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 LockdownModules, SG24-5140

F.2 IBM Redbooks collections

Redbooks are also available on the following CD-ROMs. Click the CD-ROMsbutton at http://www.redbooks.ibm.com/ for information about all the CD-ROMsoffered, updates and formats.

CD-ROM Title Collection KitNumber

System/390 Redbooks Collection SK2T-2177

Networking and Systems Management Redbooks Collection SK2T-6022

Transaction Processing and Data Management Redbooks Collection SK2T-8038

Lotus Redbooks Collection SK2T-8039

Tivoli Redbooks Collection SK2T-8044

AS/400 Redbooks Collection SK2T-2849

Netfinity Hardware and Software Redbooks Collection SK2T-8046

RS/6000 Redbooks Collection (BkMgr) SK2T-8040

RS/6000 Redbooks Collection (PDF Format) SK2T-8043


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

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

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 User’s Guide, GC31-8411

• Tivoli Manager for SAP R/3 Release 1.5, GI10-9224

• Framework 3.6 User’s 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

Application Development Redbooks Collection SK2T-8037

IBM Enterprise Storage and Systems Management Solutions SK3T-3694

CD-ROM Title Collection KitNumber


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 fewchapters will be published this way. The intent is to get the information out much quicker than theformal publishing process allows.

• E-mail Orders

Send orders by e-mail including information from the IBM Redbooks fax order form to:

• Telephone Orders

• Fax Orders

This information was current at the time of publication, but is continually subject to change. The latestinformation may be found at the Redbooks Web site.

In United StatesOutside North America

e-mail [email protected] information is in the “How to Order” section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl

United States (toll free)Canada (toll free)Outside North America

1-800-879-27551-800-IBM-4YOUCountry coordinator phone number is in the “How to Order”section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl

United States (toll free)CanadaOutside North America

1-800-445-92691-403-267-4455Fax phone number is in the “How to Order” section at this site:http://www.elink.ibmlink.ibm.com/pbl/pbl

IBM employees may register for information on workshops, residencies, and Redbooks by accessingthe 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 developedand written by the ITSO technical professionals; click the Additional Materials button. Employees mayaccess MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.

IBM Intranet for Employees


http://www.elink.ibmlink.ibm.com/pbl/pbl



http://w3.itso.ibm.com/

http://w3.ibm.com/

http://www.redbooks.ibm.com




mailto:[email protected]




IBM Redbooks fax order form

Please send me the following:

We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card notavailable in all countries. Signature mandatory for credit card payment.

Title Order Number Quantity

First name Last name

Company

Address

City Postal code

Telephone number Telefax number VAT number

Invoice to customer number

Country

Credit card number

Credit card expiration date SignatureCard issued to


List of abbreviations

AIX Advanced InteractiveExecutive

CLI Command LineInterface

DB2 Database 2

ERP Enterprise ResourcePlanning

FTP File Transfer Protocol

GUI Graphical UserInterface

IBM International BusinessMachines Corporation

ITSO International TechnicalSupport Organization

LCF Lightweight ClientFramework

R/3 Release 3

RDBMS Relational DatabaseManagement System

SAP Systems Applicationsand Products in DataProcessing

TCP/IP Transmission ControlProtocol/InternetProtocol

TEC Tivoli EnterpriseConsole

TMA Tivoli ManagementAgent

TME Tivoli ManagementEnvironment

TMR Tivoli ManagementRegion

© Copyright IBM Corp. 1999
397


Index

AABAP 197, 238ABAP file package 89, 129access 265, 266access method 263account 324administration task 36administrator 44, 109, 125, 184, 264, 299administrator group 323administrator system 295Administrator user 324ADSM 42, 241AIX 234, 241, 258, 310, 314alert 128, 139alert event adapter 83, 84, 158, 159, 185, 186,208, 219API 278application 99, 227, 230, 232, 242, 262, 265application management 21, 304, 317, 344Application Management Package (AMP) 325application performance 292Application Proxy 62, 103, 122Application Response Measurement (ARM) 26,272application 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, 342argument 166ARM API 26AS/400 232attribute 100authority 129authorization 138, 197authorization role 60, 122, 124automatic discovery 18, 52, 66, 85, 128, 140, 144,201availability 227, 240

Bbackground process 233BACKINT 43backup 122, 123, 125bandwidth 232

© Copyright IBM Corp. 1999

bandwidth optimization 16baroc file 190, 219, 247Baroc Files

sap_server_monitor_35.baroc 219sap_tecad.baroc 219tecad_wr3slog.baroc 219

bash 285batch file 277batch job 35, 52, 73, 164, 238batch process 230, 235, 288BDF 325benchmark 30buffer quality 200business application 1, 240, 305Business Application Programming Interface (BAPI)35business design 119business function 2business information 2business operation 293business process 3, 4, 20, 22, 241, 288business system 8, 22, 65, 240, 305, 331business system management 21business tree 336

Ccancelled batch job 53capacity planning 299CCMS 17, 163, 184, 188, 197, 220CDF 325CD-ROM 64, 169, 173, 181central monitor 194centralized control 269centralized location 51character column 71class object 93, 103Classes

J class 88Y class 88Z class 88

CLI 38, 53, 70, 272client capture 27client machine 295client server model 3, 25Cognos PowerPlay 19

399

collection interval 280collector 272command 93, 272, 285Common Object Request Broker Architecture(CORBA) 10configuration 52, 119, 128Configuration Files

ihsttec.cfg 323r3mibIID.conf 84, 186r3slogIID.cl 84, 189r3slogIID.conf 84, 189rfc_interface 197

configuration method 54configuration parameter 130context variable 104control mode 333core dump 78correlation 246CPIC 139, 197CPU time 76, 299cross-platform business application 65csv file 296, 298CUA buffer 188cube 295, 296, 298

Ddaemon 233data 261data file 130database 3, 5, 51, 149, 202, 217, 234, 239, 265,272, 281, 285, 292, 295, 299, 304database configuration 107database server 4, 52, 57, 62, 115, 124, 128, 140,141, 143, 144, 150, 152, 163, 167, 196, 202, 204,207, 218, 234, 336, 343database structure 293DataHub 31dataless profile manager 97, 131, 178DB2 5, 31, 116, 234, 295DB2 Enterprise Control Center (DB2 ECC) 31DB2 UDB 31DBA 31dbaccess 167default monitoring 199de-install 85delivery channel 268delivery mechanism 293

dependency 120, 123, 125dependency manager 90dependency set 93Dependency Sets

sap_dep 93sap_lib_dep 93sap_tool_dep 93

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

Ee-business 2elapsed time 26, 79EMD/MD 246encrypted form 45, 61, 268end user 20end user application performance 25Endpoint 53, 72, 83, 91, 97, 103, 122, 124, 128,132, 183, 272, 292, 309Endpoint Gateway 63, 91, 103, 108, 113, 122,124, 128, 148, 272, 309Endpoint Gateway database 92Endpoint Manager 91Endpoint method 90, 94Endpoint method cache 91, 96enterprise 227, 265, 267, 295enterprise management 228enterprise resource 228ERP 2, 4, 21, 22, 235errlog 258error log 232


event 16, 52, 53, 89, 154, 186, 222, 239, 248, 305,338Event Adapter 15, 53, 84, 85, 128, 151, 160, 164,185, 222, 247event analyzer 27event class 151, 190, 197, 219, 221, 305, 321event correlation 15Event Enablement 305, 308, 312, 322event group 155, 157event management 259event repository 260event severity 190event slot 224event source 155, 158, 242, 247event source group 89Event Sources

SENTRY 222WR3MIB 89, 158, 222WR3SLOG 158WRSLOG 89

executable program 277exit code 150Extended ERP (xRP) 3

Ffan-out 16file 93, 265file package 16, 37, 50, 132, 168, 171, 173, 176,178file server 241, 295file system 232filter 53, 186, 191, 239, 247filtering capability 84Framework function 91fresh installation 85ftp 169function module 128, 136, 198

GGEM Console 30, 305, 308, 314, 323, 324, 329,342, 343GEM event viewer 339GEM heartbeat 325GEM Instrumentation 50, 65, 305, 308, 317, 321GEM log 340GEM Server 305, 308, 310, 315, 321, 323, 324GEM sign on screen 330

generic event 186Global Enterprise Manager (GEM) 10, 21, 53, 64,111, 119, 163, 229, 236, 240, 241, 264, 304group ID 133GUI 1, 36, 38, 240, 264, 266, 272, 304, 305, 314,343guideline 246

Hhard disk 110hardware 107, 115, 230, 237, 261harmless event 84, 222heartbeat event 305help desk 240hierarchy 57high-level view 331historical data 297hostname 108HP-UX 314hub 231

IIBM 3IBM Java Web site 310icon 52, 54, 67, 72, 89, 132, 237, 279, 289icon file 325ID 58IDL interface 103import logfile 136indicator 49, 58indicator collection 56, 126, 199Informix 5, 168, 295infrastructure 242installation 97, 119, 120, 169InstallSheld 315instance profile 139integer column 71interconnected TMR 53interface function 62internal alert table 188Internet 45, 268Internet business model 3Internet-ready architecture 3IP-based network 46IT 3, 21IT administrator 18IT environment 246IT infrastructure 9

401

ITS 6

JJava 44, 305, 309, 314Java Developer Tool Kit (JDK) 306, 308, 310job ID 75job log 290job name 75job scheduling 35

KKerberos Security Registry 38key word 73

Llanguage 146, 176large-scale environment 49, 66LCF architecture 93life cycle toolbar 331life-cycle management 33load balance 299Loadrunner 292Local Area Network (LAN) 1Lockdown Module 41, 264log file 188, 234logical design 120login 36, 133, 139, 266logoff 289logon 288long running process 53Lotus Notes 241, 265

Mmachine 262Maestro 35Managed 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, 315managed resource 276, 304, 327management discipline 8Management Information Base (MIB) 237management operation 91, 343manual 168, 175MarProfile 275, 279master server 38measurement agent 26memory 110

memory allocation 217method 91methodology 246MIB 185, 188, 194, 222MIB interface 186, 195, 220Microsoft 3Microsoft SQL Server 5middleware 8migration 67, 85, 98mission critical transaction system 3mode 131module 93monitor 17, 58, 145, 152, 211, 217, 248monitor argument 79monitor event 321monitoring 15, 231, 242monitoring collection 15, 78, 199, 202, 218, 242,248Monitoring Collections

R3 Server Central Monitors 79, 195, 202R3 Server Remote Monitors 79, 195, 202,208

monitoring profile 59, 79, 237, 275, 277, 283monitoring schedule 280monitoring source 79, 218Monitors

Application Server Status 69Long Running Work Process 78Work Process 79Work Process Dispatch Queue 79

Motif 168MQSeries 33multimedia 1multiple column table 70multiple R/3 systems 51

Nnative installation 173, 178nesting level 54NetView 15, 46, 236, 241NetWare Managed Site 97network 16, 27, 51, 227, 230, 241, 262network component 237network computing environment 7network management 46network mode 295


network topology 46Network X-Ray 28NIS Domain 97notice 274notice group 274Nowp type 82

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

Ppage area 164, 200parameter 204parameter file 148password 36, 61, 129, 139, 146, 197, 260, 266,285, 323, 324, 330patch 108, 120PC Managed Node 38, 97, 178PC Server 232PeopleSoft 21performance 227, 240, 277performance data 20performance management 25

performance monitoring 29personal computer 1physical architecture design 120plan mode 332platform 119, 132, 173, 178, 238, 265, 294, 310platform type 72, 144policy definition 36, 266policy region 49, 55, 67, 86, 125, 142, 275, 319Policy Regions

Manager for R3 126, 130, 141, 144, 163,167, 169, 174Manger for R3 199R3 Configuration 127, 144, 164, 169, 174

policy-based management 18predefined monitor 37, 199, 204predefined task 67, 71, 164prerequisite 50, 62, 120presentation client 4print 263print server 241printer 265probe 28problem determination 230, 240, 241process count 53process ID 76, 78process status 80, 234process type 76, 79processor 110production 51profile 169profile based methodology 36profile manager 49, 56, 98, 108, 126, 130, 169,178, 199, 277profile manager hierarchy 97Profile Managers

R3 App Server Monitors 200, 204R3 DB Server Monitors 202R3 Managed Nodes Monitors 202R3 Transport 89, 130

program 99property 68proxy 26pull down menu 68

Qqueued request 82

403

RR/3 application 6, 202, 217R/3 buffer 217, 223R/3 Collector 297R/3 database 167R/3 monitor 52R/3 object 50, 57, 63, 66, 103, 128, 144, 203R/3 process 76, 78R/3 resource 297R/3 server 58, 297R/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, 343R/3 system release 68r3mibIID program 186RACF 265RDBMS 5, 31, 39, 207, 239, 260, 263RDBMS home 286reboot 92redbook 51reference installation 169, 178release 108Remote Function Call (RFC) 52, 61, 67, 85, 128,145, 185, 189, 194remote monitor 194repeater 231replica server 38reporting capability 20resource 99, 265Resource Access Control Facility (RACF) 40resource management 268resource role 52, 55resource type 99response 52response time 27, 200, 217, 232, 299restructure 54RFC function 61RFC interface 61, 138, 186, 195, 221RFC user 128, 145, 146RIM 286role 265role-based security 40, 264roll area 164, 200root 133root user 122, 124router 231routine task 18routing rule 268RS/6000 232, 234, 241

rule base 18, 37, 50, 84, 151, 186, 219, 221, 247,260, 305, 321rule-based foundation 45rules engine 186Rules Sets

sap_default.rls 222sap_monitor.rls 222sap_tecad.rls 222

running monitor 341running process 79

SSAP 3SAP administrator 128, 135, 199SAP instance 6SAP R/3 1, 3, 35, 41, 43, 49, 107, 115, 119, 154,163, 217, 234, 241, 263, 265, 271, 292, 297, 304,314, 327SAP R/3 application 21, 317SAP R/3 environment 9, 21SAP R/3 management 16, 344SAP R/3 resource property 336SAP R/3 user account 36SAP user 128, 129SAP Users

DDIC 129SAP* 129

SAP utility 43SAPGUI 5, 16, 18, 74, 77, 119, 129, 138, 141,168, 169, 173, 175, 178, 181, 197, 277, 287SAPOSCOL 17saprouter program 82sapsetup program 181scenario 227schedule 145schedule list 66scheduling rule 280script 104, 145, 150, 260, 287Scripts

cr_tapm_rim.sh 287ihsttec.sh 322R3Mgr_mn_deinstall.2.0 85R3Mgr_tmr_deinstall.2.0 85sap_alert_control_cb.sh 188sap_alert_reader.sh 186


sap_alert_reader_cb.sh 186sap_config_adapter.sh 159sap_config_rfc.sh 145sap_control_reader.sh 188sap_eventserver_config.sh 152sap_start_db.exit.sh 150sap_stop_db_exit.sh 150sap_tec_config.sh 155wmarreg.sh 278, 291

SCSI disk array 232Seagate Crystal Reports 19secure encryption method 38security 60, 261, 268security group 41security policy 42security profile 41, 265, 267Sentry engine 78Sentry monitor 49, 104server ID 286service delivery organization 241service level 28, 292Service Level Agreement (SLA) 29, 297, 299severity attribute 339severity level 52shared drive 295shared memory pool 139shared memory segment 139, 185SID 6, 58, 60, 68, 130, 141, 150, 167SID-specific indication 55, 66, 199Simple Network Management Protocol (SNMP) 46,237simulation 288simulation interval 292SMIT 310SNMP event 46SNMP manager 15SNMP trap 46, 237software 112, 115, 227, 261Software Distribution 10, 16, 37, 62, 119, 130,168, 171, 173, 176, 178Software Installation Service (SIS) 274solution 115, 227source file 133SP 115SP2 241specialized management 8specific event 186specification 109SQL 167

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

Ttable 287tablespace 234, 248task 15, 49, 52, 58, 61, 64, 75, 104, 126, 141, 145,150, 163, 167, 169, 174, 340Task Libraries

R3 App Server Tasks 73, 76, 126, 164R3 Configuration Tasks 71, 127, 144, 146,152, 169, 174R3 DB Server Tasks 126, 164, 167R3 Internal Tasks 127R3 List Maintenance Tasks 127R3 System Tasks 126, 164, 168

405

task library 56, 61, 126, 319Tasks

Cancel Batch Jobs 73Cancel Work Process 76Configure Autodiscovery 72, 144Configure Event Adapter 160, 186, 189Configure Event Console 155, 321Configure Event Server 152Configure Remote Function Call 146, 197Display Batch Jobs 72, 164Display Buffer Information 340Display Event Adapter Configuration 189Display Work Processes 76Release Batch Jobs 73Remove Autodiscovery 67, 72Send GEM Heartbeat 325, 342Start Database 167Stop Database 167

TCP service 265TCP/IP 5, 25TDS component 293TDS Guide 19, 293TEC 15, 16, 17, 37, 46, 50, 53, 62, 83, 110, 119,151, 186, 189, 237, 239, 241, 247, 259, 343TEC database 155TEC event 15, 83, 84, 159, 185, 220, 242, 323TEC event console 15, 84, 89, 128, 151, 186, 207,216, 222, 247, 328, 339TEC server 37, 63, 83, 103, 122, 124, 128, 151,154, 186, 219, 220, 223, 305, 312, 321technical analyst 293telnet 237test 51test case 289thin node 115thread 234threshold 52, 79, 184, 197timeout 144, 160Tivoli 7, 51Tivoli administrator 52, 129, 141, 169, 274Tivoli Application Performance Manager (TAPM)20, 25, 112, 119, 163, 241, 271Tivoli Commands

idlattr 100, 104idlcall 100, 104objcall 100tivoli 122, 124

wdepset 93wgateway 92wgetrim 286wlookup 93, 99wlsinst 108wmarregapp 277wpostemsg 83wr3rfc 53, 70wrcrtrim 286

Tivoli core application 50, 62, 120Tivoli Data Protection for SAP R/3 10, 43Tivoli database 61, 123, 125, 197, 296Tivoli Database Manager Product 10, 31, 236, 241Tivoli Databases

gwdb.bdb 92imdb.bdb 92

Tivoli Decision Support (TDS) 19, 242, 292, 293Tivoli Decision Support for SAP R/3 21, 294, 297Tivoli Desktop 15, 35, 52, 55, 67, 89, 104, 122,124, 125, 140, 150, 163, 167, 169, 205, 272, 312,315, 319, 341, 343Tivoli Enterprise 1, 7, 16, 21Tivoli Enterprise Product 10, 19Tivoli Global Sign-On 10, 37, 264Tivoli Global Sign-On Plus Module 37Tivoli Management Agent (TMA) 53, 62, 83, 85,90, 97, 103, 108, 122, 124, 128, 131, 142, 148,150, 169, 178, 272, 306Tivoli Management Application 15, 18, 90, 93, 99Tivoli Management Environment (TME) 7Tivoli Management Framework 10, 15, 31, 62, 99,119, 274, 305Tivoli Manager for DB2 31, 207Tivoli Manager for Domino 62, 250Tivoli Manager for MQSeries 10, 33Tivoli Manager for Oracle 31, 202, 207Tivoli Manager for R/3 10, 16, 21, 49, 51, 54, 64,90, 116, 119, 121, 128, 145, 149, 163, 217, 236,241, 248, 308, 343Tivoli Manager for Sybase 32Tivoli Manager series product 49, 62, 64, 105Tivoli Module Builder 331Tivoli Module Designer 331Tivoli Name Registry (TNR) 99Tivoli object 140Tivoli Objects

EventServer 84


R3AppServer 93, 99, 103, 144, 326R3AppServerPD 99R3AppServerPV 99R3DBServer 99, 103, 144, 326R3DBServerPD 99R3DBServerPV 99R3Instance 99R3System 99, 103, 104, 144, 326R3SystemPD 99R3SystemPV 99

Tivoli Output Manager 10, 43, 264Tivoli Plus for Tivoli Workload Scheduler 35Tivoli product 108Tivoli role 61, 128Tivoli Roles

install_product 122, 124r3_admin 60, 140r3_senior 60, 140r3_user 60, 140super 169

Tivoli Security Management 10, 40, 264Tivoli Service Desk 10Tivoli Storage Manager 42Tivoli User Administration 36, 39, 264Tivoli User Administration for SAP R/3 36Tivoli Workload Scheduler 10, 35, 129, 236Tivoli Workload Scheduler Extended Agent for SAPR/3 10TME 10 7TMR 39, 62, 83, 89, 110, 119, 202, 314, 327, 336TMR role 141TMR 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, 317topology information 334topology map 304TPPARAM file 134transaction 26, 129, 297transaction code 301Transaction Codes

rz10 139rz20 184se80 137sm21 288sm37 74, 288sm50 77sm51 288

st02 18st06 18su01 129, 138

transaction simulation 27transformer model 296transport 89, 128, 129, 134transport buffer 134tsadmn group 323tsuser group 323two-tier 25

UUNIX 3, 71, 132, 144, 167, 168, 174, 183, 188,237, 250, 322unknown status 329, 342upcall 63, 93, 104upgrade 97URL 19user 286, 298user access 37user created job 238user group 323user ID 37, 61, 133, 189, 197, 260, 266, 323, 330user information 38user interface 54user-defined event class 84

Vvendor 286verify mode 332Virtual User Script (VUS) 291

WWeb interface 3Web server 43Web site 120wide node 115Windows 95 5, 168, 174, 295, 314Windows 98 5, 314Windows NT 3, 71, 111, 133, 149, 167, 168, 169,174, 181, 183, 188, 241, 255, 265, 295, 297, 310,315, 322, 323Windows NT service 324Winrunner 288, 291Winrunner-Quicktest for R/3 287work process 52, 76, 79, 164work process table 71

407

workstation 168wr3mib program 185, 196, 208, 220, 221wr3rfc function 61wr3rfc program 148, 187, 196, 197, 201, 203, 221

Xxterm 167



IBM Redbooks evaluation

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

Your feedback is very important to help us maintain the quality of IBM Redbooks. Please complete thisquestionnaire 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 [email protected]

Which of the following best describes you?_ Customer _ Business Partner _ Solution Developer _ IBM employee_ None of the above

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!)

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



Printed in the U.S.A.

SG24-5500-00

Using

Tivolito

Manage

aL

arge-Scale

SA

PR

/3E

nvironmen

tS

G24-5500-00

Documents

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