tivoli business systems manager v2.1 end to-end business impact management sg246610

ibm.com/redbooks

Tivoli Business Systems Manager Version 2.1End-to-End Business Impact Management

Budi DarmawanAlessio D’Amico

Cedric FooPeter GlasmacherStephen Nosbisch

Samson Yiu

In-depth product structure revealed and explained

Detailed implementation of best practices

Integrated systems management solution

Front cover

Tivoli Business Systems Manager Version 2.1 End-to-End Business Impact Management

April 2003

International Technical Support Organization

SG24-6610-00

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

First Edition (April 2003)

This edition applies to Version 2, Release 1 of IBM Tivoli Business Systems Manager and IBM Tivoli Business Systems Manager for z/OS (product number 5678-BSM).

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

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiiiTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvThe team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxviiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii

Part 1. Concept and planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Introduction to business systems management . . . . . . . . . . . . 31.1 Business systems management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Tivoli systems management product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 IBM Tivoli Business Systems Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.1 Business system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3.2 Discovery processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.3 Event processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3.4 Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4 Document organization and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.5 Lab environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapter 2. Components and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1 Product structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2 Base services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2.1 Components and data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.2 Installation directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2.3 Windows registry structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.2.4 Log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.3 Distributed resource feeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.3.1 Agent Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.3.2 Common listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.4 Mainframe (z/OS) resource feeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.4.1 OS/390 components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.2 Windows servers connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572.4.3 Object registration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

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

2.4.4 Bulk discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622.4.5 Command support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

2.5 History server, reporting, and health monitor . . . . . . . . . . . . . . . . . . . . . . 682.5.1 History server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682.5.2 The reporting system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.5.3 Health monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Chapter 3. Database structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773.1 Microsoft SQL Server overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783.2 The databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803.3 Object implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.3.1 Important information sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.3.2 Object structure implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823.3.3 Business Systems implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 843.3.4 ROOT, BUSC, and LOBC objects. . . . . . . . . . . . . . . . . . . . . . . . . . . 853.3.5 Object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.4 Status propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873.5 Agent listener resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3.5.1 Class implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913.5.2 AMS tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

3.6 Common listener resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953.7 Menu and command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

3.7.1 Menu, menu item, and launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973.7.2 z/OS subsystems command support . . . . . . . . . . . . . . . . . . . . . . . 1023.7.3 Tivoli task support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Chapter 4. User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1134.1 Java console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144.2 Web console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Chapter 5. Implementation planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295.1 Planning overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305.2 Personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305.3 Hardware specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325.4 Network and connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335.5 Software level and prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.5.1 Planning for distributed systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 1345.5.2 Planning for mainframe systems. . . . . . . . . . . . . . . . . . . . . . . . . . . 135

5.6 Operators and users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385.7 Business System requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

5.7.1 Business System View theory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395.7.2 Business System View design concept. . . . . . . . . . . . . . . . . . . . . . 1395.7.3 Business System View structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

iv Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

Part 2. Distributed implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Chapter 6. Base services implementation . . . . . . . . . . . . . . . . . . . . . . . . 1496.1 Hardware and software prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

6.1.1 Hardware configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1506.1.2 Software components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1516.1.3 Hardware and software configuration for this book. . . . . . . . . . . . . 152

6.2 Prerequisite software components installation . . . . . . . . . . . . . . . . . . . . 1546.2.1 Operating system: Windows 2000 Server . . . . . . . . . . . . . . . . . . . . 1546.2.2 MKS Toolkit for Systems Administrators Version 7.5 or 8.0 . . . . . . 1556.2.3 Windows Resource Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556.2.4 JDBC Driver: Microsoft SQL 2000 Driver for JDBC . . . . . . . . . . . . 1556.2.5 Microsoft IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556.2.6 Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

6.3 Database server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1766.4 Console and propagation server installation . . . . . . . . . . . . . . . . . . . . . . 1906.5 History server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1946.6 Health Monitor Server implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 199

6.6.1 HMS Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1996.6.2 Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2026.6.3 Health Monitor Client implementation . . . . . . . . . . . . . . . . . . . . . . . 208

Chapter 7. TEC components integration. . . . . . . . . . . . . . . . . . . . . . . . . . 2097.1 Tivoli Enterprise Console overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2107.2 Setting up the TEC connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

7.2.1 Installing event enablement and the task server . . . . . . . . . . . . . . . 2117.2.2 Setting up the user ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2137.2.3 Updating the TEC event classes and rules . . . . . . . . . . . . . . . . . . . 2177.2.4 Enabling TBSM agent listener. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

7.3 IBM Tivoli Monitoring modules integration . . . . . . . . . . . . . . . . . . . . . . . 2267.4 Creating a generic component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2307.5 Defining a component from DM monitors . . . . . . . . . . . . . . . . . . . . . . . . 2357.6 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Chapter 8. IBM Tivoli Monitoring integration . . . . . . . . . . . . . . . . . . . . . . 2498.1 IBM Tivoli Monitoring integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2508.2 Adapter installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

8.2.1 Installing JRE 1.3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2528.2.2 Installing the TBSM adapter for ITM . . . . . . . . . . . . . . . . . . . . . . . . 2548.2.3 TBSM adapter processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2568.2.4 Configuring the IBM Tivoli Monitoring for 5.1.1 TBSM Adapter . . . 259

8.3 Using the TBSM adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2618.3.1 Discovery process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2618.3.2 Event forwarding to Tivoli Business Systems Manager . . . . . . . . . 264

Contents v

8.4 Tracing an event to the Common Listener . . . . . . . . . . . . . . . . . . . . . . . 268

Chapter 9. IBM Tivoli NetView integration . . . . . . . . . . . . . . . . . . . . . . . . 2799.1 What IBM Tivoli NetView is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2809.2 NetView 7.1.3 installation and configuration . . . . . . . . . . . . . . . . . . . . . . 283

9.2.1 Installation prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2839.2.2 Suggested configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

9.3 Adapter installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2919.3.1 Installing the NetView part of the adapter . . . . . . . . . . . . . . . . . . . . 2929.3.2 Installing the TBSM part of the adapter. . . . . . . . . . . . . . . . . . . . . . 293

9.4 NetView adapter configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2939.5 Using the adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

9.5.1 Bulk discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2959.5.2 How NetView resources are handled . . . . . . . . . . . . . . . . . . . . . . . 2979.5.3 Launching NetView Web console from TBSM . . . . . . . . . . . . . . . . 303

9.6 Troubleshooting the environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3059.6.1 TBSM adapter basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3059.6.2 TBSM communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3079.6.3 Testing the launch functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3089.6.4 TBSM adapter log and trace files . . . . . . . . . . . . . . . . . . . . . . . . . . 309

9.7 Extending the menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3119.7.1 Extending the NetView Web console . . . . . . . . . . . . . . . . . . . . . . . 3129.7.2 Extending the TBSM Java console . . . . . . . . . . . . . . . . . . . . . . . . . 319

Part 3. z/OS integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Chapter 10. z/OS installation and configuration . . . . . . . . . . . . . . . . . . . 33110.1 Source/390 implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

10.1.1 Pre-installation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33210.1.2 Installing Source/390. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33310.1.3 Bulk discovery configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33710.1.4 Source/390 tuning considerations. . . . . . . . . . . . . . . . . . . . . . . . . 33710.1.5 Source/390 security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

10.2 Setting up Tivoli NetView for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33810.2.1 Modify the NetView started task procedure . . . . . . . . . . . . . . . . . 33910.2.2 Modify the DSIPARM members . . . . . . . . . . . . . . . . . . . . . . . . . . 33910.2.3 Enable the PPI connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33910.2.4 Enable NETCONV connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 34010.2.5 Enabling communication between NetView systems . . . . . . . . . . 34110.2.6 Tuning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

10.3 Implementing the Event Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

Chapter 11. z/OS data feeds and discovery . . . . . . . . . . . . . . . . . . . . . . . 34711.1 z/OS data feeds overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

vi Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

11.2 System Automation for OS/390 Version 2.1 . . . . . . . . . . . . . . . . . . . . . 34911.2.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34911.2.2 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35011.2.3 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

11.3 Database 2 (DB2) for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35311.3.1 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35411.3.2 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

11.4 Information Management System (IMS) . . . . . . . . . . . . . . . . . . . . . . . . 35711.4.1 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35711.4.2 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

11.5 CICSPlex System Manager Version 2.2 . . . . . . . . . . . . . . . . . . . . . . . . 36111.5.1 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36111.5.2 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

11.6 Tivoli Workload Scheduler for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . 37211.6.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37211.6.2 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37311.6.3 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

11.7 Resource Object Data Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37611.7.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37711.7.2 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37711.7.3 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

11.8 Resource Measurement Facility (RMF). . . . . . . . . . . . . . . . . . . . . . . . . 38111.8.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38111.8.2 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

11.9 System Managed Storage (SMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38511.9.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38511.9.2 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

11.10 DFSMS Hierarchical Storage Manager . . . . . . . . . . . . . . . . . . . . . . . . 38811.10.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38811.10.2 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

11.11 WebSphere HTTP Server for OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . 39111.11.1 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39111.11.2 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

Part 4. Advanced configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

Chapter 12. Automatic Business System View creation . . . . . . . . . . . . . 39512.1 Automatic Business System View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

12.1.1 Automatic Business Systems design . . . . . . . . . . . . . . . . . . . . . . 39612.1.2 Automatic Business Systems configuration file. . . . . . . . . . . . . . . 39712.1.3 Defining the Automatic Business System . . . . . . . . . . . . . . . . . . . 402

12.2 ABS usage example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40312.2.1 Manual creation of the business system view. . . . . . . . . . . . . . . . 403

Contents vii

12.2.2 BSV creation tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40712.3 Distributed LOB rules to ABS migration . . . . . . . . . . . . . . . . . . . . . . . . 414

12.3.1 Migration description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41412.3.2 Migration example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

Chapter 13. Setting up roles and security. . . . . . . . . . . . . . . . . . . . . . . . . 42113.1 Resource security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

13.1.1 Protecting files and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . 42213.1.2 Protecting the registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42613.1.3 Windows user ID and groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429

13.2 Password protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43013.2.1 TBSM processes passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43013.2.2 Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43213.2.3 Reporting system password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

13.3 TBSM command security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43313.4 TBSM operators and workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434

Chapter 14. Maintenance and tuning issues . . . . . . . . . . . . . . . . . . . . . . 43714.1 SQL Server Agent jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

14.1.1 z/OS-related jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43814.1.2 Distributed resources jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44014.1.3 Database maintenance jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440

14.2 Database maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44514.2.1 Database statistic and check . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44514.2.2 Database Maintenance Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

14.3 Microsoft SQL Server and Windows 2000 tuning . . . . . . . . . . . . . . . . . 45814.3.1 Windows 2000 Advanced Server tuning . . . . . . . . . . . . . . . . . . . . 45814.3.2 Microsoft SQL Server 2000 tuning . . . . . . . . . . . . . . . . . . . . . . . . 462

Chapter 15. Automatic problem ticketing . . . . . . . . . . . . . . . . . . . . . . . . . 46515.1 Automatic problem ticketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46615.2 Defining the auto ticketing rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46715.3 Tivoli Information Management for z/OS integration overview . . . . . . . 46915.4 Installation and configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471

15.4.1 Enable problem management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47115.4.2 Extract and customize the input-output processor . . . . . . . . . . . . 47415.4.3 Setting up the task server and Tivoli NetView for z/OS . . . . . . . . 47515.4.4 Application customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

15.5 Using the problem ticket interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49915.5.1 Manual problem ticket operation . . . . . . . . . . . . . . . . . . . . . . . . . . 49915.5.2 Closing a problem ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

Chapter 16. High availability and failover . . . . . . . . . . . . . . . . . . . . . . . . . 51316.1 Failover concept and terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514

viii Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

16.2 Implementation of failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51516.2.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51516.2.2 Installation and customization of failover . . . . . . . . . . . . . . . . . . . 51616.2.3 Setup for z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

16.3 Performing failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52116.3.1 Enabling failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52216.3.2 Enabling reverse failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522

16.4 Limitations and discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52316.5 Troubleshooting tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

Chapter 17. Historical reporting with TEDW . . . . . . . . . . . . . . . . . . . . . . . 52717.1 Tivoli Enterprise Data Warehouse overview . . . . . . . . . . . . . . . . . . . . . 528

17.1.1 Tivoli Enterprise Data Warehouse concepts and components . . . 52917.1.2 IBM Tivoli Business Systems Manager integration . . . . . . . . . . . . 532

17.2 Installation and configuration for data warehouse. . . . . . . . . . . . . . . . . 53317.2.1 Warehouse integration pre-installation steps . . . . . . . . . . . . . . . . 53317.2.2 Setting up the source ETL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

17.3 Activating collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53817.3.1 Changes on the TWH_CDW database . . . . . . . . . . . . . . . . . . . . . 53917.3.2 Creating an ODBC connection to source database . . . . . . . . . . . 53917.3.3 Defining authority to the Warehouse Sources and Targets . . . . . 54317.3.4 Scheduling the source ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54817.3.5 Changing the source ETL status to Production. . . . . . . . . . . . . . . 55117.3.6 Running ETLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552

Part 5. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553

Appendix A. Detailed process flow of services . . . . . . . . . . . . . . . . . . . . 555

Appendix B. Sample files and scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557The gemmfprod.sh script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558High-level load sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560

ASILoad_Highlevel.ksh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560ITSO_Highlevel - Sample high-level load source . . . . . . . . . . . . . . . . . . . 564

Appendix C. IBM Tivoli NetView additional information . . . . . . . . . . . . . 565NetView adapter configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566

The nvid.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566The topxlistener.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566The topxtrapgate.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569

TBSM adapter files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571Launch menu item add and delete script . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572NetView Web Server script 3beansalad.js . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

Contents ix

Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577

System requirements for downloading the Web material . . . . . . . . . . . . . 578How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583

Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584

IBM Redbooks collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585

x Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

Figures

1-1 Tivoli software product pillars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51-2 Tivoli performance and availability solutions . . . . . . . . . . . . . . . . . . . . . . 61-3 TBSM console: propagation path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121-4 TBSM console: tree view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141-5 TBSM console: Hyperview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151-6 TBSM console: Table view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161-7 TBSM console: Business impact view . . . . . . . . . . . . . . . . . . . . . . . . . . 171-8 TBSM console: events view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181-9 TBSM properties window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191-10 TBSM Web console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201-11 Network diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222-1 IBM Tivoli Business Systems Manager product structure . . . . . . . . . . . 262-2 TBSM flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302-3 IBM Tivoli Business Systems Manager Windows directory structure . . 392-4 Registry tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412-5 Hierarchical setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422-6 Database setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432-7 Flowchart for distributed system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462-8 AMS description files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472-9 Common listener connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512-10 z/OS components and feeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532-11 TBSM data server startup log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552-12 TBSM object server startup log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562-13 TBSM object pump startup log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572-14 Connection from z/OS to TBSM servers . . . . . . . . . . . . . . . . . . . . . . . . 582-15 Initial conversation for TBSM connection. . . . . . . . . . . . . . . . . . . . . . . . 602-16 Sample message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612-17 Queue file contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612-18 The Resources view after the high-level object load . . . . . . . . . . . . . . . 642-19 Parameters of the GTMAOPE0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652-20 MVSIPListener registry definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662-21 Command aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672-22 History server setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692-23 Microsoft IIS virtual directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702-24 Reporting system invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712-25 Object Event Report Selection screen . . . . . . . . . . . . . . . . . . . . . . . . . . 722-26 A generated report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732-27 Health monitor client window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

© Copyright IBM Corp. 2003. All rights reserved. xi

2-28 Registry Editor for Health Monitoring profile . . . . . . . . . . . . . . . . . . . . . 753-1 Microsoft SQL Server Enterprise Manager . . . . . . . . . . . . . . . . . . . . . . 793-2 Part of TBSM containment hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 863-3 TBSM inheritance hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873-4 The propagation concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883-5 Propagation algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903-6 GEM object classes in TBSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913-7 Tables for CID G02H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923-8 GEMLookupCID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933-9 GEM_IDlookup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943-10 GEM_DMtoCID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953-11 CL_Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963-12 Common listener auto placement table . . . . . . . . . . . . . . . . . . . . . . . . . 963-13 CL_Severities content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973-14 Default context menu for DB2InstanceManager . . . . . . . . . . . . . . . . . . 983-15 Context menu processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993-16 Running the asisp_definemenuitem. . . . . . . . . . . . . . . . . . . . . . . . . . . 1053-17 Invoke MVS D A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063-18 Task setting window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073-19 Tivoli NetView for z/OS prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1073-20 Task Monitor result window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083-21 Context menu for DIRCDrv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113-22 Execution result for DIRCDrv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124-1 Java console structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144-2 IBM Tivoli Business Systems Manager icon . . . . . . . . . . . . . . . . . . . . 1144-3 IBM Tivoli Business Systems Manager sign-on dialog . . . . . . . . . . . . 1154-4 Welcome screen for IBM Tivoli Business Systems Manager. . . . . . . . 1154-5 Primary Menu for Super Administrator. . . . . . . . . . . . . . . . . . . . . . . . . 1164-6 Expanded console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1174-7 Property page of a DB2InstanceManager object . . . . . . . . . . . . . . . . . 1184-8 Expanded console in debug mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194-9 Sign on to the IBM Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1214-10 Welcome screen of the Web console . . . . . . . . . . . . . . . . . . . . . . . . . 1224-11 Primary options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234-12 User profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244-13 User roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1254-14 TBSM Sign On screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264-15 Business System View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1274-16 All Resources View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285-1 Flat BSV for Remote Banking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415-2 Hierarchical BSV for Remote Banking . . . . . . . . . . . . . . . . . . . . . . . . . 1425-3 Inverted hierarchy BSV for Remote Banking . . . . . . . . . . . . . . . . . . . . 1435-4 Grouped resource BSV for Remote Banking . . . . . . . . . . . . . . . . . . . . 144

xii Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

6-1 InstallShield Welcome dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576-2 Computer Name dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576-3 Installation Selection dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1586-4 User Information dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596-5 Software License Agreement dialog . . . . . . . . . . . . . . . . . . . . . . . . . . 1596-6 Installation Definition dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1606-7 Instance Name dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616-8 Setup Type dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1626-9 Choose Folder dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636-10 Select Components dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636-11 Services Account dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646-12 Authentication Mode dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1656-13 Collation Settings dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1666-14 Network Libraries dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676-15 Start Copying Files dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1686-16 Choose Licensing Mode dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696-17 SQL Server Enterprise Manager view . . . . . . . . . . . . . . . . . . . . . . . . . 1706-18 SQL Server Security options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706-19 Change password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716-20 Password confirmation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716-21 Log on to SQL Query Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736-22 Current Connection Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736-23 Connection Properties options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1746-24 Opening the Options menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1756-25 Tools Options dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1766-26 Language selection dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1776-27 System File Update welcome screen. . . . . . . . . . . . . . . . . . . . . . . . . . 1776-28 Temporary directory selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786-29 System File Upgrade complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1796-30 Welcome dialog for TBSM installation . . . . . . . . . . . . . . . . . . . . . . . . . 1806-31 License agreement dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1806-32 Setup path selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1816-33 Setup type selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1826-34 Select Components for database server . . . . . . . . . . . . . . . . . . . . . . . 1836-35 Enter Information for SQL database server host name . . . . . . . . . . . . 1846-36 Database parameters dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1856-37 Database upgrade dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1866-38 Start copying files dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1876-39 Setup Complete dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1876-40 Extract seed database files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1886-41 Changes in AttachDatabases.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1896-42 Services setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1906-43 Component selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Figures xiii

6-44 Create local groups dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1926-45 JDBC driver selection dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1926-46 Installation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1936-47 Services list for console and propagation server . . . . . . . . . . . . . . . . . 1946-48 TBSM operators groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1946-49 History Server component selection dialog . . . . . . . . . . . . . . . . . . . . . 1956-50 Creating a new database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1966-51 History database properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1976-52 Pop-up message for historyserversetup.ksh . . . . . . . . . . . . . . . . . . . . 1976-53 Health Monitor Server component selection dialog . . . . . . . . . . . . . . . 2006-54 Health Monitor Server host name dialog . . . . . . . . . . . . . . . . . . . . . . . 2016-55 Health Monitor Server parameters dialog . . . . . . . . . . . . . . . . . . . . . . 2026-56 Open the Properties dialog for Health Monitor. . . . . . . . . . . . . . . . . . . 2036-57 Health Monitor Log On tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2046-58 Health monitor profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2056-59 Default services definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2066-60 Settings for Common Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2076-61 MonitoredQueueTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2087-1 Event flow for IBM Tivoli Business Systems Manager integration . . . . 2107-2 Install Product window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2127-3 Services window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2137-4 Local Security Settings window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2147-5 Security setting dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2157-6 Tivoli BSM Event Enablement Properties window . . . . . . . . . . . . . . . . 2167-7 TME Desktop of Administrator window . . . . . . . . . . . . . . . . . . . . . . . . 2177-8 Event Server Rule Bases window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2217-9 Import Into Rule Base window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2227-10 TBSM console: All Resources - Descendents window . . . . . . . . . . . . 2297-11 GEMLookupCID content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2317-12 New generic test object created. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2347-13 Properties window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2357-14 Flow diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2377-15 Event Viewer: Group All - All events . . . . . . . . . . . . . . . . . . . . . . . . . . 2387-16 All Resources - Descendents window . . . . . . . . . . . . . . . . . . . . . . . . . 2397-17 Note editor for closing an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2408-1 IBM Tivoli Business Systems Manager for ITM diagram . . . . . . . . . . . 2518-2 Installing JRE 1.3.0 via GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2538-3 Install Product window, ITM adapter for TBSM . . . . . . . . . . . . . . . . . . 2558-4 Install Options window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2568-5 IBM Tivoli Business Systems Manager console window . . . . . . . . . . . 2638-6 Instrumentation mapping to enterprise . . . . . . . . . . . . . . . . . . . . . . . . 2648-7 Profile Properties window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2658-8 Indications and Actions window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

xiv Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

8-9 All Resources - Descendants window . . . . . . . . . . . . . . . . . . . . . . . . . 2678-10 Windows 2000 - Properties window. . . . . . . . . . . . . . . . . . . . . . . . . . . 2688-11 SQL Window: Query-ibmtiv5.Object.sa . . . . . . . . . . . . . . . . . . . . . . . . 2758-12 SQL Window: Query-ibmtiv5.object.sa . . . . . . . . . . . . . . . . . . . . . . . . 2769-1 NetView’s main capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2809-2 The NetView Web console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2829-3 Invoking Web console Security from nvsetup . . . . . . . . . . . . . . . . . . . 2869-4 The Web Console Security dialog box. . . . . . . . . . . . . . . . . . . . . . . . . 2879-5 The Add User dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2879-6 The NetView Web Console download page . . . . . . . . . . . . . . . . . . . . 2889-7 Changing the default path for the NetView Web Console . . . . . . . . . . 2899-8 Web Console login dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2909-9 Open a map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2919-10 The TBSM Bulk Upload entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2969-11 NetViews bulk upload message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2979-12 The initial NetView Map contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2989-13 Initial NetView resources uploaded to TBSM. . . . . . . . . . . . . . . . . . . . 2999-14 Hyperview view of NetView resources. . . . . . . . . . . . . . . . . . . . . . . . . 3009-15 The final discovery in NetView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3019-16 The corresponding TBSM hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 3029-17 Various network views in TBSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3039-18 TBSMs Launch submenu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3049-19 The Web Console Launch results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3059-20 Launch error message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3089-21 The Roles dialog with the new menu entry . . . . . . . . . . . . . . . . . . . . . 3179-22 Parsing error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3179-23 NetView Web console and the new menu . . . . . . . . . . . . . . . . . . . . . . 3189-24 The resulting output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3199-25 The Launch submenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3209-26 NetView Console launch process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3219-27 3beansalad.js display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3239-28 The new menu entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3269-29 The Web console display launched by the new menu . . . . . . . . . . . . . 32710-1 Property page of OS object to enable upload . . . . . . . . . . . . . . . . . . . 34411-1 Feeds for z/OS systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34811-2 System Automation for OS/390 2.1 connection to TBSM . . . . . . . . . . 35011-3 Subsystem objects from System Automation for OS/390 . . . . . . . . . . 35311-4 DB2 topology display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35711-5 IMS descendants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36111-6 CPSM main panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36311-7 View selection panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36311-8 RTASPEC panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36411-9 Real time analysis specification update . . . . . . . . . . . . . . . . . . . . . . . . 364

Figures xv

11-10 Action definition selection panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36511-11 Creating TBSMA1 action definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 36611-12 Updated action definition list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36611-13 CICSPlex System Manager panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36711-14 CPSM primary option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36811-15 BATCHREP display panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36811-16 BATCHREP submission panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36911-17 Property of a CICSPlex definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37011-18 Initiating CICSPlex SM discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37111-19 CICSPlex SM CICS Topology display . . . . . . . . . . . . . . . . . . . . . . . . . 37211-20 Detailed operation information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37411-21 Inserting SNA APPN network object . . . . . . . . . . . . . . . . . . . . . . . . . . 37811-22 Setting the NetID name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37911-23 Setting the OS path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37911-24 SNA topology view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38111-25 Event flow and component descriptions for TBSM/RMF integration . . 38211-26 Invoking RMF registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38411-27 SMS information flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38511-28 Register monitoring interval for SMS resources . . . . . . . . . . . . . . . . . 38711-29 Disk configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38811-30 Creating an HSM object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38911-31 HSM creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39011-32 DFSMShsm topology view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39111-33 HTTP Server objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39212-1 ABS processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39612-2 Sample business system view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40312-3 Database tables with the loaded ABS configuration . . . . . . . . . . . . . . 40512-4 ITSO RESOURCES business system view . . . . . . . . . . . . . . . . . . . . . 40612-5 ABSMain window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40812-6 First BSV ITSO Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40912-7 BSV tree for the example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41012-8 Adding Production OS filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41112-9 Defining condition for production OS . . . . . . . . . . . . . . . . . . . . . . . . . . 41212-10 Condition for Production DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41312-11 Distributed Line of Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41512-12 GEM_InstFiltering table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41512-13 Table GEM_Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41913-1 Changing TivoliManager directory’s property . . . . . . . . . . . . . . . . . . . 42313-2 Sharing property for the TivoliManager directory . . . . . . . . . . . . . . . . . 42413-3 Security property of TivoliManager directory . . . . . . . . . . . . . . . . . . . . 42513-4 Advanced security setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42613-5 Protecting TBSM registry key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42713-6 TBSM registry permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

xvi Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

13-7 Advanced permissions setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42913-8 Automatic logon for Event Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43113-9 Historical database users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43313-10 Extract of the MenuItem table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43413-11 Saving a workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43513-12 Opening a workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43513-13 Editing a workspace permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43614-1 Cleanup Old Log Files job window. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44114-2 Delete Old MVS Upload Output Files window . . . . . . . . . . . . . . . . . . . 44314-3 Cleanup Old DB Queues window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44514-4 Update ObjectEvents stats job wIndow . . . . . . . . . . . . . . . . . . . . . . . . 44614-5 Update Object Stats job wIndow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44714-6 Database Maintenance Plan creation . . . . . . . . . . . . . . . . . . . . . . . . . 44814-7 Database Maintenance Plan Wizard: Welcome. . . . . . . . . . . . . . . . . . 44914-8 Database Maintenance Plan Wizard: Select Databases . . . . . . . . . . . 45014-9 Database Maintenance Plan Wizard: Data Optimization settings . . . . 45114-10 Database Maintenance Plan Wizard: Database Integrity Check . . . . . 45214-11 Database Maintenance Plan Wizard: Backup settings . . . . . . . . . . . . 45314-12 Database Maintenance Plan Wizard: Backup Disk Directory settings . 45414-13 Database Maintenance Plan Wizard: Transaction Log Backup settings45514-14 Database Maintenance Plan Wizard: Reports to Generate . . . . . . . . . 45614-15 Database Maintenance Plan Wizard: Maintenance Plan History. . . . . 45714-16 Database Maintenance Plan Wizard summary . . . . . . . . . . . . . . . . . . 45814-17 Windows 2000 System Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45914-18 Windows2000 Performance Options . . . . . . . . . . . . . . . . . . . . . . . . . . 45914-19 Windows 2000 Local Area Connection Properties. . . . . . . . . . . . . . . . 46014-20 Windows 2000 File and Printers Sharing Properties . . . . . . . . . . . . . . 46114-21 SQL Server Properties Memory window . . . . . . . . . . . . . . . . . . . . . . . 46214-22 SQL Server Properties Processor window. . . . . . . . . . . . . . . . . . . . . . 46315-1 Problem and change management interface . . . . . . . . . . . . . . . . . . . . 46615-2 Data flow: TBSM operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47015-3 TBSM event ID assisted entry panel . . . . . . . . . . . . . . . . . . . . . . . . . . 47815-4 IBM Tivoli Business Systems Manager class ID assisted entry panel . 47915-5 Tivoli Information Management for z/OS s-word display . . . . . . . . . . . 48015-6 Tivoli Information Management for z/OS p-word display . . . . . . . . . . . 48015-7 Users to notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48115-8 Deleting of the BRANCH control line . . . . . . . . . . . . . . . . . . . . . . . . . . 48215-9 Change DEFAULT to MVS user ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 48315-10 Control panel update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48515-11 Function line summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48615-12 First line option 1: Control flow processing . . . . . . . . . . . . . . . . . . . . . 48715-13 First line oOption 2: Data collection processing. . . . . . . . . . . . . . . . . . 48815-14 First line option 3: Test data processing . . . . . . . . . . . . . . . . . . . . . . . 488

Figures xvii

15-15 Second line option 1: Control flow processing . . . . . . . . . . . . . . . . . . . 48915-16 Second line option 2: Data collection processing . . . . . . . . . . . . . . . . 49015-17 Second line option 3: Test data processing . . . . . . . . . . . . . . . . . . . . . 49015-18 Third line option 1: Control flow processing . . . . . . . . . . . . . . . . . . . . . 49115-19 Third line option 2: Data collection processing . . . . . . . . . . . . . . . . . . 49215-20 Third line option 3: Test data processing . . . . . . . . . . . . . . . . . . . . . . . 49215-21 Fourth line option 1: Control flow processing. . . . . . . . . . . . . . . . . . . . 49315-22 Fourth line option 2: Data collection processing . . . . . . . . . . . . . . . . . 49415-23 Fourth line option 3: Test data processing. . . . . . . . . . . . . . . . . . . . . . 49415-24 Fifth line option 1: Control flow processing . . . . . . . . . . . . . . . . . . . . . 49515-25 Fifth line option 2: Data collection processing . . . . . . . . . . . . . . . . . . . 49615-26 Fifth line option 3:Test data processing . . . . . . . . . . . . . . . . . . . . . . . . 49615-27 Panel list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49715-28 List of modified panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49815-29 Panel Copy specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49815-30 Problem ticket creation dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50015-31 Authentication dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50115-32 Problem ticket created . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50115-33 Problem ticket icon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50215-34 Tivoli Information Management for z/OS with the problem ticket. . . . . 50315-35 Searching for a problem ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50415-36 Problem ticket list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50515-37 Problem ticket window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50615-38 Problem ticket updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50715-39 Creating new problem ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50815-40 Searching Tivoli Information Management for ticket no 00000009 . . . 50915-41 Search result for ticket no 00000009 . . . . . . . . . . . . . . . . . . . . . . . . . . 50915-42 Closing problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51015-43 Closing problem dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51117-1 A typical Tivoli Enterprise Data Warehouse environment . . . . . . . . . . 52917-2 IBM Tivoli Business Systems Manager warehouse component . . . . . 53217-3 Installation type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53517-4 Path to the installation media for the GTM. . . . . . . . . . . . . . . . . . . . . . 53617-5 IBM Tivoli Business Systems Manager program installation . . . . . . . . 53717-6 IBM Tivoli Business Systems Manager ETL Installation summary . . . 53817-7 System DSN tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54017-8 Selecting the data source for ODBC System DSN . . . . . . . . . . . . . . . 54117-9 SQL Server data source settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54117-10 User authentication for the new data source . . . . . . . . . . . . . . . . . . . . 54217-11 Other options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54217-12 Completing the data source definition . . . . . . . . . . . . . . . . . . . . . . . . . 54317-13 IBM Tivoli Monitoring Version 5.1.1 Generic ETL1 Sources . . . . . . . . 54417-14 GTM_OBJECT_Source user ID information . . . . . . . . . . . . . . . . . . . . 545

xviii Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

17-15 IBM Tivoli Business Systems Manager ETL target . . . . . . . . . . . . . . . 54617-16 GTM_TWH_CDW_Target user ID information . . . . . . . . . . . . . . . . . . 54717-17 GTM_c05_LOBState_Process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 54817-18 Schedule GTM_c05_s010_Load_LOBStage . . . . . . . . . . . . . . . . . . . . 54917-19 Schedule configuration for GTM_c05_s010_Load_LOBStage . . . . . . 55017-20 Promoting scheduled processes to Production status . . . . . . . . . . . . . 55117-21 Work in Progress window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552A-1 Detailed services diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556

Figures xix

xx Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

Tables

1-1 Reading paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211-2 Operating system and software detail . . . . . . . . . . . . . . . . . . . . . . . . . . 222-1 IBM Tivoli Business Systems Manager services by component . . . . . . 312-2 TBSM services log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432-3 AMS types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482-4 TEC exits for event forwarding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495-1 List of mainframe information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1365-2 Subsystem naming convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375-3 IMS subsystems checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375-4 DB2 subsystems checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1375-5 CICS subsystems checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385-6 Pro and cons of BSVs creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456-1 Required hardware configuration for TBSM. . . . . . . . . . . . . . . . . . . . . 1516-2 TBSM server configuration running in the lab . . . . . . . . . . . . . . . . . . . 1526-3 Prerequisite software components installed . . . . . . . . . . . . . . . . . . . . 1536-4 Database attributes for reporting system . . . . . . . . . . . . . . . . . . . . . . . 1997-1 IBM Tivoli Monitoring tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2299-1 nvid keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29410-1 z/OS data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33310-2 Modification to IBM Tivoli NetView for z/OS startup procedure . . . . . . 33911-1 TBSM batch jobs for SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38612-1 Distributed rules not supported by the migration script . . . . . . . . . . . . 41614-1 z/OS Resources SQL jobs: suggested settings . . . . . . . . . . . . . . . . . . 43814-2 Distributed Resources Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44014-3 Database Maintenance Jobs suggested settings . . . . . . . . . . . . . . . . 44014-4 Queues tables cleaned up by the Cleanup Old DB Queue job . . . . . . 44415-1 Problem management parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47115-2 Create a problem ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499

© Copyright IBM Corp. 2003. All rights reserved. xxi

xxii Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

Notices

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

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

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

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

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

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

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

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

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

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

© Copyright IBM Corp. 2003. All rights reserved. xxiii

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

AIX®CICS®CICSPlex®Database 2™DB2®DFS™DFSMShsm™Domino™IBM®IBM.COM™IMS™

Informix®Lotus®MVS™NetView®Notes®OS/2®OS/390®OS/400®RACF®Redbooks™Redbooks (logo)™

RMF™Tivoli®Tivoli Enterprise™Tivoli Enterprise Console®Tivoli Management Environment®TME®TME 10™VTAM®WebSphere®z/OS™

The following terms are trademarks of other companies:

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both.

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

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

C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC.

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

xxiv Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

Preface

This IBM® Redbook gives a broad understanding of the IBM Tivoli Business Systems Manager architecture and internals. The in-depth discussion covers the product’s inner workings and includes log files to illustrate the processing of its various components.

IBM Tivoli Business Systems Manager is designed to display all aspects of the enterprise’s IT system as they affect the users’ business systems. This book enables easy implementation of IBM Tivoli Business Systems Manager in distributed environments. Procedures are illustrated with examples of the installation and configuration process to explain the deployment of IBM Tivoli Business Systems Manager into a customer’s environment.

It also covers the implementation of IBM Tivoli Business Systems Manager in z/OS™ with most of its major interfaces. IBM Tivoli Business Systems Manager can monitor all major IBM subsystems in z/OS including IMS™, DB2®, CICS®, storage, and Web solutions.

A book about concepts and implementation would not be complete without a comprehensive discussion about using, maintaining, and troubleshooting the system. We devote several sections to these topics.

The team that wrote this redbookThis redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center.

Budi Darmawan is a Project Leader at the International Technical Support Organization, Austin Center. He writes extensively and teaches IBM classes worldwide on all areas of systems management, database systems, and business intelligence. Before joining the ITSO in 1999, Budi worked in Integrated Solution Services for IBM Indonesia as lead solution architect and implementer. His current interests are in performance and availability and business systems management.

Alessio D’Amico works as a Technical Consulting IT Specialist for the EMEA South Region TBSM services team. He joined IBM in 1998 as a Tivoli® Software Engineer covering various positions including level 3 customer support and development. He moved to the TBSM services team in 2001.

© Copyright IBM Corp. 2003. All rights reserved. xxv

Cedric Foo works as a Technical Consulting IT Specialist for Tivoli Software at IBM United Kingdom. Before joining the Pan EMEA TBSM Services Team two and a half years ago, Cedric worked as an OS/390® specialist in the ITS North Region Enterprise Assist Technical Support team for more than two years. He has more than 22 years of IT experience, from small, specialized subsystems to large mainframe complexes.

Peter Glasmacher is a certified Systems Management Expert professional from Dortmund, Germany. After joining IBM in 1973, he worked in various positions including support, development, and services covering multiple OS platforms and networking architectures. Currently, he works as a consulting IT specialist for the Integrated Technology Services branch of IBM Global Services, concentrating on infrastructure and security issues. He has more than 15 years of experience in the network and systems management areas. For the past eight years, he concentrated on architectural work and the design of network and systems management solutions in large customer environments. Since 1983, he has written extensively on workstation-related issues, both external and internal. He has authored or co-authored a number of Redbooks covering network and systems management topics.

Stephen Nosbisch is a Senior IT Specialist from Boulder, Colorado. His current assignment includes developing architectual design solutions for enterprise wide automation platforms within SDC-West for both IBM internal and commercial accounts. He has more than 15 years of experience in the network and systems management areas. For the past two years he has focused heavily on business systems management solutions.

Samson Yiu is a Senior IT Specialist working with the IBM Support Centre in Australia. He holds a degree in Computer and Mathematical Sciences as well as professional certification as an MCP+Internet, MCSE, Tivoli Enterprise™ Consultant, Citrix, and IBM Certified Systems Expert. He has worked for IBM Australia for 10 years, primarily in software defect support, and is a senior member of the Tivoli PACO support team. His time is spent exclusively supporting Tivoli products. This is the fifth book to which he has contributed.

xxvi Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

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

Betsy ThaggardInternational Technical Support Organization, Austin Center

Pam Geiger, Mike OdomIBM Tivoli Software Group

Jessie Zhang, Vivian RobertsIBM Australia

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

Preface xxvii

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

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

ibm.com/redbooks/residencies.html

Comments welcomeYour comments are important to us!

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

� Use the Contact us Review Redbook form found online at:

ibm.com/redbooks

� Send your comments in an Internet note to:

[email protected]

� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. 0SJB Building 003 Internal Zip 283411400 Burnet RoadAustin, Texas 78758-3493

xxviii Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

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

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

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

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


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

Part 1 Concept and planning

Part 1 provides some background information about and discusses the concept and planning information for IBM Tivoli Business Systems Manager. The chapters are:

� Chapter 1, “Introduction to business systems management,” on page 3 discusses background information and the environment setup that we used for the project. This chapter also provides a guide for using this redbook.

� Chapter 2, “Components and functions,” on page 25 explains in-depth the components and functions of IBM Tivoli Business Systems Manager.

� Chapter 3, “Database structure,” on page 77 goes into detail about how the IBM Tivoli Business Systems Manager database is organized. Here we also present some component-specific extensions of the database, such as Common Listener, TEC interface, and the Menu system.

Part 1

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

� Chapter 4, “User interface,” on page 113 discusses both available user interfaces for IBM Tivoli Business Systems Manager: the Java console and the Web console.

� Chapter 5, “Implementation planning,” on page 129 explains information that you must prepare and understand before starting IBM Tivoli Business Systems Manager implementation.

2 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

Chapter 1. Introduction to business systems management

This chapter presents some basic information about business systems management with IBM Tivoli Business Systems Manager and introduces the rest of the book with the description of the environment that we use in examples. The sections are:

� 1.1, “Business systems management” on page 4 explains the value of business systems management.

� 1.2, “Tivoli systems management product” on page 5 describes the Tivoli systems management product structure.

� 1.3, “IBM Tivoli Business Systems Manager” on page 7 explains the features of IBM Tivoli Business Systems Manager.

� 1.4, “Document organization and scope” on page 20 shows how this book is organized and provides some suggestions for using it effectively.

� 1.5, “Lab environment” on page 22 discusses the setup that we use in the examples.

1


1.1 Business systems managementOver the past 20 years we have seen a dramatic increase in complexity in the variety of computer systems and software used to run a business. Gone are the days when a computer system was isolated and used for the single purpose of word processing or producing a spreadsheet. Now we have multiple systems, such as a cluster of database servers, providing a single service, or multiple services provided by a single machine such as a mainframe.

Most often, these computers are all networked to form a single, very complex enterprise. The IT departments that maintain these computers specialize in such infrastructures and have an extensive understanding of how these machines work and how to fix the technology when it breaks.

However, as the environment becomes more complex, business users also want to understand the health of the infrastructure and the IT environment for their particular functions. Each sector of the business may have its own opinion about which machines or resources are most important. All need to understand the state of their operation so they can proactively manage their resources.

The IT department may understand that all resources are important, but most likely would not know the overall impact of each of these resources in the business sense. When multiple resources fail at one time, they may need to prioritize repairs, which means understanding the impact of each single resource on the enterprise’s operations.

These requirements from both the business and the IT department can be addressed together: Business users can see the resources that they are using and how they affect their function, and IT personnel can use a reversed model to see which function from the business user is affected by the resources.

To be able to perform this function, the system must coordinate and collect the status of all IT resources from the different parts of the enterprise using various systems management tools. It also must be able to make an abstraction of the entire business structure that incorporates the IT resources. It also needs interfaces to other parts of the business, such as problem and change management.

We will see how these business and IT needs can be met.


1.2 Tivoli systems management productTivoli, as part of the IBM Software group, provides IT resource management software. The complete systems management approach from Tivoli is grouped into four pillars, as shown in Figure 1-1.

Figure 1-1 Tivoli software product pillars

Underlying the Tivoli solution set is a group of common services and an infrastructure that provides consistency across Tivoli management applications and enables integration.

Within the Tivoli product family, specific solutions target four primary disciplines of systems management: Performance and Availability, Configuration and Operation, Storage Management, and Security. Products within each of these areas have been made available over the years and, through generations of enhancements, have become accepted solutions in enterprises around the world. With these core capabilities in place, IBM has been able to focus on building applications that take advantage of these pillars to provide true business systems management solutions.

With this end-to-end set of solutions built on a common foundation, enterprises can manage the ever-increasing complexity of their IT infrastructures with reduced staff and increasing efficiency.

Tivoli Mgmt SolutionTivoli Mgmt Solution

Common Infrastructure/Services

Business Systems ManagementBusiness Systems Management

PerformancePerformanceandand

AvailabilityAvailability

ConfigurationConfigurationandand

OperationsOperationsSecuritySecurityStorageStorage

MonitoringMonitoring

AnalysisAnalysis

CentralCentralConsoleConsole

ReportingReporting

AccessAccessManagementManagement

IndentityIndentityManagementManagement

RiskRiskManagementManagement

StorageStorageManagementManagement

Storage AreaStorage AreaNetworkNetworkManagementManagement

DataDataProtectionProtection

DisasterDisasterRecoveryRecovery

StorageStorageManagementManagement

Storage AreaStorage AreaNetworkNetworkManagementManagement

DataDataProtectionProtection

DisasterDisasterRecoveryRecovery

CentralizedCentralizedControlControl

ServiceServiceDeliveryDelivery

WebWebManagementManagement

PervasivePervasiveManagementManagement

PerformancePerformanceandand

AvailabilityAvailability

ConfigurationConfigurationandand

OperationsOperationsSecuritySecurityStorageStorage

Chapter 1. Introduction to business systems management 5

In the performance and availability area, products are structured as shown in Figure 1-2.

Figure 1-2 Tivoli performance and availability solutions

The Tivoli performance and availability portfolio is an integrated family of products that span Web, client-server, and host environments and are designed to provide a comprehensive and scalable solution for centralized management of e-business operations. Tivoli can simplify performance and availability management by consolidating and integrating products into three independent layers that offer three distinct types of value, yet provide superior management capabilities when used together. All offerings are designed to help provide out-of-the-box value and rapid return on investment, while minimizing total cost of ownership through high quality and comprehensive functionality.

Tivoli simplifies autonomic prevention and recovery of IT problems at their source with out-of-the-box IBM best practices in the IBM Tivoli Monitoring products (yellow layer). Event correlation and automation products (green layer) provide centralized autonomic prevention and recovery of IT problems that span multiple resources. By providing better root-cause analysis and automated responses to identified problems, these products can help you:

� Eliminate the cost of downtime

Real time Management Predictive Management

Business Impact Management

Event Correlation and Automation

Monitor Systems and Applications

IBM Tivoli Business Systems Manager

IBM Tivoli NetView

IBM Tivoli Monitoring

IBM TivoliService Level

Advisor

IBM TivoliWeb SiteAnalyzer

IBM TivoliEnterprise Data

Warehouse

IBM TivoliEnterprise Console


� Reduce personnel costs

� Improve your return on IT investments

IBM Tivoli Business Systems Manager is a focal-point monitoring solution that provides you with a business view of your IT environment. In the next section we cover how it achieves these goals.

Discussion in this redbook focuses on IBM Tivoli Business Systems Manager and its integration interface to other IBM performance and availability products.

1.3 IBM Tivoli Business Systems ManagerIBM Tivoli Business Systems Manager is an enterprise management product that monitors the data processing resources that are critical to a business application. (We sometimes will refer to it as TBSM, mainly in captions and figures.) It enables end-to-end monitoring of systems, subsystems, applications, and other resources in your enterprise, from OS/390 and z/OS systems to distributed systems. IBM Tivoli Business Systems Manager provides your operations with a view of the system components as they relate to your overall business.

We use IBM Tivoli Business Systems Manager to:

� Construct monitoring views that reflect the enterprise’s current applications and business systems, which can contain a complex mixture of system resources across the entire enterprise.

� Enable real-time monitoring.

� Support existing Tivoli Global Enterprise Manager instrumentation, Tivoli Distributed Monitoring, IBM Tivoli Monitoring, and IBM Tivoli Enterprise Console®.

� Provide an open archtecture to enable third-party product integration.

� Manage business system components on a variety of platforms.

� Provide trend-analysis data for Tivoli Enterprise Data Warehouse.

� Enable effective operation of your entire enterprise.

After resources are defined to or discovered by IBM Tivoli Business Systems Manager, they are registered with IBM Tivoli Business Systems Manager, and the information is stored in an SQL database. You can access the database using a GUI-based console. IBM Tivoli Business Systems Manager monitors for state changes that occur in the various resources within your enterprise. An event management facility helps you determine and troubleshoot system problems that can affect the availability of applications and systems. By applying


rules to events and data collected from various sources, even when business systems span several platforms, IBM Tivoli Business Systems Manager enables you to graphically monitor and control the interconnected business components and operating system resources.

Some new concepts are pertinent to understanding the operation of IBM Tivoli Business Systems Manager:

� Business system

� Discovery Processing

� Event Processing

� Views

1.3.1 Business systemA business system is a group of diverse but interdependent applications and other system resources that interact to accomplish specific business functions. A business system can contain applications or other resources that run on a variety of platforms, including host, distributed, and network environments. For example, a banking business system designed to support transactions over the Web typically includes a Web server running outside the company’s intranet that is connected directly to the Internet and a firewall that provides secure connectivity to a machine running a custom business component, such as loan processing. The loan processing business component usually runs on a distributed platform and interfaces to business components running on a host computer. The host handles all bank transactions. This business system presents challenges to a system manager because it crosses the typically isolated environments of host and distributed systems.

Another example of a business system is an e-mail system. E-mail business systems include all instances of e-mail business components that are being used in your network. You might have a mix of Lotus® Notes®® servers and clients, POP mail or Microsoft® Exchange servers and clients, and other e-mail business components.

An e-mail business system includes definitions that tell whether each of its entities is a server, a client, or both. It also includes definitions of the monitors that collect status information for each component in the business system, as well as definitions of the relationships between the components in the business system.

IBM Tivoli Business Systems Manager enables you to use an automated approach for creating business systems. Using commands provided in IBM Tivoli Business Systems Manager results in faster implementation and completeness


of the business views. When the configuration is completed, the automatically created Business System View continues to monitor the system for the creation of new resources and automatically adds them to the view. In Chapter 12, “Automatic Business System View creation” on page 395, we will cover the creation.

1.3.2 Discovery processingIBM Tivoli Business Systems Manager monitors resources for state changes and performance characteristics that indicate availability. However, before you can monitor resources in your enterprise, the resources must be discovered and registered in the IBM Tivoli Business Systems Manager database, a process that varies depending on the data source.

The process for resources monitored by OS/390 involves running batch jobs that detect the configuration of your resources and update the database. Resources discovered through the Tivoli Enterprise Console require that the classes first be defined in the IBM Tivoli Business Systems Manager database. The resources are then created dynamically as events are received from the Tivoli Enterprise Console. Resources discovered through the common listener interface are dynamically populated through bulk and delta discovery transactions.

IBM Tivoli Business Systems Manager has three discovery processes for z/OS objects:

� Pre-discovery: Batch jobs are run initially when, or before, IBM Tivoli Business Systems Manager is installed and configured.

� Rediscovery: Batch jobs can be customized and run on a scheduled basis to gather updated information about resources in your enterprise.

� Auto-discovery: Programs automatically detect updates, resulting in updates to the database.

The identification or discovery process uses various data sources to initially populate resources in the IBM Tivoli Business Systems Manager database. The z/OS process involves a series of batch functions that create a sequential file, which is then forwarded to the IBM Tivoli Business Systems Manager servers. The data is then processed and stored in the IBM Tivoli Business Systems Manager database. The discovered resources are imported into IBM Tivoli Business Systems Manager in a process called resource registration.

Note: In previous versions of IBM Tivoli Business Systems Manager this was known as a line of business (LOB) view.


IBM Tivoli Business Systems Manager has two methods for discovering distributed resources. Rules can be added to the IBM Tivoli Enterprise Console to forward events to IBM Tivoli Business Systems Manager database using the agent listener. The first event from a resource triggers the creation of the resource in the IBM Tivoli Business Systems Manager database. The common listener provides bulk and delta transactions. Bulk transactions are a snapshot of the instrumented environment. Bulk transactions identify which resources exist, resources that have changed since the last bulk transaction, the associations between resources, and resources that no longer exist since the last bulk transaction. The IBM Tivoli Business Systems Manager database is populated with the information in the bulk transaction. The delta transaction updates the IBM Tivoli Business Systems Manager database as new resources are discovered. We will see various examples of the usage of the discovery process for different products throughout the book.

1.3.3 Event processingIBM Tivoli Business Systems Manager consolidates events from a wide range of IBM and independent system vendor products. Event processing involves capturing specific events and routing them to the IBM Tivoli Business Systems Manager server. The events result in updates to the IBM Tivoli Business Systems Manager database, which are then displayed on the IBM Tivoli Business Systems Manager console. Events also can trigger the discovery of resources. IBM Tivoli Business Systems Manager has two event types: messages and exceptions.

A fundamental principle of an effective centralized command center is to make alerts meaningful. The lights that indicate problems of greater or lesser severity must reflect the context in which they appear. IBM Tivoli Business Systems Manager introduces two concepts in managing this problem: correlated priorities and alert ownership.

Correlated priorities is a mechanism in selecting an object priority such that it will affect the alert status of a resource that is on a higher hierarchy. Taking ownership of an alert changes the tagged object icon from alert to Ownership status. Taking ownership also acts as a contract of problem acceptance. The username is automatically recorded in a note, which allows narrative action information to be recorded, viewed, and played back for reviews. Because all clients are updated instantly when ownership is taken, other members of the command center team and department users with special Business System Views (BSVs) can see that someone is responding to an alert. Integration with the Tivoli Framework products enable the state changes in products such as TEC to reflect a coherent view of the enterprise.


Filtering is a powerful feature for building a BSV by providing ad-hoc selection criteria, such as object type, name, and alert state. This enables the command center staff to quickly create a custom view to closely monitor a collection of objects showing recent trouble conditions. Filtering also allows representations of the same object contained in different BSVs to filter events differently, therefore allowing you to be notified only on events that pertain to you.

IBM Tivoli Business Systems Manager monitors resources for state changes and the performance characteristics that reflect their availability. These resources are represented by IBM Tivoli Business Systems Manager objects in the SQL database. Actions on an object, such as an alert notification and the propagation of that alert up and down a view, result from events. Events may be exceptions associated with an object or a state change of that object. Exceptions occur when the counters that measure performance thresholds are exceeded. An example of an exception could be unacceptable response time associated with a CICS transaction. Another example of an event could be the receipt of a console message that a batch job terminated abnormally. This would cause a state change to occur and would result in an event. As events occur within the monitored environment, they are collected and recorded by IBM Tivoli Business Systems Manager, and are displayed by tagging an alert icon on the offending object’s icon.

Propagation leverages the object-orientated implementation inherent within the IBM Tivoli Business Systems Manager environment and continuously disseminates events throughout the object hierarchy. Propagation escalates alerts up the hierarchy based on the severity of events and the volume and rate at which they occur. Exceptions, console messages, and other events are assigned priorities for each object. When an object receives an event, the events priority is examined and compared against tolerance rates set for that object. If a threshold is exceeded, an alert occurs on that object and sends an event to its parent object on the hierarchy. This, in turn, can cause another event to occur and another alert to be sent further up the hierarchy. In addition to controls that adjust rates for incoming performance exceptions, each object on the hierarchy includes controls for events arriving from the child objects below it.

Figure 1-3 on page 12 shows an alert occurring on the DB2 subsystem D7Q2 object under the SC69 system. The event is propagated up the hierarchy to the Enterprise level. The propagation also takes place on the Business System View of the object that affects the ITSO RESOURCES object.


Figure 1-3 TBSM console: propagation path

Propagation is the technical component that enables IBM Tivoli Business Systems Manager to progress from a physical to a logical model. As events are propagated to the physical parents of an object, they also are propagated to all Business System Views containing those objects.

1.3.4 ViewsIBM Tivoli Business Systems Manager enables you to manage resources in a way that best reflects your current organization. Your IBM Tivoli Business Systems Manager implementation can reflect a decentralized or a centralized control structure. The resources either can be defined to IBM Tivoli Business Systems Manager or can be discovered using various methods (for example, components, modules, or programs) to detect the configuration of the resources. Once the resources are defined or discovered, they are registered in the IBM


Tivoli Business Systems Manager database; that is, information about the resources is stored in the database and is available for monitoring and viewing.

The IBM Tivoli Business Systems Manager console and the IBM Tivoli Business Systems Manager Web console display your enterprise’s resources in various views. When notifications that trigger alerts are received from the various collection agents within the enterprise, the alerts are displayed as graphic overlays on the resources, indicating the different status of your resources.

A resource view displays all the resources registered in the IBM Tivoli Business Systems Manager database. Business System Views can be created from the console or automatically from incoming discovery and event data. A BSV is a logical view that includes any subset of the registered resources that are of interest for monitoring. Each resource is represented as an icon within the view. You can create, save, and later access BSVs. Opening several windows, each containing a different BSV, enables you to monitor different resources and their various relationships from a single workstation. BSVs can be based on an actual business system or on:

� An application or set of applications

� A department

� A vertical area of responsibility

� A geographic region

Some examples of Business System Views are:

� Real estate (business system)

� Inventory, software distribution (applications)

� Human Resources (department)

� Email gateway (vertical area of responsibility)

� Asia Pacific South Operations (geographical region)


BSVs enable you to organize logically the resources that you want to monitor and display them in the resource system views and Business System Views using these methods:

� Tree view, which shows the hierarchy of the resources. Branches in the tree can be expanded or collapsed to show or hide resources. We can see this in Example 1-4.

Figure 1-4 TBSM console: tree view


� Hyperview, which graphically displays a large number of resources at one time as shown in Figure 1-5.

Figure 1-5 TBSM console: Hyperview


� Table view, which shows resources in a table format. Information for any column can be sorted and filtered as shown in Figure 1-6.

Figure 1-6 TBSM console: Table view


� Business impact view, which is displayed as a hyperview, shows resources that are affected or act as parents to a specific resource, as shown in Figure 1-7.

Figure 1-7 TBSM console: Business impact view


� Event view, which examines the events that were responsible for the state change, as shown in Figure 1-8.

Figure 1-8 TBSM console: events view


Property sheets for each of the resources, such as the one shown in Figure 1-9, enable viewing and updating of:

� Attributes, such as the resource name and current status

� Alert information, such as currently posted events and notes

� Thresholds for propagation and filtering

� Scheduling information

Figure 1-9 TBSM properties window


The IBM Tivoli Business Systems Manager Web console, shown in Figure 1-10, enables quick access for checking critical resources and provides various ways to view resources and events.

Figure 1-10 TBSM Web console

1.4 Document organization and scopeThis redbook is designed to provide both technical concept detail and implementation instructions to help IBM/Tivoli professionals understand and implement IBM Tivoli Business Systems Manager. The content includes:

� Architectural detail� Planning information� Distributed environment implementation� Mainframe information� Post-implementation tasks� Optional component implementation

Table 1-1 on page 21 outlines the chapters for quick reference on specific topics.


Table 1-1 Reading paths

Purpose Relevant topics

Understanding IBM Tivoli Business Systems Manager architecture

Chapter 2, “Components and functions” on page 25Chapter 3, “Database structure” on page 77

Planning an IBM Tivoli Business Systems Manager implementation

Chapter 2, “Components and functions” on page 25Chapter 5, “Implementation planning” on page 129

Implementing IBM Tivoli Business Systems Manager in distributed environment

Chapter 5, “Implementation planning” on page 129Chapter 6, “Base services implementation” on page 149Chapter 7, “TEC components integration” on page 209Chapter 8, “IBM Tivoli Monitoring integration” on page 249Chapter 9, “IBM Tivoli NetView integration” on page 279

Implementing IBM Tivoli Business Systems Manager in z/OS environment

Chapter 5, “Implementation planning” on page 129Chapter 6, “Base services implementation” on page 149Chapter 10, “z/OS installation and configuration” on page 331Chapter 11, “z/OS data feeds and discovery” on page 347

Maintaining IBM Tivoli Business Systems Manager

Chapter 2, “Components and functions” on page 25Chapter 12, “Automatic Business System View creation” on page 395Chapter 13, “Setting up roles and security” on page 421Chapter 14, “Maintenance and tuning issues” on page 437

Extending IBM Tivoli Business Systems Manager with problem management

Chapter 15, “Automatic problem ticketing” on page 465

Providing failover to IBM Tivoli Business Systems Manager servers

Chapter 16, “High availability and failover” on page 513

Collecting historical information from IBM Tivoli Business Systems Manager

Chapter 17, “Historical reporting with TEDW” on page 527


1.5 Lab environmentWe ran the project at ITSO Austin. We set up the main IBM Tivoli Business Systems Manager systems using four servers. Our lab environment is shown in Figure 1-11.

Figure 1-11 Network diagram

The detailed software and operating system that we used is shown in Table 1-2.

Table 1-2 Operating system and software detail

TBSM Servers

Ethernet

ibmtiv5Windows 2000

MS SQL Server 2000Database ServerAgent Listener

ibmtiv3Windows 2000

Console V2 ServerPropagation ServerCommon Listener

ibmtiv6Windows 2000

MS SQL Server 2000History Server

Health Monitor Server

CapeCodAIX 5.1

Netview 7.1.2

ibmtiv9Windows 2000 Server

Framework 3.7.1TEC 3.7.1ITM 5.1.1

ITM for DB/2 5.1DB/2 7.1

Classic DM 3.7

SC64 - z/OSTBSM Source/390

Netview 5.1TWS 8.1

ibmtiv8Windows 2000 Server

Endpont

3C041Windows 2000Event Server


Netview 5.1RODMCICS

CICSPlexSM


Netview 5.1SA/390 2.2

RODMDB2 V7 z\OS

IMS V7.1SMSXRCRMF

DFSMSHSM

MVS1 - z/OSTBSM Source/390

Netview 5.1SA/390 2.2

Name OS Software

ibmtiv3 Windows 2000 Advanced Server Edition

Console V2 ServerPropagation ServerCommon Listener

ibmtiv5 Windows NT 2000 Advanced Server Edition

MS-SQL 2000 Server Enterprise EditionDatabase ServerAgent Listener


The Tivoli Management Framework components that are installed in our environment are shown in Example 1-1.

Example 1-1 Result for wlsinst -a of the TMR server

*-----------------------------------------------------------------------------*Product List

*-----------------------------------------------------------------------------*TME 10™ Framework 3.7Tivoli Enterprise Console Adapter Configuration Facility 3.7.1BM Tivoli Monitoring, Version 5.1.0 - JRE 1.3.0Tivoli Java Client Framework 3.7Tivoli Java Client Framework 3.7.1Java for Tivoli 3.7

ibmtiv6 Windows 2000 Advanced Server Edition

MS-SQL 2000 Server Enterprise EditionHistoryServerHealth Monitor Server

ibmtiv8 Windows 2000 Server Edition

TME® Endpoint 106

ibmtiv9 Windows 2000 Server Edition

Tivoli Management Framework 3.7.1IBM Tivoli Enterprise Console 3.7.1IBM Tivoli Monitoring 5.1.1ITM for Databases: DB2 5.1DB2 7.1Tivoli Distributed Monitoring 3.7

capecod AIX® 5.1 NetView® 7.1.2

IBM S/390s z/OS version 4 TBSM Source/390 2.1Tivoli NetView for z/OS 5.1System Automation for OS/390 V2R1Tivoli Workload Scheduler 8.1DB2 for z/OS 7.1IMS 7.1CICS TMCICSPlex® SM 2.2Tivoli Decision Support/390 7.1System Managed Storage 1.5DFSMS/HSM 1.5.eXtended Remote CopyResource Management Facility

3C041 Windows 2000 Advanced Server Edition

Event Handler Server

Name OS Software


Java for Tivoli 3.7.1Tivoli Java RDBMS Interface Module (JRIM) 3.7JavaHelp for Tivoli 3.7Swing for Tivoli 3.7Tivoli Enterprise Console Console 3.7.1Tivoli Enterprise Console Server 3.7.1Tivoli Enterprise Console User Interface Server 3.7.1IBM Tivoli Monitoring, Version 5.1.1Tivoli MDist 2 Graphical User Interface

*-----------------------------------------------------------------------------*Patch List

*-----------------------------------------------------------------------------*3.7.1 Tivoli Enterprise Console ACF Fixpack 33.7.1 Tivoli Enterprise Console Console Fixpack 33.7.1 Tivoli Enterprise Console Server Fixpack 3Tivoli Framework Patch 3.7.1-TMF-0088 (build 11/01)Tivoli Framework Patch 3.7.1-TMF-0089 (build 10/16)Tivoli Framework Patch 3.7.1-TMF-0090 (build 09/13)3.7.1 Tivoli Enterprise Console User Interface Server Fixpack 3IBM Tivoli Monitoring, Version 5.1.1 - Fixpack 1IBM Tivoli Monitoring - Tivoli Enterprise Data Warehouse Support, Version 5.1.1 Fixpack 1Tivoli Java RDBMS Interface Module (JRIM) 3.7.1JavaHelp for Tivoli 3.7.1Swing for Tivoli 3.7.1Tivoli Framework 3.7.1 Maintenance Release (build 03/15)Tivoli MDist 2 Graphical User Interface 3.7.1 Maintenance Release

We used a relatively small Tivoli framework environment to illustrate this example. You will need to install IBM Tivoli Monitoring 5.1.1 on the gateway before installing the IBM Tivoli Business Systems Manager adapter. In our case, the endpoint that we are going to monitor will be logged into a gateway on our TMR.


Chapter 2. Components and functions

In this section we discuss the basic components and functions of IBM Tivoli Business Systems Manager, and elaborate on these topics in the following sections:

� 2.1, “Product structure” on page 26 gives an overview of IBM Tivoli Business Systems Manager product components

� 2.2, “Base services” on page 29 explains the main component of IBM Tivoli Business Systems Manager that resides on the Windows servers

� 2.3, “Distributed resource feeds” on page 45 explains the data feeds from various distributed systems management tools

� 2.4, “Mainframe (z/OS) resource feeds” on page 53 explains the various interfaces from the z/OS

� 2.5, “History server, reporting, and health monitor” on page 68 discusses the optional components of IBM Tivoli Business Systems Manager

2


2.1 Product structure The major components of the IBM Tivoli Business Systems Manager are shown in Figure 2-1.

Figure 2-1 IBM Tivoli Business Systems Manager product structure

IBM Tivoli Business Systems Manager has three major components:

� Base services, which includes database storage for current and historical data, event receiving and handling services, as well as functions to provide the graphical client interface of the product. As the name indicates, this is the base function that enables you to process events coming from the mainframe, the distributed environment, or both. IBM Tivoli Business Systems Manager uses Windows servers as its platform.

� Distributed resources feeds, which provides the support for the distributed environment including Tivoli Management Framework and other IBM software and third-party software. Some of the distributed sources include:

– IBM Tivoli Enterprise Console 3.6.2 and 3.7.1 – IBM Tivoli Management Framework 3.6.1, or later – IBM Tivoli Workload Scheduler 8.1 (Host and Distributed) – IBM Tivoli NetView (Distributed)

Base Services

� Database server� Event server� Propagation server� Console server� History server� others

TBSMServers

SNA (LU6.2)TCP/IPTCP/IP

Mainframe Resources Feeds

� Applications� Batch systems� Database systems� Online systems� Operating system� Storage systems

Distributed Resouces Feeds

� Tivoli EnterpriseConsole

� IBM TivoliMonitoring

� TivoliInstrumentationService (AMS)

OS/390


– IBM Tivoli Monitoring– IBM Tivoli Monitoring for Databases, Applications, Business Integration,

Web Infrastructure, and Collaboration– Tivoli Distributed Monitoring (Classic)– BMC Patrol 3.4 – CA TNG 2.1, 2.2, and 2.4 – NetIQ AppManager 4.02

� Mainframe resources feeds (often referred to as Source/390), which enables the processing of events from multiple z/OS subsystems and applications. The enterprise edition must run some pre-discovery processes before the object creation and event propagation of the objects can work. The IBM Tivoli Business Systems Manager enterprise edition enables you to manage the following entities on your z/OS systems:

– Applications– Batch systems– Database systems– Online systems– Operating systems– Storage systems

Some of the z/OS sources include:

– IBM CICS® Transaction Server 1.3, 2.1, and 2.2 – IBM Tivoli NetView for OS/390 1.3 and later – IBM Tivoli Operations, Planning, and Control 2.2 and 2.3 – IBM Tivoli Workload Scheduler for z/OS 8.1– IBM DB2 Performance Monitor Versions 5, 6, and 7 – IBM WebSphere®® OS/390 3.5, 4.0, and 4.0.1 – IBM Tivoli Storage Management Systems 1.4 and 1.5 – IBM Storage Management Systems for OS/390 2.10 – IBM System Automation for OS/390 1.3 and 2.1 – BMC Mainview for MVS™™ 2.5.01 or later – BMC Mainview for CICS 5.4.0 or later – BMC Mainview for IMS 3.2.0 or later – BMC Mainview for DB2 7.1 or later – BMC Control M 5.1.4 – BMC Auto Operator 6.0 and 6.1 – Landmark TMON for MVS 2.0 or later – Landmark TMON for CICS 2.0 or later – Landmark TMON for DB2 3.2 or later – CA/7 3.2 and 3.3 – CA OPS/MVS 4.2, 4.3, and 4.4 – Candle Omegamon1 II for MVS Versions 500 and 520 – Candle Omegamon II for CICS Versions 500 and 520

1 IBM Tivoli Business Systems Manager currently only supports Omegamon classic interface

Chapter 2. Components and functions 27

– Candle Omegamon II for DB2 Versions 500 and 520 – Candle Omegamon II for IMS Versions 500 and 520 – Candle AF/Operator 3.1.0 and 3.2.0 – ASG Zeke 4.5 and 5.1

Interfaces between these components and IBM Tivoli products will be discussed in greater detail in the following sections.

Typically IBM Tivoli Business Systems Manager base services is installed on six Windows machines, with the name and role of each Windows machine as follows:

Host Integration server Acts as a conduit for Source/390 components in z/OS to the IBM Tivoli Business Systems Manager base services. It runs on Microsoft Host Integration Server and establishes a session with z/OS eNetwork Communication Server or VTAM® on the host, and it serves the SNA client on the event handler server to enable information exchange. It was called SNA server in previous versions. This server is not needed for TCP/IP connection.

Event Handler server Receives, processes, and reacts to z/OS events. This machine requires SNA client or Host Integration client software, even when you run only TCP/IP connection.

Database server Provides the database repository, which is the heart of IBM Tivoli Business Systems Manager processing. It hosts the object repository in the Microsoft SQL Server database.

Console server Serves the client workstation connections. (This used to be called Application server.)

Propagation server Processes events and calculates the necessary propagation action.

History server Maintains an audit trail of all actions and events acted on by IBM Tivoli Business Systems Manager on a SQL server database for reporting and analysis purposes. It contains replicated data from the database server.

Additonal servers are needed to provide optional functions:

Web console server Provides the user with a Web-based administrative console to IBM Tivoli Business Systems Manager. The Web console differs in appearance and behavior from the console. It runs in kiosk mode, the mode of a Web browser without any browser controls (such as the


menu bar and tool bar) activated. Operators can perform the same basic monitoring and problem-determination tasks as with the regular console, and administrators can perform additional tasks such as creating shared filters.

Health Monitor Server Monitors the health and availability of IBM Tivoli Business Systems Manager processes and queues. This machine enables you to monitor the performance and availability of IBM Tivoli Business Systems Manager components. You can monitor the various services, disk utilization, database space, system queues, and connections to the various data sources.

You may need additional servers for test and quality assurance systems. For IBM Tivoli Business Systems Manager distributed implementation, some of these functionalities can be merged. The recommended configuration of IBM Tivoli Business Systems Manager distributed consists only of a database server and a merged server. The merged server consists of the propagation server, application server, and the common listener function.

2.2 Base servicesThe IBM Tivoli Business Systems Manager base services consists of a set of Windows services running on the IBM Tivoli Business Systems Manager servers. This section provides an in-depth description of the IBM Tivoli Business Systems Manager base services. The discussion consists of:

� 2.2.1, “Components and data flow” on page 29

� 2.2.2, “Installation directory structure” on page 39

� 2.2.3, “Windows registry structure” on page 40

� 2.2.4, “Log files” on page 43

2.2.1 Components and data flowTo better understand how IBM Tivoli Business Systems Manager components interact, see the diagram in Figure 2-2 on page 30. It shows the interaction of the base services servers component.


Figure 2-2 TBSM flowchart

The main components are shown in dark gray boxes, while the other IBM Tivoli Business Systems Manager components are shown in light gray boxes. Non-IBM Tivoli Business Systems Manager components are shown in white boxes.

The database server is the centerpiece, to which all components eventually connect. Specific components for connection to other pieces are shown, such as the Source/390 in z/OS and Agent Listener and Common Listener in distributed systems. For TCP/IP based connection, the Source/390 will connect directly to the Event Handler server.

In IBM Tivoli Business Systems Manager V2R1, installation is simplified to a certain number of components. Table 2-1 on page 31 shows the list of services that are installed and run for each component. Most components relate to specific servers; however, some components may be combined in certain servers.

z\OS

TBSM Servers

TivoliManagementRegion

Source/390

Host IntegrationServer

Event HandlerServer

PropagationServer Database

Server

HistoryServer

ConsoleServer

Common ListenerService

AgentListener

Tivoli DataWarehouse

Web Console

Console

Distributed DataSource.

( Netview, ITM)Task Server

TECEvent Enablement

Web ConsoleServer

Health MonitorServer

Tivoli NetViewfor z\OS

Health MonitorClient


Table 2-1 IBM Tivoli Business Systems Manager services by component

The following sections discuss the role of each service.

Server Services Notes

Database server ASIDBValidaterASIMVSIPListenerSvcASIPADispatcherASIStagedEventLoaderASITaskServerASIEvent EnablementASITSDEvent HandlerSvc

Agent Listener is installed from the Distributed TEC listener component that generally resides in this server

Console Server ASIDBValidaterASIConsoleServerV2

Propagation Server ASIDBValidaterASIRemoteExecutionServerASIEnqueueProxy Server

Propagation agent is started with ASIPAgent.exe

Event handler server ASIDBValidaterASIEnqueueProxyServerASIMVSIPOSListenerASIMVSEventHandlerSvcASIMVSIPSenderSvcASIMVSUploadRuleSvc

For SNA-based connection: ASIMVSSenderSvc ASIMVSListenerSvc

Distributed TEC component

ASIAgentListenerSvc This is usually installed in the database server

Health Monitor server ASIHealthMonitor Health monitor can be installed in the history server

Web console server TivoliPresentationServices HTTPServerTivoliPresentationServices HTTPAdministrationps_wcps_mcr

Web server services from Tivoli presentation services for the Web console

Common listener ASICommonListener Common listener can be installed together with application or propagation server

History Server - No services installed

Health Monitor Client - No services installed


Tivoli BSM Database Validater (ASIDBValidater)This service validates the availability of database connections for all IBM Tivoli Business Systems Manager servers. The database validater service runs on all IBM Tivoli Business Systems Manager servers. All other IBM Tivoli Business Systems Manager services that access the database are made dependent on this service.

The database validater periodically runs the query shown in Example 2-1. This query can be found under the IBM Tivoli Business Systems Manager registry key Components\ASIDBValidater\Settings in the value of TestSQL. We have formatted the query display.

Example 2-1 Database validater query

if db_name()='master' beginif exists (select * from sysobjects

where type='X' and name='xp_createnotificationevent')exec('xp_createnotificationevent')

if exists (select * from sysobjects where type='X' and name='xp_creatependingevent')

exec('xp_creatependingevent') if exists (select * from sysobjects

where type='X' and name='xp_createrulecmdevent')exec('xp_createrulecmdevent')

endelse select * from sysobjects where name='sysobjects'

Tivoli BSM Propagation Agent Dispatcher (ASIPADispatcher)The Tivoli BSM propagation agent dispatcher manages the propagation agents. It calls the remote execution server in the propagation server the propagation agent. When an event is generated, it notifies the enqueue proxy server on the propagation server to put the events into the propagation agent’s queue file. Currently, restarting the propagation agent dispatcher is the only appropriate way to start or restart the propagation agent.

When the Propagation Agent Dispatcher is stopped, it stops the propagation agent on the propagation server through the remote execution server.

Tivoli BSM Staged Event Loader (ASIStagedEventLoader)This service is responsible for loading events to the IBM Tivoli Business Systems Manager database. This process must run continuously. This process works with the ObjectEvents database.


Tivoli BSM Task Server (ASITaskServer)This component is used to issue commands on the monitored resources. Two types of commands are supported:

� z/OS command through Tivoli NetView for z/OS

� running a Tivoli Management Framework task

It invokes the send command using the tgmtask utility.

Typically, the task server running on the database server only holds the connection to Tivoli NetView for z/OS through the NETCONV session. If you are not managing any resources that belong to the z/OS, you may disable this service.

The task server that is used for Tivoli Management Framework tasks runs on a Tivoli Enterprise Console server together with the event enablement service. This task server is installed using the Tivoli Management Framework winstall command. The task server that runs a Tivoli Management Framework task must be running under a Tivoli-authorized administrator user ID, and the machine must be a managed node in a Tivoli Management Region (TMR).

Tivoli BSM Event Enablement (ASIEventEnablement)This component is supposed to be used in the distributed components with the Agent Listener service to handle Tivoli Enterprise Console events. The service that is installed in the database server is not used. You may want to disable this service.

The event enablement process has to run on the same machine as the Tivoli Enterprise Console to receive events from it.

Tivoli BSM MVS IP Listener (ASIMVSIPListenerSvc)This process waits for the connection from z/OS. This IP-based listener is used for bulk file transfers from z/OS. Specifically, it handles discovery of resources that are sent using the program GTMAOPE0, typically by listening to port 1021. It can handle character conversion and localization. More discussion on this process is provided in Chapter 11, “z/OS data feeds and discovery” on page 347.

Tivoli BSM TSD Event Handler (ASITSDEventHandlerSvc)This component is used for integration with problem management software, typically Tivoli Service Desk. It processes problem ticket closure events that are generated by the problem management product and applies them to the appropriate IBM Tivoli Business Systems Manager information. More discussion on problem management is given in Chapter 15, “Automatic problem ticketing” on page 465.


Tivoli BSM Console Server Version 2 (ASIConsoleServerV2)The console server handles communication to the IBM Tivoli Business Systems Manager Java console. It communicates with the database server for any updates on events and objects, and applies them to all the open consoles.

It also helps maintain all active console sessions to the database server. The console is a role-based user interface in which you set up roles to determine a user’s access rights. The roles are: Restricted Operator, Operator, Administrator, and Super Administrator. The console server in version 2 uses four Windows groups to categorize the authentication of an operator. An operator who does not belong to any of the IBM Tivoli Business Systems Manager groups cannot open the console.

The console monitors resources for state changes and performance characteristics that reflect availability. If the availability of a resource or resources is threatened, an alert icon is placed next to the resource or subsystem. Notification of alerts and events management are the console’s primary tasks. By observing views, end users can see whether the system, subsystem, or resource is available and performing correctly.

The Java console connects to the console server through port 80 (http), therefore it most likely can go through firewalls.

Tivoli BSM Remote Execution (ASIRemoteExecutionServer)The remote execution server is responsible for starting and stopping the propagation agent at the request of the propagation agent dispatcher.

Tivoli BSM Enqueue Proxy Server (ASIEnqueueProxyServer)The enqueue proxy server receives messages that are meant to be processed by other components or services:

� For the MVS sender service in the event handler server, it puts the message into the <SMFid>_Upload.que file

� For the propagation agent in the propagation server for events that need to be propagated, the message is typically put into ROOT-0001.que

The queue file typically resides in the TivoliManager\data\Queues directory. There are two important commands for queue files: dumpfqueue and dequeue. The dumpfqueue checks the status of the queue file, while dequeue is used to clean up the queue file.

Note: If backward compatablity is required for previous IBM Tivoli Business Systems Manager consoles, you also should load Application Server services.


The syntax for dumpfqueue command is dumpfqueue <queuefilename> as shown in Example 2-2.

Example 2-2 Sample dumpfqueue result

C:\TivoliManager\Data\Queues>dumpfqueue AgentListener.queName=AGENTLISTENER.QUE CellSize=2048 MaxEntries=70000 HeadOffset=512 TailOffset=512 EnqueueCount=35287 DequeueCount=35287 FlushCount=0 FileEntries=0 SemaphoreEntries=0 Locked=No Empty=Yes

EnqueueCount and DequeueCount indicate queue activity. The EnqueueCount number should equal the DequeueCount number. The result Empty=Yes indicates that there is no data currently in the queue.

The syntax for dequeue command is

dequeue -t<timeout> -r<repeat_count> -p<pause_time> -s -v -x <queuepath>

where:

<queuepath> File path to queue (required).

-t<timeout> Dequeue timeout in milliseconds.

-r<repeat_count> Repeat count. Specify -1 for infinite repeat.

-p<pause_time> Pause between operations in milliseconds.

-s Silent operation. Will not output queue entries to stdout. Useful with binary data.

-v Output all printable data. Useful with binary data. May be used with -x.

-x Output all data in hexidecimal. Useful with binary data. May be used with -v.

Propagation agent (ASIPAgent.exe)The propagation agent calculates the propagation events that must be performed and updates the database server. See 3.4, “Status propagation” on page 87 for more on the propagation process.

Tivoli BSM MVS IP OS Listener (ASIMVSIPOSListener)This is the new TCP/IP-based MVS OS Listener that listens to connection requests from the Source/390 Object Server process from z/OS. It typically listens at port 1022. When a connection is acheved, it spawns a listener thread to communicate with the Source/390 object server. You can use the netstat -a | grep 1022 command to check the connection from port 1022. Our listener is connected to four z/OS systems as shown in Example 2-3 on page 36.


Example 2-3 MVS IP listener connection

C:\>netstat -a | grep 1022 TCP 3c041:1022 3c041:0 LISTENING TCP 3c041:1022 wtsc66.itso.ibm.com:1051 ESTABLISHED TCP 3c041:1022 wtsc64.itso.ibm.com:1556 ESTABLISHED TCP 3c041:1022 wtsc69.itso.ibm.com:3201 ESTABLISHED TCP 3c041:1022 bldmvs1.boulder.ibm.com:1031 ESTABLISHED

Tivoli BSM MVS Listener (ASIMVSListenerSvc)This is the SNA-based MVS listener that waits for the connection request from the Source/390 object server. It is started as an LU6.2 transaction program by the TPSTART utility.

The listener process writes in two log files. The first log has the prefix LS and contains the listener initialization before it knows the z/OS image that contacted it. The second log has the prefix MVSL and contains the SMF ID of the z/OS that triggers the listener process. The MVS listener will put the messages it receives into a queue file. The logs indicate whether TPStart has successfully launched the listener process and will show whether an SNA session has been established through the SNA server to the host.

Tivoli BSM MVS Event Handler (ASIMVSEventHandlerSvc-nnn)The MVS event handler retrieves the queued MVS listener messages from a queue file. The queue file name is the same as the SMF ID of the z/OS origin of the message. It sends the message to the staged event loader in the database server and notifies the MVS upload rule services to process the message.

Each connected z/OS image has a different event handler process.

Tivoli BSM MVS Upload Rule Server (ASIMVSUploadRuleSvc)The MVS upload rule server processes the z/OS message and constructs the appropriate responses to the z/OS components. It is responsible for starting the various registration processes and starting the object initialization in the database server.

The upload rule service is dependent on the rule database in ASIRuleSvc database. The ASIRuleSvc contains shadow data from various z/OS objects in the Object database for rule processing. This information is created the first time the upload rule service is started and is recorded in the ObjectSync table. To re-initiate the collection of information, delete the row in the ASIRuleSvc’s ObjectSync table.

After creating a new operating system object, run the SQL statement delete from ASIRuleSvc..ObjectSync and then restart the upload rule server.


Tivoli BSM MVS IP Sender (ASIMVSIPSenderSvc-nnnn)The replies that are constructed by the various scripts from the upload rule service are put into the upload queue by the enqueue proxy server. The sender service is responsible for actually sending them. This IP-based sender service connects to the Source/390 object server through a typical port (usually 1023, but in our setup 1023 is used for UNIX System Services login, so we configured the sender to connect through port 1024).

Each z/OS image has a separate sender service and upload queue files.

Tivoli BSM MVS Sender Svc (ASIMVSSenderSvc-nnnn)This is the SNA-based sender service that acts as an LU6.2 transaction program. The behavior is similar to the IP-based sender service.

Tivoli BSM Agent Listener (ASIAgentListenerSvc)The Agent Listener service is used to receive events from the Tivoli Enterprise Console. It connects and registers itself to an event enablement process using the gemeeconfig command for configuration. This component is discussed in greater detail in Chapter 7, “TEC components integration” on page 209.

Tivoli BSM Health Monitor Server (ASIHealthMonitor)This service runs the HMSQueries.ksh using the SRVANY.exe from the Windows Resource Kit. The HMSQueries.ksh runs a set of predefined checks and then sleeps for 60 seconds.

It retrieves availability data from a variety of sources and produces files that are used as input to the interface, which the service makes available to health monitor clients. The collection of input files from a single sample are concatenated into a single output file called TotalSummary.txt (usually located in the \TivoliManager\Mgmt\HMS\Input directory). Total summary files are date-stamped and time-stamped and placed in a directory called Output (\TivoliManager\Mgmt\HMS\Output). This file, which can be viewed using a text editor, contains a complete snapshot of the working system for that given time stamp. It can be archived to provide a complete history of how IBM Tivoli Business Systems Manager servers have performed over a given period.

Note: Chapter 10, “z/OS installation and configuration” on page 331 has more information about these z/OS communication services.


The GUI displays these systems health monitor components:

� Database Blocking: Monitors the hosts and processes that cause database blocks, and alerts system administrators to potentially harmful system availability problems.

� Database Lock Summary: An adjunct-monitoring window to the Database Blocking facility. Monitors what database processes are locking database tables and pages at the time of the sampling interval.

� DB Queues: Monitors the status of the Tivoli Business Systems Manager database queues, enabling you to determine whether the components servicing those queues are operating correctly, and checks the status of propagation and notification.

� MVS Status: Monitors the status of the MVS listener processes, event handler, and sender services, and monitors the processing of data received from hosts that are running the Source/390 program.

� PAgent Status: Monitors the status of Propagation Agent processes and the processing of events by those Propagation Agents.

� Required Services: Monitors the status for all Tivoli Business Systems Manager services required for Windows-based system availability.

� Server Disk Usage: Monitors the percentage of disk usage on Tivoli Business Systems Manager production servers by host name and drive letter.

� SQL Response Time: Monitors the performance of key stored procedures that Tivoli Business Systems Manager users execute on a regular basis.

� Staged Event Status: Monitors the depth and processing of Staged Event Queues with the Tivoli Business Systems Manager database processing of the message and exception queues in the database.

Tivoli BSM Common Listener (ASICommonListener)The Common Listener provides a scalable infrastructure for the integration of product instrumentation into IBM Tivoli Business Systems Manager. Data is sent by monitoring product to the Common Listener, which updates the IBM Tivoli Business Systems Manager database.

More discussion about the Common Listener with IBM Tivoli Monitoring is provided in Chapter 8, “IBM Tivoli Monitoring integration” on page 249, and discussion about the Common Listener with IBM Tivoli NetView is provided in Chapter 9, “IBM Tivoli NetView integration” on page 279.

Conceptual discussion of the common listener process is given in 2.3, “Distributed resource feeds” on page 45.


2.2.2 Installation directory structureIBM Tivoli Business Systems Manager installed on Windows machines provides the directory structure shown in Figure 2-3. This directory structure typically is created under \TivoliManager and shared as Access1$ for easy access by other IBM Tivoli Business Systems Manager servers.

Figure 2-3 IBM Tivoli Business Systems Manager Windows directory structure

Some of these directories will not be present on all servers. The component installed influences the directories installed. The following are used in the directories:

Autotrace Configures automatic tracing for Common Listener and Console Server java processes.

bin Main executable path for IBM Tivoli Business Systems Manager. This must be in the system path.

CommonListener Common listener installation directory.

ConsoleServer Console server installation directory.

Data Data directory used for Tivoli Information Management for z/OS integration.

Data\products Directories where Tivoli Manager for products definition is stored.


Data\Queues Queue files directory where the enqueue proxy server writes files.

Data\Rules Rule directory that is used by the ASIMVSUploadRule server. Rule files have the .clp extension.

Lang Language-specific locale for character translation tables.

Logs Main log directory, shared as Logs$

man Not used.

Mgmt Directory for health monitor program and output files. This directory is shared as Mgmt$

sql Directory for storing SQL queries.

TDS Topology Display Services: the installation path for event enablement and task server.

xdfparser Parser script for decoding Application management instrumentation definitions into IBM Tivoli Business Systems Manager.

2.2.3 Windows registry structureMost of the settings for IBM Tivoli Business Systems Manager services are stored in the Windows registry under the following key:

HKEY_LOCAL_MACHINE\Software\Accessible Software, Inc.\Access1\1.0

A sample registry tree is shown in Figure 2-4 on page 41.


Figure 2-4 Registry tree

The main folders in this registry structure are:

Components Where most of the services’ settings are stored; however, the setting for services from the propagation servers are not located here.

Settings The location of the global settings for this server’s IBM Tivoli Business Systems Manager in this server.

SetupDefaults The values of the installation parameters that we enter from the installation dialogs.

The Settings folder has a hierarchical design, so all information is retireved from a branch’s innermost folder. If it does not exist there, it will be retrieved from the folder that is in the next level. As an example, we will find the log file prefix, log level, and log directory from the registry tree for the MVS IP OS Listener for SC66, as shown in Figure 2-5 on page 42. All registry paths are relative to HKLM\SOFTWARE\Accessible Software, Inc\Access1\1.0:

� The log file prefix (MVSL_SC66) is retrieved from Components\ASIMVSIPOSListenerSvc\Instances\SC66\Settings\Log, as that


is the innermost setting with that value. If the listener has not been associated with any instance, it will use the setting in Components\ASIMVSIPOSListenerSvc\Settings\Log, which is MVSIP.

� The LogLevel information for all MVS IP OS Listeners is retrieved from Components\ASIMVSIPOSListenerSvc\Settings\Log, as it cannot be found on the innermost Setting in Components\ASIMVSIPOSListenerSvc\Instances\SC66\Settings\Log.

� The Log directory is not present in either Components\ASIMVSIPOSListenerSvc\Instances\SC66\Settings\Log or Components\ASIMVSIPOSListenerSvc\Settings\Log; therefore it is retrieved from Settings\Log path.

Figure 2-5 Hierarchical setting

Another important setting is the database setting in Settings\DB, as shown in Figure 2-6 on page 43. It contains the database access information that is used


by some programs to gain access to the database. This key contains the database system administrator (sa) password.

Figure 2-6 Database setting

2.2.4 Log filesLog files for the IBM Tivoli Business Systems Manager processes are very important for understanding how these processes work and for debugging if a problem occurs. Each process in IBM Tivoli Business Systems Manager generates log files. Most of these files are stored under TivoliManager\logs, and their settings are stored in the registry, as shown in Figure 2-5 on page 42.

The list of standard log files is provided in Table 2-2.

Table 2-2 TBSM services log files

Process name Log prefix

ASIDBValidaterTivoli BSM Database Validater

-

ASIPADispatcherTivoli BSM Propagation Agent Dispatcher

PD

ASIEnqueueProxyServerTivoli BSM Enqueue Proxy Server

EPS

ASIRemoteExecution ServerTivoli BSM Remote Execution Server

RX

PAgent.exe PA

ASIApplicationSvcTivoli BSM Application Server

AS

ASINotificationSvcTivoli BSM Notification Server

NS

ASIMVSIPOSListenerSvcTivoli BSM MVS IP Listener

MVSIPMVSL_nnnn_


The logging level for an IBM Tivoli Business Systems Manager–based log is controlled from the LogLevel registry value in the Settings folder. The log files that are shown in full in Table 2-2 on page 43 do not use the standard IBM Tivoli Business Systems Manager format.

ASIMVSListenerSvc LSMVSL_nnnn_

ASIMVSEventHandlerSvc-nnnnTivoli BSM MVS EventHandlerSvc-nnnn

MVSE_nnnn_

ASIMVSUploadRuleSvcTivoli BSM MVSUpload Rule Server

MVSURS

ASIMVSIPSenderSvc-nnnnTivoli BSM MVS IPSenderSvc-nnnn

MVSS_nnnn_

ASIMVSSenderSvc-nnnnTivoli BSM MVSSenderSvc-nnnn

MVSS_nnnn_

ASIStagedEventLoaderTivoli BSM Staged Event Loader

SEL

ASIMVSIPListenerTivoli BSM MVSIPListener

IPL

ASIAgentListenerTivoli BSM Agent Listener

AL

ASIRuleSvcTivoli BSM Rule Server

RLS

ASITaskServerTivoli BSM Task Server

ihstsmsg.logihstserr.log

ASIEventEnablementTivoli BSM Event Enablement

ihseemsg.logihseeerr.log

TSDEventHandlerSvcTivoli BSM TSD Event Handler

TBSMTSD.log

ASICommonListenerTivoli BSM Common Listener

CLASICLTransportn.log

ASIConsoleServerV2Tivoli BSM Console Server V2

ConsoleServer\TBSMServern.log

Process name Log prefix


The standard IBM Tivoli Business Systems Manager log format is set in the LogHeading registry value. Typically the format is:

%Y/%m/%d %H:%M:%S|%t|%O|%o|logprefix|%i|%F|%L|

The format variables include:

%Y Year

%m Month

%d Date

%H Hour

%M Minute

%S Second

%t Microsecond

%O Record types:

DBG debug

INF informational

NOT notice

ERR error

WRN warning

CRT critical

%o Priority, which indicates what logging level will show this type of record

%i Thread ID

%F Source program name

%L Line number in the source program

2.3 Distributed resource feedsThe IBM Tivoli Business Systems Manager distributed components are shown in Figure 2-7 on page 46. Basically IBM Tivoli Business Systems Manager supports two interfaces for distributed environment: through agent listener and common listener. We will describe both interfaces.


Figure 2-7 Flowchart for distributed system

2.3.1 Agent ListenerThe Agent Listener system processes connections from Tivoli Enterprise Console (TEC). Any resources that send events to TEC can be forwarded through the event enablement process into the agent listener. This connection is handled by two processes that should run on the TEC server machine:

� Event enablement, which enables monitoring of any distributed resource, the status of which can be communicated using a Tivoli Enterprise Console event. Connectivity to IBM Tivoli Business Systems Manager is provided by the agent listener process.

� The task server, which interacts with the IBM Tivoli Management Framework. Command requests from an operator are routed to the task server using the

TBSM Servers

TivoliManagementRegion (TMR)

APMInstrumentation

Tivoli DistributedMonitoring

Classic

Generic TECEvents

Tivoli Managerfor Products

TivoliEnterpriseConsole(TEC)

TBSMTask Server

(ihscts)

TBSMEvent Enablement

(ihstdmai)

AgentListener

CommonListener

Tivoli NetviewDistributed

TBSM DatabaseServer

IBM TivoliMonitoring

(ITM)

TivoliManagementFramework

BMC PATROL

CA Unicenter

Net IQ


tgmtask utility, which invokes a Tivoli Framework task on the appropriate destination. Responses are returned to the task server where they are correlated with the request and routed back to the requesting operator.

Several types of events can be forwarded through this interface, as shown in Figure 2-7 on page 46:

� Application Policy Management (APM) instrumentation

� Tivoli Distributed Monitoring events

� Any generic TEC event

The Tivoli Manager for product uses the APM interface to send heartbeat events and threshold violation status to TEC, while the new IBM Tivoli Monitoring for modules uses the generic TEC event interface to forward events to IBM Tivoli Business Systems Manager.

APM instrumentationAPM resources are defined through Application Management Specification (AMS) definitions. Many software products are instrumented with AMS. These products, if not predefined in IBM Tivoli Business Systems Manager, can be defined manually in IBM Tivoli Business Systems Manager using the (xdf)parser utility. This utility interprets the AMS definitions and creates SQL definitions that extend the IBM Tivoli Business Systems Manager data model. This (xdf)parser utility is implemented in Java. It has its own JRE.

An AMS definition is distributed in files as shown in Figure 2-8.

Figure 2-8 AMS description files

isComposedOf

Application(GDF)

Software Component(CDF)

mapsToSoftwareComponent mapsToBusinessComponent

Business Mapping(BMDF)

isComposedOf

organizes

isComposedOf

Business System(BSDF)

Business Subsystem(BSSDF)

Business Component(BCDF)


Application The application building block, which is used to group a set of software components, captures information that applies to all the components of an application.

Software Component The most fundamental building block, the software component is a manageable unit of an application that resides on a particular platform. The software component building block describes the management requirements, such as installation, configuration, and monitoring, for a single software component on a single platform.

Business System In many cases, applications are combined into a high-level system that performs a particular business function. The business system is a combination of applications and technologies that interact with each other to fulfill a critical business function.

Business Subsystem The business subsystem organizes business components into groups based on a common function in order to provide another level of management.

Business Component Business systems are made up of components that describe the role a software component plays within a business system. For example, an Internet server could be an order entry interface or an airline ticketing server, depending on what business system it belongs to.

Business Mapping This provides the mapping for business system components to software components.

Table 2-3 shows definitions resulting from AMS definition file types.

Table 2-3 AMS types

AMS filetype TBSM definitions

bsdf Business System View definitions, depending on the type: Business System, Application, or Middleware

bssdf Business System View definitions

bmdf Ties the component to its Business System View and provides instance filtering for the Business System View

bcdf No correlated IBM Tivoli Business Systems Manager definitions are created

gdf Defines and provides the name of the default task library


Several TEC event classes are related to these definitions. All of these event classes are defined in the software component level, shipped with the event enablement component in the file interapp.baroc, and processed by interapp.rls using a specific IBM Tivoli Business Systems Manager exit as shown in Table 2-4.

Table 2-4 TEC exits for event forwarding

For IBM Tivoli Business Systems Manager processing, the APM Heartbeat indicates:

� The discovery of the resource.

� That the resource is still alive. A certain length of time without the heartbeat can change the alert state of the resource to yellow or red.

The APM Threshold indicates whether a threshold is exceeded. It will trigger exception processing for the resource.

Distributed Monitoring resources

Distributed Monitoring resources are defined to IBM Tivoli Business Systems Manager using the gemdmmap command. With this command, we create a new class for a software component and a monitoring collection that is associated with it. More than one monitoring collection can be associated with a software

cdf IBM Tivoli Business Systems Manager object type for the component name and version. Associates the icon used at the console. Tasks are added to the menu items for the instance, and the name of alternate task libraries is specified. A Business System View is created for the manufacturer of the component.

Exit Input event type TBSM event type

ihstetec APM Heartbeat APM Heartbeat

ihstmtec APM Threshold APM Threshold

ihstctec APM Connection Change - (not used in TBSM)

ihststec APM System layer - (not used in TBSM)

Important: This resource class only applies to the classic Tivoli Distributed Monitoring profile. It does not applies to IBM Tivoli Monitoring resources as the generated event.

AMS filetype TBSM definitions


component, but a monitoring profile cannot be associated with more than one software component.

Distributed Monitoring profiles also can be added to APM-defined software components. For example, to associate a monitoring profile for Domino™ monitors to the APM-defined instrumentation of Tivoli Manager for Domino, we use the gemdmmap command to create an association for a monitoring profile to the APM-based Domino object class. The sentry events that are sent by the profile are processed as APM Threshold exceptions. The software component instance must be created with the APMHeartbeat event. Distributed Monitoring events will correlate to APM instances when the monitoring profiles are distributed to the same managed node or endpoint where the APM resources are located.

The Distributed Monitoring events must be forwarded to IBM Tivoli Business Systems Manager using the ihstztec exit.

Generic TEC interfaceThe generic TEC interface provides the ability to integrate a generic TEC event into IBM Tivoli Business Systems Manager objects as a generic GEM object class. The events that are not triggered by Tivoli Distributed Monitoring can also be forwarded to IBM Tivoli Business Systems Manager and defined as a separate software component using this API.

Use gemgenprod.sh to define a generic distributed object. TEC event forwarding should be performed using the ihstttec exit. Most of the objects defined and created for the IBM Tivoli Monitoring for products are defined in this class.

Mainframe objectsThis class represents APM objects that are instrumented using IBM Tivoli NetView for z/OS Application Management Instrumentation (AMI). The objects in this class are created under the Operating System object, under the Complex - Machine - LPAR hierarchy based on the content of the host name field.

AMI resources receive the APM Heartbeat and APM Threshold events similar to other APM resources. The only difference is that the event is sent from Tivoli NetView for z/OS through the Event Automation Services to TEC. There is no interface to create this type of object.

Refer to Instrumenting Enterprise Application using Tivoli GEM, SG24-5399 for a complete discussion of AMI. There is no creation interface for these mainframe objects. However, a sample creation script gemmfprod.sh is provided in “The gemmfprod.sh script” on page 558.


2.3.2 Common listenerThe common listener interface provides a generic interface in which any type of object can be created, updated, or deleted. Figure 2-9 shows the detailed mechanism of the common listener.

Figure 2-9 Common listener connection

IBM Tivoli Business Systems Manager has an adapter that collects event data from distributed data sources as follows:

� IBM Tivoli Monitoring

� IBM Tivoli NetView

� Tivoli Workload Scheduler V8

� BMC PATROL

� Unicenter TNG

� NetIQ

The Common Listener service enables products to send bulk discovery, delta discovery, and event information to IBM Tivoli Business Systems Manager without going through TEC. Depending on the sending adapter, resource discovery information can be sent through the common listener service with the events routed through TEC for correlation.

The common listener transport uses message queueing technology that is implemented in Java. It transports extended markup language (XML) messages that are formated using the Simple Object Access Protocol (SOAP). Three types of objects can be manipulated using the common listener interface:

� Instance, which relates to a real resource instance in the IBM Tivoli Business Systems Manager database. This type of object can be created, updated, or deleted.

� Link, which relates to a physical containment link or topology link in IBM Tivoli Business Systems Manager. A link can be created or deleted only.

� Event, which can be applied to an instance.

TBSM DatabaseCommon listenerApplication TBSM adapter transport layer


Example 2-4 shows a sample event formatted in XML.

Example 2-4 Formatted XML for an event through Common Listener

<event> <time>1037738248</time> <id> <class>OperatingSystem</class> <instid>os_ibmtiv9</instid> </id> <type>TMW_HighProcesses@TMW_Processor</type> <context>[666252843]Processor=0;</context> <tbsm> <type>EXCP</type> <desc>High CPU Usage, High CPU Usage User Priv, and High CPU Usage Process are exceeded on the processor 0. (;highprocesses= 2.0000 ;idprocess= 204.0000 ;percentprocessortime= 98.0000 ;process="CSRSS" ;processor="0") </desc> </tbsm> <tecstatus> <severity>CRITICAL</severity> </tecstatus></event>

More information about the database structure of common listener can be found in 3.6, “Common listener resources” on page 95.


2.4 Mainframe (z/OS) resource feedsMainframe component connectivity is shown in Figure 2-10.

Figure 2-10 z/OS components and feeds

z\OS

TBSM SOURCE/390

SOURCE/390Object Pump

WebSpherefor OS/390

DFSMShsm

SMS

XRC

MVSConsole

Messagesand

Commands

CICSPlex SystemManager for OS/390

Resource ManagementFacility

OMEGAMON

CICS Transient Data

Tivoli WorkloadScheduler

CICSPlex

IMS

DB2

System Automation forOS/390 V2R1

Tivoli NetViewfor z/OS

CPSM API

GPMSERVE

3270 screenExternal DataInterface (EDI)

Program-to-program

Interface (PPI)

SOURCE/390 Dataspace

SOURCE/390 Object Server

SA/390 V1R3 and otherautomation tools Automation EDI interface

TBSM Servers

Hostintegration

Server Database

ServerEvent ServerTask Server

NETCONVSNATCP/IP

GTMAOPE0

MVS IPListener

RODM EKGNotify


We will discuss this connectivity in the following sections:

� 2.4.1, “OS/390 components” on page 54

� 2.4.2, “Windows servers connection” on page 57

� 2.4.3, “Object registration process” on page 60

� 2.4.4, “Bulk discovery” on page 62

� 2.4.5, “Command support” on page 68

2.4.1 OS/390 componentsSource/390, which resides on a z/OS system, enables the monitoring and management of OS/390 and z/OS systems. Source/390 components are:

� Source/390 Object Pump

� Source/390 Object Server

� Source/390 Data Space

The Source/390 object pump collects event and performance data and places it in the Source/390 data space. The Source/390 object server then picks up the data and exceptions and passes them to the IBM Tivoli Business Systems Manager servers for subsequent processing and storing in the database.

The object pump uses several mechanisms to get the feeds:

� NetView program-to-program interface (PPI): The object pump registers itself as the PPI listener called NETVAOP. NetView automation can write to the PPI interface and send events to IBM Tivoli Business Systems Manager. This mechanism is used for z/OS subsystems such as CICS, IMS, DB2, and System Automation/390 V2.

� The external data interface (EDI) uses cross-memory services to pass messages and exceptions that reside on the same MVS host to IBM Tivoli Business Systems Manager. Messages and exceptions are passed by EDI directly to the Source/390 object pump and are not displayed on the system console. This interface is used by the CICS transient data monitor, Tivoli Workload Scheduler for z/OS batch information, System Automation for OS/390 v1.3, and other automation products.

� Most of the z/OS subsystems—such as storage information (DFSMS), extended recovery (XRC), and WebSphere information—as well as general JES and z/OS information, are read through the extended MCS console interface.


� Several feeds have a specialized interface, such as:

– Resource Object Data Manager (RODM): The object pump subscribes to the RODM change notification (EKGNotify) so that any RODM object changes will be notified to IBM Tivoli Business Systems Manager.

– CICSPlex System Manager (CPSM): The object pump actively queries the CPSM using the CPSM API interface.

– Resource Monitoring Facility (RMF™): The object pump uses the GPMSERVE process to get RMF metrics for z/OS resources.

– Omegamon II: The object pump interfaces with Omegamon’s 3270 exception screen and monitors the exceptions that occur.

This is the start-up sequence for the address spaces of Source/390:

1. First, the dataspace is started. It must show the GTM5010I message before we can proceed. The startup log for the data server is shown in Figure 2-11.

Figure 2-11 TBSM data server startup log

2. The object server is started and connected to the data server, as seen in message GTM4041I in Figure 2-12 on page 56. It then allocates LU 6.2 sessions or a TCP/IP session.

– An LU 6.2 session is indicated by message GTM7406I, and the transaction programs are initialized as indicated by the GTM7424I messages.

– An IP session is indicated by messages GTM8205I and GTM8252I, as shown in Figure 2-12 on page 56.

GTM5000I TBSM DATASPACE INITIALIZATION STARTINGGTM4600I EXTENDED RECOVERY ENVIRONMENT ESTABLISHEDGTM4110I GTMDSPC , USING ID 01GTM5002I PROCESSING PARMLIB MEMBER: PDSC6900GTM5101I TBSM DATASPACE CREATED, SIZE= 42467328, ORIGIN=00000000GTM5030I MODIFY INTERFACE ESTABLISHED, CONSOLE COMMUNICATION AVAILABLEGTM5010I TBSM DATASPACE INITIALIZATION COMPLETE


Figure 2-12 TBSM object server startup log

3. The object pump is started and, as indicated by the log in Figure 2-13 on page 57, it performs the following:

– Issues the MONITOR command.

– Allocates an MCS console, as indicated by IEA630I.

– Connects to the object server, as indicated by GTM1620I.

– Starts the registration process, as indicated by GTM1770I and GTM1780I.

GTM7500I INITIALIZATION IN PROGRESSGTM4600I EXTENDED RECOVERY ENVIRONMENT ESTABLISHEDGTM4110I GTMSRVR , USING ID 01GTM7508I TBSM SERVER DETECTED, JOBNAME=GTMDSPCGTM4403I Q WARM STARTED, QADDR=00001000, ALET=01FF001B, SIZE=100 PAGES, ID=GTMSRVRGTM8205I GTMIPSND : READY TO TRANSMIT TO 9.3.5.11 PORT(1022)GTM8252I GTMIPRCV : LISTENING ON PORT 1024GTM4403I Q WARM STARTED, QADDR=00071000, ALET=01FF001B, SIZE=50 PAGES, ID=GTMLOGGTM4200I ALLOCATION SUCCESSFUL, DDNAME=ACC1LOG , S99ERROR=0000, S99INFO=0000, DSNAME=GTMV2R1.SC69N.SRVR.LOG1GTM4010I TBSM INITIALIZATION COMPLETED


Figure 2-13 TBSM object pump startup log

– The object registration handshake is explained from the Windows side in 2.4.3, “Object registration process” on page 60.

2.4.2 Windows servers connectionThe connection to IBM Tivoli Business Systems Manager servers is shown in Figure 2-14 on page 58.

GTM7500I INITIALIZATION IN PROGRESSGTM4600I EXTENDED RECOVERY ENVIRONMENT ESTABLISHEDGTM4110I GTMPUMP , USING ID 01GTM7508I TBSM SERVER DETECTED, JOBNAME=GTMDSPCGTM4403I Q WARM STARTED, QADDR=00066000, ALET=01FF0010, SIZE=10 PAGES, ID=GTMPUMPGTM7801I STORAGE ALLOCATED FOR 10,016 TRAPSGTM7524I VTAM 3270 SERVICES ARE NOT AVAILABLEMN JOBNAMES,TMONITOR SESS,TIEA630I OPERATOR TM39069 NOW ACTIVE, SYSTEM=SC69 , LU=TM39069GTM7545I TM69 : SUBSYSTEM INITIALIZEDGTM7815I TBSM HAS CONNECTED TO RODM : RODMGTM7890I PPI RECEIVER IS ACTIVEGTM7501I RUNNING INITIAL REXX EXEC : GTMRX004GTM0001I TBSM INITIALIZATION STARTED - 4 Dec 2002 11:05:29GTM0002I SYSTEM WAS IPL'D ON 10/23/2002 (102302) AT 16:52:42GTM0003I TBSM IS RUNNING ON SYSTEM SC69GTM2101I LOG PROCESSING IS AVAILABLE. DDNAME = ACC1LOGGTM2102I DSNAME = SYSOUT(A)GTM2104I THE LOG WILL BE CLOSED AND OPENED ON THE FOLLOWING INTERVAL: 04:00:00GTM1620I OBJECT PUMP TO OBJECT SERVER HANDSHAKE STARTEDGTM0220I TBSM LOGON PROCESSING INITIALIZATION STARTED ...GTM1001I TBSM EVENT MANAGER INITIALIZATION STARTED ...GTM9520I TBSM COMMAND PROCESSOR INSTALLEDGTM0990I TBSM INITIALIZATION COMPLETEDGTM1770I ALL REQUIRED SHARED VARIABLES HAVE BEEN REGISTERED, PROCESSING CONTINUESGTM1780I OBJECT PUMP/OBJECT SERVER IS REQUESTING OBJECTS


Figure 2-14 Connection from z/OS to TBSM servers

For the SNA connection, the Tivoli BSM MVS Listener (or ASIMVSListenerSvc) receives messages or exceptions from the z/OS system. Once the connection to the z/OS system is established by the object pump, the SNA server and the Source/390 object server attempt to allocate a conversation. When the Source/390 object pump is started, it contacts the MVS Listener.

The MVS Listener is an auto-start transaction program. It is started automatically by the TPSTART program when a message is sent by the object pump after the connection between the IBM Tivoli Business Systems Manager and the SNA server is established. It stops when the connection is lost. The transaction program (TP) name for the MVS Listener is ACC1RCV.

For the IP connection, the Tivoli BSM MVS IP OS Listener (ASIMVSIPOSListenerSvc) listens to its port, typically 1022. When a connection is detected, it spawns a thread to handle the communication.

Event Server

SNA Server

SNA Client

MVS Event handler

MVS Listener

TPStart

MVS Sender

Enqueue Proxy Server

MVS Upload RuleServer

Upload queue Receivequeue

Object Server

VTAM

Source/390programs

(ksh)

Event Server

MVS Event handler

MVS IP OS ListenerMVS IP Sender

Enqueue Proxy Server


Upload queue Receivequeue

Object Server

TCPIP

Source/390programs

(ksh)


After the program is initialized, the MVS Listener begins to receive data from the z/OS system and looks for the existence of a queue file that has the same identifier as the z/OS system being monitored. For example, the queue file for SC66 is SC66.que. If the queue file exists, it begins to insert data into the file. If the file is not present, the MVS Listener then initializes a message queue file and begins to insert data into it.

The Tivoli BSM MVS Event handler service (ASIMVSEventHandlerSvc) periodically checks the message queue file for data. If the data is present, it reads the message from the queue and inserts it into the database.

There are some commands executed automatically during the startup of Source/390 following a system IPL or Source/390 restart. These commands perform such tasks as initializing Source/390, registering objects, and requesting file status. You can also use the Source/390 command from the IBM Tivoli Business Systems Manager console using context menus of the operating system object.

The automatic execution of these commands results in Source/390 sending state information in the form of messages to the IBM Tivoli Business Systems Manager servers. Upon receipt of these state messages, the Tivoli BSM MVS Upload Rule Server service (ASIMVSUploadRuleSvc) evaluates the information, formulates the proper commands to send, and finally uploads the proper command or command set to Source/390, where they are executed. The MVS Upload Rule Server service runs on the Event Server. Upload rule processing is triggered by the event handler upon inserting the event into the database.

In addition to processing messages regarding the initialization of Source/390, the MVS upload rule server evaluates other conditions that are of concern to the proper execution of the Source/390 environment.

When the z/OS upload is enabled, the reply message is sent back to the Event Server machine through the Tivoli BSM Enqueue Proxy Server (ASIEnqueueProxyServer), which puts the events in an upload queue file. An example of an upload queue file in our example environment is SC66-Upload.que. The Tivoli BSM MVS Sender service (ASIMVSSenderSvc) or Tivoli BSM MVS IP Sender service (ASIMVSIPSenderSvc) checks the queue files and sends the message back to the Source/390. For the SNA connection, it uses the ACC1RECV transaction program, which invokes the ACC1RECV program in the object server address space. For the IP connection, it will connect to the object server listening port, which typically is 1023.


2.4.3 Object registration processIn this section, we discuss in more detail the object registration process, which is a conversational mechanism from the object pump to the IBM Tivoli Business Systems Manager input component for getting an automated status of any z/OS object.

Figure 2-15 shows a flow chart of the initial connection of the Source/390 to the IBM Tivoli Business Systems Manager input component.

Figure 2-15 Initial conversation for TBSM connection

The message exchange is conducted in an internal form. You can peek on the messages in the queue files that are used by the Listener and Sender services. These queue files are stored in TivoliManager\Data\Queues, and are named after the z/OS system that they belong to. For example, SC66 has a listener queue called SC66.que and a sender queue called SC66-Upload.que.

The message is separated into fields with the backslash character (\, ASCII x’5C’, EBCDIC x’E0’) and ended with a tilde character (~, ASCII x’7E’, EBCDIC x’A1’). The first two fields are named the format type and action type fields. The format type and action type fields uniquely differentiate the messages for usage and field contents. A sample message is given in Figure 2-16 on page 61.

01/01OS identification

02/12Variable creation

ENT - COMP - MACH - LPAR-OS

02/04Request objects

02/05TrapCreation

All object traps under the OS (STC, batch, DB2,IMS, CICS etc)

02/09Omegamon

For each Omegemon objects

02/10Batch Registration

02/15TDQ Registration

02/20RMF Registration

including each metrics in RMF profile

OS/390 -> WinNT

WinNT -> OS/390


Figure 2-16 Sample message

In the case of an STC resource called NPM in our SC66 operating system, we can see the data exchanged as shown in Figure 2-17.

Figure 2-17 Queue file contents

The object registration event occurs in the following sequence:

1. When the object pump is connected to the listener, it sends the identification noting the timestamp of the event and that the operating system name is SC66. The event is received by the MVS listener and stored to the database through the MVS event handler.

2. The variable registration messages are sent by the MVS sender services.

3. Upon receiving the variables, the object pump sends the indication that it is ready to receive the list of objects to be monitored using the 02\04 record by sending the SC66 OS’s object ID.

4. ASIMVSUploadRuleSvc evaluates the message received by the listener and puts the appropriate reply message into the upload queue. ASIMVSSenderSvc reads the SC66-Upload.que file and sends it to the object pump.

Format type - Action type fields02 Functional command05 Object monitoring

02\05\ 02STC\03NPM\ 040004E4000C\ 45ACTIVE\46FNM025~

Tilde, end of messageA typical field04 Field type object identificationrest data

02\12\02ENT\03Mainframes\040000040001~02\12\02COMP\03ITSO\040000090002~02\12\02MACH\03SC66Machine\0400001B0003~02\12\02LPAR\03PRIMARY\040000200005~02\12\02OS\03SC66\040000240006~

02\05\02STC\03NPM\040004E4000C\45ACTIVE\46IEF403I\45INACTIVE\46IEF404I~

01\01\002000022013:09:46.710538\01SC668\02OS\03SC66~

02\04\002000022013:12:05.635942\01SC6613\02OS\03SC66\040000250006~

02\01\002000022013:14:02.920700\01SC6620\02STC\46IEF403I\03NPM\ 040004E6000C\45ACTIVE\49NPM - STARTED - TIME=13.14.02 - ASID=0089.~

data sent from OS/390

data sent to OS/390

1

2

3

4

5


5. When the event that is trapped occurs, the object pump initiates the 02\01 message to inform the status change of the affected object.

The following is a list of commonly used field identification:

00 Timestamp in the format of YYYYMMDDHH:MM:SS.UUUUUU

02 Object type ID, similar to the content of cid column in obj_class table

03 Object name.

04 Native key. A unique 10-character object identification that is constructed of the hexadecimal value of the object ID and the class ID.

45 State. The value that will go to the state attribute of an object.

46 Message ID that is trapped. This must also exist in the MessageDescription table.

49 Description text.

By evaluating the queue files and the IBM Tivoli Business Systems Manager log files, you may be able to determine the problem in the object registration process.

2.4.4 Bulk discoveryFor z/OS operation, we explain two types of bulk discovery related to populating the IBM Tivoli Business Systems Manager object hierarchy with resources:

� Bulk discovery of z/OS high-level resources from preformatted files to load to the database.

� Bulk discovery using dynamic discovery of subsystems and sending the information through the MVSIPListener

Bulk object discovery: high-level loadIBM Tivoli Business Systems Manager’s operation is based on the objects that represent the relevant system resources within an enterprise. Therefore, an exhaustive discovery of all system resources is a critical step in the successful implementation of the product.

Initial object placement for the z/OS mainframe is critical. A set of hierarchy resources must be defined in the IBM Tivoli Business Systems Manager database, and the initial hierarchy that defines the Operating System object must be present before any work can be performed. The high-level load presets this hierarchy.


z/OS mainframe based objects can be either high-level or low-level. The high-level objects, in order of top-down hierarchy, are:

� Complex� Machine� LPAR� Operating system (OS)

The low-level objects are all the objects below the Operating System, as described in the physical hierarchy. The low-level object is defined from dynamic discovery from the subsystems, such as automation product or others.

The high-level bulk discovery involves processing a control file that contains the structure of each z/OS or OS/390 system. This file usually is created manually. Our definition is provided in “ITSO_Highlevel - Sample high-level load source” on page 564. Each line in this file contains the hierarchy of each operating system. For example, for SC66, we used the following line:

Mainframes/ITSO Enterprise/ITSO//SC66Machine//Primary//SC66/

Mainframes is the name of the enterprise, ITSO Enterprise is its description, ITSO is the name of the Complex, SC66Machine is the machine, Primary is the name of the LPARs, and SC66 is the Operating System.

The high-level load uses the ITSO_Highlevel input file. The format of each line is simply the name and description of each of the high-level object types separated by a backslash. When we have a blank descriptions field, it is shown as a double backslash.

To load the high-level objects into IBM Tivoli Business Systems Manager, a Korn Shell script was executed by entering the following command at the command prompt:

sh ASILoad_Highlevel.ksh ITSO_Highlevel.txt

The contents of ASILoad_Highlevel.ksh are shown in “ASILoad_Highlevel.ksh” on page 560. After the load completed, the Resources view looked like Figure 2-18 on page 64.


Figure 2-18 The Resources view after the high-level object load

Subsystem bulk discoveryThis process sends the files generated by the pre-discovery job to the MVS IP listener. The OS/390 program GTMAOPE0 sends the file through TCP/IP to the MVS IP listener process in Windows NT server. At the end of the file transfer, the CreateDiscoveryBatch.ksh script is triggered to prepare the file loading into the database.

The GTMAOPE0 program is controlled by the parameters in the SYSIN file. The file to be downloaded is in the SYSUT1 file. A sample SYSIN for GTMAOPE0 is shown in Figure 2-19 on page 65.


Figure 2-19 Parameters of the GTMAOPE0

GTMAOPE0 functions similarly to FTP (File Transfer Protocol). These are some of the acceptable parameters:

TCP/IP_ADDRESS The address of machine that runs the MVS IP listener.

TCP/IP_PORT Port number for the MVS IP listener; 1021 is the default.

CODEPAGE The codepage of the OS/390 prediscovery file. This parameter is used when the conversion is needed.

COMMAND Command alias that will be translated by the MVS IP listener to a certain Windows NT command.

CONVERT Whether to convert the data from the mainframe codepage to the codepage of the MVS IP listener.

TEXT Whether the conversion is for binary data or text.

FORMAT The format code of the data, indicating what subsystem the data belongs to.

The ASIMVSIPListenerSvc or Tivoli BSM MVS IP Listener service runs at the Event Server. It receives the data from the GTMAOPE0. Some parameters have to be customized in the Windows registry for the MVS IP listener as shown in Figure 2-20 on page 66.

//SYSIN DD * TCP/IP_ADDRESS=9.3.187.194 TCP/IP_PORT=1021 CODEPAGE=037 COMMAND=DB2DISCOVERY CONVERT=NO TEXT=NO FORMAT=X'11' /*


Figure 2-20 MVSIPListener registry definitions

The following information must be put in the registry:

� The IP port used for the file transfer must be defined in the Port value.

� All the OS/390 IP addresses that connect to the IP listener must be defined as a value in the ValidClients sub-key.

� The translation of the COMMAND parameter of the GTMAOPE0 to Windows NT commands must be provided in the CommandAliases sub-key.

The content of the current CommandAliases is shown in Figure 2-21 on page 67.


Figure 2-21 Command aliases

For the CreateDiscoveryBatch command, the -C flag activates the CODEPAGE parameter, and the -F flag activates the FORMAT parameter of the GTMAOPE0 parameters.

When a pre-discovery file is received by the database server, it is saved in the Windows default temporary directory in a file called ~TVx.TMP, where x is a hexadecimal sequence number.

This process is executed in three steps:

� The CreateDiscoveryBatch script is triggered at the end of the file transfer. It prepares the required environment to allow the Discovery Load job. It renames the temporary files as BCP files and creates a Batch record in the DiscoveryBatch table.

� The Discovery Load job for each subsystem reads the pre-discovery file and fills a temporary SQL table with the subsystem objects. These jobs should be scheduled regularly using the SQL Server Agent. It will trigger the Microsoft SQL Server BULK INSERT command.

� The Discovery Process job generates the required environment to create each object in the temporary table. At the end of this process, the job state is set to COMPLETED in the DiscoveryBatch table. This job can be started manually or scheduled using the SQL Server Agent, similar to the Discovery Load job. The Discovery Process job takes a long time to run and consumes a lot of resources, so you should schedule it to run at off-peak time.


2.4.5 Command supportCommand support to the z/OS systems is supported using the Tivoli NetView for z/OS. The communication path, as shown in Figure 2-14 on page 58, uses the Tivoli BSM Task Server that communicates using the NETCONV session to Tivoli NetView for z/OS.

An operator can invoke a menu or command, and IBM Tivoli Business Systems Manager will route the command to the task server utilizing the tgmtask utility.

A NETCONV session must be maintained using a logged-in operator. Typically you would use an AUTOTASK to maintain this session. More about the setup of the NETCONV sessionis in 10.2, “Setting up Tivoli NetView for z/OS” on page 338.

2.5 History server, reporting, and health monitorThis section contains additional information about the optional components that IBM Tivoli Business Systems Manager uses:

� 2.5.1, “History server” on page 68

� 2.5.2, “The reporting system” on page 70

� 2.5.3, “Health monitor” on page 74

2.5.1 History serverThe history server contains the image of the current IBM Tivoli Business Systems Manager database that is not pruned overtime by the operational tasks to maintain the performance of the operational database.

A history server can be set up in two ways, as shown in Figure 2-22 on page 69:

� Linked Server

� Bulk Copy Program (BCP)

Note: The recommended solution is to implement the BCP method.


Figure 2-22 History server setup

As you can see, these approaches use different methods to transfer data from the database server to the history server (assuming they are installed on separate machines). You should install only one of them.

Linked Server approachThe Linked Server approach uses Microsoft SQL Linked Server implementation to move data directly from the database server to the history server using OPENQUERY. Unlike the BCP approach, the history server does not need to have IBM Tivoli Business Systems Manager installed. The Event History database is created if it does not exist. Setting up the history server with the linked server approach is much easier with the linked server approach than with the BCP approach. The reporting system is configured to retrieve historical data from the database server. This has an impact on database server performance.

Optionally, the linked history server can be set up on the IBM Tivoli Business Systems Manager database server (single-server approach) if the environment is small.

Bulk Copy Program (BCP) approachThe BCP approach uses the bcp command to copy data (events) out of the database server. The bcp command transfers data to the history server and then into the database table. The history server database has to be synchronized with the database on the database server.

Linked Server

TBSM

SQL

TBSM

SQL

TBSM

SQL

TBSM

SQL

Bulk Copy Program (BCP)


The BCP method does the following:

� Moves BCP events from the primary IBM Tivoli Business Systems Manager database server to the history server at five-minute (tunable) intervals.

� Periodically restorates the IBM Tivoli Business Systems Manager’s Object, Meta, and RODM databases to the history server from the primary database server.

� Performs cleanup on events transferred from the Object database on the primary database server to boost performance.

2.5.2 The reporting systemThe reporting system is implemented at the history server. It uses the Microsoft Internet Information Server. The reporting system creates a directory alias in the Microsoft Internet Information Server as shown in the Internet Service Manager window in Figure 2-23. The directory is ASI, which refers to the path C:\TivoliManager\ASIReports\ASIWeb.

Figure 2-23 Microsoft IIS virtual directories


It uses various Active Server Pages (ASPs) to connect to the Microsoft SQL Server database in the history server to show the reports.

Start the Reporting System directly within the application of the IBM Tivoli Business Systems Manager console. Select an object from any open view, right-click the object, and use Open-> Reporting System. Figure 2-24 shows how to start the Reporting System directly from an IBM Tivoli Business Systems Manager console application.

Figure 2-24 Reporting system invocation


This will display the Event Report Selection screen for the object you choose, as showin in Figure 2-25.

Figure 2-25 Object Event Report Selection screen


Depending on your view and the object you select, dialog windows enable you to select specific criteria for your report selection. After you make your filtering selections, click Submit to generate the report. Figure 2-26 shows the generated report using the selection criteria shown in Figure 2-25 on page 72.

Figure 2-26 A generated report


2.5.3 Health monitorThe health monitor keeps track of the health of IBM Tivoli Business Systems Manager and enables you to view the performance and availability of IBM Tivoli Business Systems Manager components. You can monitor the various services, disk utilization, database space, system queues, and connections to the various data sources.

The health monitor is installed onto a machine using the base services install option. As an option you can select to install the health monitor server or health monitor client.

The health monitor server is a Windows service that runs the HMSQueries.ksh and records the output in a file under the Mgmt$\Output directory. The health monitor client then connects to this network share and displays system health status, as shown in Figure 2-27.

Figure 2-27 Health monitor client window


You can customize the health monitor to fit your IBM Tivoli Business Systems Manager implementation. However, the Windows registry setting must be modified for your particular environment. Modifications for adding or deleting services and other parameters take place in the health monitor server in the Health Monitor registry key under the path:

HKEY_LOCAL_MACHINE\Software\ Accessible Software, Inc.\Access1\1.0

It is shown in Figure 2-28.

Figure 2-28 Registry Editor for Health Monitoring profile


Chapter 3. Database structure

This chapter provides a general description about the IBM Tivoli Business Systems Manager database. The discussion is based on IBM Tivoli Business Systems Manager Version 2.1 and may not apply to other versions of IBM Tivoli Business Systems Manager.

� 3.1, “Microsoft SQL Server overview” on page 78 gives an overview of Microsoft SQL Server

� 3.2, “The databases” on page 80 describes IBM Tivoli Business Systems Manager databases

� 3.3, “Object implementation” on page 80 discusses how IBM Tivoli Business Systems Manager implement its objects

� 3.4, “Status propagation” on page 87 discusses status propagation concepts and implementation

� 3.5, “Agent listener resources” on page 91 describes the database extension that is used by the agent listener

� 3.6, “Common listener resources” on page 95 describes the database extension that is used by the common listener

� 3.7, “Menu and command” on page 97 discusses menu and command implementation in IBM Tivoli Business Systems Manager

3


3.1 Microsoft SQL Server overviewMicrosoft SQL Server is a full-function database platform that provides an advanced RDBMS processing function with a tight integration into the operating system. We used Microsoft SQL Server 2000 for our examples.

Microsoft SQL Server has the following services:

� SQL Server engine, which is the primary process that performs the RDBMS function

� SQL Server agent, a job-scheduling function that automates execution of certain database functions on a given schedule

� Microsoft Distributed Transaction Coordinator (MSDTC), which is not used by IBM Tivoli Business Systems Manager

When it is initially installed, Microsoft SQL Server comes with the following databases:

� master: The primary database of this Microsoft SQL Server instance, which contains other databases and extended stored procedure information

� model: The database that will be used for creating new (empty) databases

� msdb: Database for SQL Server agent and log-forwarding feature information

� tempdb: Temporary database for creating and using temporary tables, such as tables that start with a hash sign (#)

� Northwind: A sample database

Each of those databases is implemented initially as a single file. Each database has a log file associated with it to record any incomplete transactions.

These are the important objects in the user database:

� Tables and indexes to store data.

� System tables to store database objects. The names are typically have the sys prefix.

� Trigger, a program that is executed on a certain condition of a row in a table, such as insertion, update, or deletion.

� Stored procedure, which performs a specific action that can be called as a single transaction.

� User defined data types and functions, which provide the user flexibility when defining new columns or variable types and new data processing routines.


Both trigger and stored procedure are written in a proprietary language called Transact-SQL. This is a structured programming language that can imbed and execute SQL command without the need to compile it.

The important tools for administering Microsoft SQL Server are:

� Microsoft SQL Server Enterprise Manager: a snap-in application to Microsoft Management Console that enables almost any database administration function to be performed, even launching other tools. The sample Microsoft SQL Server Enterprise Manager screen in Figure 3-1 shows the available servers with all the objects underneath them.

Figure 3-1 Microsoft SQL Server Enterprise Manager

� SQL Query Analyzer (isqlw): An interactive program that enables execution of SQL command and displays the result. A non-GUI version of the Query Analyzer can be called from the command line using the isql command.

� SQL Query Profiler: A tracing tool that shows the applications accessing the database engine and the SQL statements that have been executed. This is an excellent debugging tool for a large number of components, as it enables you to see the SQL statements that are issued by each component.

Chapter 3. Database structure 79

3.2 The databasesIBM Tivoli Business Systems Manager comes with pre-populated databases. Detailed installation procedure is given in 6.3, “Database server installation” on page 176. The following databases are provided:

Objects The primary IBM Tivoli Business Systems Manager database that stores most of the management data. As the name implies, it stores IBM Tivoli Business Systems Manager objects information, attributes, and links.

ASIRuleSvc Rule database that contains a mirror image of selective IBM Tivoli Business Systems Manager objects for rule processing. This database offloads some heavy rule processing from the main object database, as most of the rules are not concerned with state changes.

Meta Metadata database that contains the most information about IBM Tivoli Business Systems Manager database objects structure, attributes, and methods. Some of the tables here are provided as views in the object database.

RODM, RODMLoad Temporary loading database for SNA network objects from RODM.

OPCLoad Temporary loading database for Tivoli Workload Scheduler (used to be called Tivoli OPC) data.

WebServer Database for the help and reporting system resources.

ObjectEvents Contains the processing queues of IBM Tivoli Business Systems Manager. Each queue isrepresented in three tables: Pending<qtype>, LastProcessed<qtype>, and Processed<qtype>.

ObjectQueues Not used.

3.3 Object implementationIBM Tivoli Business Systems Manager uses an object-oriented data structure. It implements the objects in Microsoft SQL Server relational database. Typically, an object in IBM Tivoli Business Systems Manager has:

� Class definition and attributes

� Methods that can be invoked

� Links to other objects

Our discussion provides some information about object implementation.


3.3.1 Important information sourcesTables that show important information about IBM Tivoli Business Systems Manager object structure typically reside in the Meta database, but they can be accessed through views in the Object database. Those are:

obj_class Primary table that contains an object’s class definition.link_type Primary table that describes existing link types.isa_table Inheritance structure table.obj_link_table Lists all possible links between object types.link_chain Generated containment structure table.isa_chain_table Generated inheritance structure paths.method_table Lists the available methods for a specific class.

Extensions to these core information tables address required new functions. These additional informational tables are not related directly to the object implementation, but provide good information about the IBM Tivoli Business Systems Manager object classes:

� Tables provided with the IBM Tivoli Business Systems Manager agent listener implementation:

GEM_LookupCID Provides a master list of all Gxxx classes that are dynamically created and mapped to the triplet (the information about Manufacturer, Product, and Version). The triplet is the key matching attribute for the TEC integration as discussed in Chapter 7, “TEC components integration” on page 209.

GEMIDLookup Provides the field key lookup for TEC-related objects, such as IP Address, TMR, and host name, so that finding an object does not require searching through multiple tables with dynamically created names Gxxxcname_C and Gxxxcname_A.

GEM_DMtoCID Provides a mapping for the ‘old’ Tivoli Distributed Monitoring Version 3.6 objects implementation. Multiple DM profiles can be mapped to a single IBM Tivoli Business Systems Manager class, therefore this table is necessary.

� Tables provided with the Common Listener implementation:

CL_AutoPlacement Mapping of instrumentation to enterprise

CL_LinkRules Rules for creating a link based on the cid and other attributes

CL_Options Common Listener global options

CL_Registration All known registered connectors


CL_RegistrationList List of objects registered through the common listener

CL_Severities Platform-specific severity mapping to alert state

CL_Stage List of staging transactions whose data resides in the tables CL_StageBulkData, CL_StageDeltaData, and CL_StageEvData

CL_Status Status of staging load processes

3.3.2 Object structure implementationAn object is implemented as a set of tables, indexes, stored procedures, and triggers. An object class has the following primary attributes, which are stored in obj_class table:

cid Class ID, which is a 4 characters name of the object classcno Class number, which is a numeric identifier for each cidcname Class name, which is the long name for a cidcdesc Class description

Example 3-1 shows these attributes from the Network Region class.

Example 3-1 Attributes of the Network Region class

> select cid, cno, cname, description, label from obj_class where cid = 'NREG'

cid cno cname description label ---- ------ ------------- ----------------- ----------------- NREG 253 NetworkRegion Network Region Network Region

(1 row(s) affected)

Typically an object class will have the following tables:

<cid>_ID A single row, single column table that contains the next instance ID for the specific cid.

<cname>_C Primary table for the class that stores all the standard attributes for instances of this class. This table is indexed with the instance ID.

<cname>_A Attribute table for all non-standard attributes of a class.

<cname>_S Provides such class-wide information as status propagation information, icons, and other attributes.

<cname>_V The existence of this view signifies that this is a managed object, not an abstract object that is used internally by IBM Tivoli Business Systems Manager.


Each object has links to other objects in IBM Tivoli Business Systems Manager that are implemented as link tables. There are several important link types:

PHYC Physical containment link. These are the links that build the object hierarchy in IBM Tivoli Business Systems Manager’s All Resources View.

LOBC Business Systems containment link. These are the links that build the IBM Tivoli Business Systems Manager business systems hierarchy structure.

LOB This link provides a mapping from the real object class to a business system object. See 3.3.3, “Business Systems implementation” on page 84.

TOPO Topology link, used for the new Topology views in IBM Tivoli Business Systems Manager V2.

There are other links that signify links to other object types, such as propagation information. See 3.4, “Status propagation” on page 87 for more about these.

Links are implemented in tables. Using the physical containment for the Network Region class as an example, the containment table displays the information as shown in Example 3-2.

Example 3-2 Containment information for Network Region

> select src_cid, dst_cid from Meta..obj_link_table where src_cid = 'NREG' or dst_cid = 'NREG' and link_type='PHYC'

src_cid dst_cid ------- ------- ENT NREGIPNW NREGNREG NLOCNREG R3SY

(4 row(s) affected)

As you can see, only certain classes can connect to the Network Region object. Link tables are created for each class that can connect, so these are the tables for our example:

� ENT_NREG_PHYC� IPNW_NREG_PHYC� NREG_NLOC_PHYC� NREG_R3SY_PHYC


The content of these link tables is reflected in a table called link. Specifically for PHYC links, the content also is reflected in a table called containment.

Each object class has default stored procedures that are used for basic manipulation of the object. Typically these stored procedures are created:

alloc<cid> Allocates a new ID and increment the <cid>_ID table

asisp_create<cid> Creates a new instance of cid

delete_<cid> Deletes an instance of cid

asisp_view<cid> Retrieves instance information of an object in cid

asisp_joinedview<cid> Combines a view from the view table and an arbitrary table

cl_process<cid> Common listener processing for the cid

Certain triggers are created to ensure data validity and consistency. There are three types of triggers: insert, update, and delete. Triggers are specific to a table, and IBM Tivoli Business Systems Manager typically names the triggers t<type>_<tablename>, where type can be I, U or D. The following are some trigger examples:

� Most of the <cname>_C tables have update triggers that increment the revision number and set the ctime (changed time) column to the current timestamp.

� Most of the <cname>_C and <cname>_A tables that are monitored have insert and update triggers that will queue information to the Automatic Business System feature of IBM Tivoli Business Systems Manager.

� Note object has an Update trigger to provide closure for external events that are closed by the Take Ownership function.

3.3.3 Business Systems implementationA special class has been created for implementing provided business systems. This class is called LineOfBusiness (LOB), and is special in that:

� It is not part of the physical containment hierarchy (All Resources View).

� It can have multiple icons depending on the LOB link that exists between the object and an object in the physical containment hierarchy.

� It can be nested in the Business System View any way you prefer.

� Some propagation attributes can be modified for each instance so that it will be able to accomodate any type of business system condition.

Each object that appears in the Business System View has a single type, which is derived from the LOB class. Except for the container objectsthat represent the


original business system object, the rest of the business system objects are mapped to a real object. Therefore, we call these objects shadow objects.

3.3.4 ROOT, BUSC, and LOBC objectsThe only ROOT object in IBM Tivoli Business Systems Manager is the initial object from which all objects descend. The ROOT object has an ID of 0001. In the database, the ROOT object has two objects under it: the Business System Container (BUSC) object and the LOB Container (LOBC). There is only one instance each for BUSC and LOBC classes.

The BUSC object precedes all the objects in the All resource view, which sometimes is called the physical tree. The LOBC object precedes all the business systems objects, sometimes called the logical tree.

3.3.5 Object hierarchyIBM Tivoli Business Systems Manager has two types of object hierarchy: containment and inheritance. The containment hierarchy enforces what object can be a descendant of an object, while the inheritance hierarchy provides the inheritance feature of the object-oriented programming.


Figure 3-2 on page 86 shows a sample of the containment hierarchy.

Figure 3-2 Part of TBSM containment hierarchy

Enterprise

Complex Network Region

Machine

LPAR

OS

Batch Job Set

Batch Job

Batch ScheduleSet

Batch Schedule

File

DB2objects

CICS

R3

R3 DB

R3 AS

MQSeries

MQManager

MQ Queue

MQ Channel

MQ Process

STCIDMS Sybase

IMSobjects

Network Location

NT Server UNIX Network Node

GEMobjects


The inheritance hierarchy has several abstract object classes. Part of the inheritance hierarchy is shown in Figure 3-3 on page 87.

Figure 3-3 TBSM inheritance hierarchy

3.4 Status propagationOne of the main features of IBM Tivoli Business Systems Manager is status propagation, the ability to aggregate the status of objects into meaningful information in the business systems. Here we discuss the database implementation and the details about how status propagation works. This concept is very important when you design a business system that you want to reflect meaningful conditions.

In IBM Tivoli Business Systems Manager, the status of an object will be propagated upward in its hierarchy. Figure 3-4 on page 88 shows the propagation concept in IBM Tivoli Business Systems Manager.

Base

DB2 base

IMS Base

MVS RegisterableWindows Viewable

Object

Managed Object

Managed Object 2

MVS Job

STC

GEM Base SC

GEM GEM SC GEM DM SC GEM MF SC

GEM ExtendedGeneric SC

GEM Generic SC

RODM ManagedObject

SNMP ManagedObject

CICS ObjectDirectly Contained

Object

Event

Exception Message


Figure 3-4 The propagation concept

Propagation is an incident that occurs when a IBM Tivoli Business Systems Manager object receives an event. The event can be a message, an exception, or a child event.

Each IBM Tivoli Business Systems Manager object has the following attributes that relate to the propagation mechanism:

Alert State The object property that defines the color-coded status of the object. The alert state can have the value of Green, Yellow, or Red.

State The presumed actual state of the object in the enterprise. State values are dependent on the object type. For example, a DASD object can have the state of being Off-line, Online, or Boxed; and a Batch Job object can have the state Inactive, Running, Completed, Amended, Starting, and Stopping.

Object priority Determines the priority of a child event that will be generated by this object when the propagation condition is fulfilled. The priority can have the following values: Critical, High, Medium, Low, Ignore, or Inherit from event.

Propagation matrices This entity contains two types of matrices: exception and child event. An exception matrix indicates the number of exceptions of a particular alert state and the priority that

High Medium Low

Red

Yellow

High Medium Low

Red

Yellow

Exception matrix

Child Event matrixM

essa

ge

Chi

ld e

vent

Excep

tion

Chi

ld e

vent

Alert State

State

Priority

Object


an object has received. A child event matrix indicates the number of child events of a particular alert state and the priority that an object has received.

When an event is received by an object, the following things happen:

� The event may change one or more of the object’s attributes.

� An event with the priority of Critical always generates one or more child events.

� An event with the priority of Ignore never generates a child event.

� Other priorities of an event may trigger one or more child events to another object.

A generated child event has two important properties: the Alert State and priority. The Alert State of a generated child event is always equal to that of the original event. The priority of a generated child event is equal to the Object priority of the object generating the child event. In the case where the Object priority is Inherit from event, the generated child event priority will be the same as the original event priority.

The processing of an event that an object receives differs based on the event:

� State or message

When a message is sent, it is matched with the message attribute in the IBM Tivoli Business Systems Manager database. A message has Alert State, State, and Priority attributes. The affected object sets its Alert State and State to those of the message. The message event always creates one or more child events to higher-level objects.

� Exception

When an exception is received from a performance-monitoring tool, it is matched with the exception attribute in the IBM Tivoli Business Systems Manager database. An exception has Alert State and Priority attributes.

Unless the exception priority is Critical or Ignore, the affected object changes the counter in the Exception Matrix according to the exception’s Alert State and Priority. When the exception counter in that matrix has exceeded the maximum number of exceptions for this Object type or falls below it, the object Alert State is changed accordingly, and one or more child events are generated.

� Child event

The processing of a child event is similar to the processing of an exception. Unless the child event has the priority of Critical or Ignore, the received child event changes (add or subtract) the counter in the Child Event Matrix according to the child event’s Alert State and Priority. When the child event


counter in that matrix has exceeded the maximum number of exceptions for this Object type or falls below it, the object Alert State is changed accordingly, and one or more child events are generated.

The propagation process can be illustrated with the flow chart shown in Figure 3-5.

Figure 3-5 Propagation algorithm

Type=

Message

Eventreceived

ApplyAlert State andState to Object

Increase Counter inException Matrix basedon its Priority and Alert

State

Increase Counter in ChildEvent Matrix based on

its Priority and Alert State

Priority=

Critical

Yes

No

No

Priority=

IgnoreYes

ApplyAlert State to

Object

Log event andcontinue

Type = ChildEvent

No

YesNo

ExceedException

Limit?

Exceed ChildEvent Limit?

Yes

Yes Yes

No No

Generate ChildEvent


The propagation has to be customized for each installation so that:

� Meaningful status is reflected from the workstation. This includes the correct representation of each alert status in the enterprise.

� Thresholding for objects gives the necessary filter for unwanted events.

� Certain objects that are very important will be given higher priority.

� Certain messages will be emphasized to show their priority.

3.5 Agent listener resourcesThis section discusses the implementation of the resources from the agent listener. The discussion is divided into:

� 3.5.1, “Class implementation” on page 91

� 3.5.2, “AMS tables” on page 93

3.5.1 Class implementationThe agent listener objects are implemented in IBM Tivoli Business Systems Manager by extending its database data structure. A new abstract object is created as the base class of the GEM objects. These classes are constructed in the hierarchy shown in Figure 3-6. (This is the inheritance hierarchy.)

Figure 3-6 GEM object classes in TBSM

These components in IBM Tivoli Business Systems Manager are defined with the class ID of Gxxx, where xxx are any alphanumeric characters. The class name is represented as Gxxxcname. As with the standard IBM Tivoli Business Systems Manager class discussed in 3.3, “Object implementation” on page 80, agent

GEM Software ComponentGMSC

GEM MainframeGMMF

GxxxGxxx

Gxxx

Distributed MonitoringGMDM

GxxxGxxx

Gxxx

GEM AMS objectGMGM

GxxxGxxx

Gxxx

GEM GenericGMGN

GxxxGxxx

Gxxx

GEM GenericGMGX


listener objects are implemented in a set of tables and procedures. Figure 3-7 shows the tables for object class G02H.

Figure 3-7 Tables for CID G02H

Some of the important tables shown in Figure 3-7 are:

G02H_ID This table contains a single number that represents the highest-instance ID number in the class table. Whenever an instance is created for a class, the content of this table must be incremented.

G02Hcname_C The class table that contains the instances of this class.

G02Hcname_S The setting table that contains a single row representing the class-wide attributes. Some examples in this category are icon definition, message tables, and propagation matrix limits.


3.5.2 AMS tablesFor the GEM-based components, several additional tables define important information about the classes and instances. These tables can be categorized as being used for:

� Finding and locating GEM classes and instances

� Placement of object instances

� Automatic creation of Line of Business views

These additional tables are useful for finding and locating these GEM objects:

� GEMLookupCID

This table contains the information about GEM-based classes in IBM Tivoli Business Systems Manager. These classes are named Gxxxx, with a long name of Gxxxxcname. Figure 3-8 shows the content of a GEMLookupCID table.

Figure 3-8 GEMLookupCID


The Manufacturer, Product, and Version columns contain unique information that identifies the component. Tasklib contains the name of the Task Library where a task for this component can be invoked. Comptype indicates the type of GEM component: gem, os390, gen, or dm.

� GEM_IDlookup

This table shows the argument that matches an event attribute with the GEM object and its parent. Figure 3-9 shows a sample content of this table.

Figure 3-9 GEM_IDlookup

Some instances can be located from their TCP/IP host names, the sub-source field, or from their endpoint IDs in the TMR.

� GEM_DMtoCID

This table maps the DM profile to the GEM object class id. When an event from a DM profile is received as indicated in the sub-source slot, it will be applied to the GEM object in the specified class. Figure 3-10 on page 95 shows sample content from the GEM_DMtoCID table.


Figure 3-10 GEM_DMtoCID

The Enterprise outliner view for a GEM object has the following hierarchy:

BUSC - Enterprise - Network Region - Network Location

These tables are used to get the necessary information for placing the GEM object in the Enterprise Outliner.

GEM_EEHostToEnterprise Maps the event enablement host name to the Enterprise object. We map our machine brewster to ITSO enterprise.

GEM_LocationToRegion The Network Region object name is derived from the location. The default derivation is to take the second qualifier of the location name.

GEM_HostnameToLocation The TCP/IP host name is used to obtain the Network Location parameter. The default location is derived from the second and third part of the TCP/IP host name.

For example, IBM Tivoli Business Systems Manager creates the following hierarchy for resources residing in ibmtiv9.itsc.austin.ibm.com:

Enterprise - austin - itsc.austin - ibmtiv9.itsc.austin.ibm.com - resources

3.6 Common listener resourcesThe common listener resources are constructed as a set of tables and stored procedures. When a common listener data source first connects, it registers itself in the CL_Registration table. In our setup, we have IBM Tivoli NetView and IBM Tivoli Monitoring Common listener data sources. Therefore our CL_Registration table is shown in Figure 3-11 on page 96.


Figure 3-11 CL_Registration

The common listener interface can send three types of transactions:

� Bulk data, typically sent on the initial connection to tell the common listener about all available resources from a particular source

� Delta data, sent regularly to update the resource in the common listener source

� Event data, typically sent on change of status or other important notification to IBM Tivoli Business Systems Manager

These transaction are sent in XML format conforming to Simple Object Access Protocol (SOAP). The content is stored temporarily in the common listener staging tables CL_StageBulkData, CL_StageDeltaData, CL_StageEvData.

These operations can affect two types of objects: a resource object or a link definition. An object will be created in the IBM Tivoli Business Systems Manager database based on the enterprise specified in the CL_AutoPlacement table. Our CL_AutoPlacement table is shown in Figure 3-12.

Figure 3-12 Common listener auto placement table


An event’s severity is mapped to the IBM Tivoli Business Systems Manager alert state and priority in the CL_Severities table. TEC and NetView alsohave mappings. Sample content for the CL_Severities table is shown in Figure 3-13.

Figure 3-13 CL_Severities content

3.7 Menu and command This chapter discusses the ability to customize commands for the IBM Tivoli Business Systems Manager workstation. The discussion here is divided into:

� 3.7.1, “Menu, menu item, and launcher” on page 97

� 3.7.2, “z/OS subsystems command support” on page 102

� 3.7.3, “Tivoli task support” on page 108

3.7.1 Menu, menu item, and launcherTo enhance the processing of the IBM Tivoli Business Systems Manager workstation installation, you may want to add custom commands to your workstation. The context menus of each object are constructed from the MenuItem and isa_chain tables. Note that two tables comprise the MenuItem: MenuItem_BASE and MenuItem_LOCAL. The tables with the _LOCAL suffix contains parameters that must be localized for translation purposes.

Figure 3-14 on page 98 shows the default context menu for a DB2InstanceManager object.


Figure 3-14 Default context menu for DB2InstanceManager

The context menu retrieves its menu entries from the MenuItem tables. It shows all menus belonging to its class and all inherited menu from its parent classes. The inheritance hierarchy is recorded in the isa_chain table.

Figure 3-15 on page 99 shows sample context menu processing for a Started Task object.


Figure 3-15 Context menu processing

This illustrates the process that occurs as an object is selected to obtain the context menu:

1 Using its class ID, the application server tries to determine the command classes that match the object from the isa_chain table. The object class is matched with the component ID (cid) column, and the resulting command class is from the base_cid column. All object classes are inherited from their own command class and tree object (TREO) command class.

2 The application server then checks the MenuItem table for all command classes that apply to the object class. It matches the base_cid column in the isa_chain table with the obj_cid column in the MenuItem table.

As shown in Figure 3-15, the applicable fields in the MenuItem table are:

obj_cid Command class. The obj_cid can be a super class of a real object.

obj_id Instance ID. An obj_id of 0 applies the menu to all instances of the object.

Combined, the obj_cid and obj_id identify the object that has this menu object. The BASE is a root for all objects. You can create a menu for a specific object instance.

id Command ID.

control_id Contains the command line, stored procedure, or command text for processing or execution.

c id base_c idS TC S TC

S TC M JO B

S TC TR EO

C IC S C IC S

C IC S M JO B

C IC S TR EO

... ...

isa_cha in

obj_c id ob j_ id id control_id label pa re nt_ id order fla gs

S TC 0 1 cm d.exe C om m an d 3 4.00 .0 0.00 2

TR EO 0 2 http://tivm gr1/as i/ind ex.asp D oc - in dex 6 2 2.10 .0 0.00 2 56

TR EO 0 3 O nVie wH yperV ie w H yp erV iew 9 2 7.10 .0 0.00 10 24

S TC 121 4 sh.e xe Ko rn sh ell 7 0.00 .0 0.00 2

M JO B 0 5 R un Store dP roced ure R un Te st 9 9.00 .0 0.00 40 96

B AS E 0 6 D ocu m entatio n 2 2.00 .0 0.00 8

M enuItem

cid=ST C

1

2


label Shows the text that we see in the context menu.

parent_id Indicates the parent command ID for the submenu.

item_order Indicates the command order that should be shown in the menu. Commands may be stacked to nine levels.

flags Describes the execution behavior of the command.

Flags are binary fields that are shown as a number. The meaning of each bit in the flag fields is:

0x00000001 MI_SEPARATOR; this is a separator entry.

0x00000002 MI_COMMANDLINE; the control_id contains the command line string to be executed in the database server by CMD.EXE.

0x00000004 MI_DIALOGBOX; opens a dialog box (must define the class for Java console).

0x00000008 MI_SUBMENU; indicates that this entry is a staging entry with a submenu attached to it.

0x00000010 MI_BUILTINONITEMSELECT; reserved for menu from IBM Tivoli Business Systems Manager.

0x00000020 MI_BUILTINONMENUCREATE; reserved for menu from IBM Tivoli Business Systems Manager.

0x00000040 MI_DISABLEONSECURITYFAIL; disable this entry when the security flag is not completed.

0x00000080 MI_ELIMINATEOVERRIDE; eliminate this entry when there is an override menu item.

0x00000100 MI_URL; the control_id specifies a URL that will be shown using an Internet Explorer plug-in from the IBM Tivoli Business Systems Manager workstation.

0x00000200 MI_INVOKEMETHODINVIEW; runs method and displays the result in a class for Java console.

0x00000400 MI_ACTIVEXCONTROL; runs an activeX console (not used in the Java console).

0x00000800 MI_HYPERVIEW; invokes the hyperview engine.

0x00001000 MI_INVOKEMETHOD; invokes an internal object’s method as defined in the method table (no graphical display).

0x00002000 MI_DISABLEIFNOTEXIST.

0x00004000 MI_GRAPHVIEW.


0x00008000 MI_MENUBARONLY; this entry is only for the menu bar, not applicable for context menu.

0x00010000 MI_INVOKEMETHODINTEXTVIEW; invokes a method and displays the resulting text.

0x00020000 MI_APPLAUNCH; launches a GUI application in the workstation.

0x10000000 MI_VISIBLESELF; visible for the physical object.

0x20000000 MI_VISIBLEAGGREGATE; visible on an aggregate object.

0x40000000 MI_VISIBLELINK; visible on a linked (business system) object.

A special set of menu commands has been implemented that are called launcher menus. They are defined as a submenu for the Launch context menu. These commands launch a device-specific application and specifically store the command line that is used in the client in the RDM_LAUNCHER table. This table contains platform-specific commands for each application.

The commands related to menu and launcher are:

� AddAppLauncherEntry.sh with arguments:

-n Entry name-l Platform-c Connection type-m -x Port numbers-w Timeout in seconds-r Revision number-g Command line string-a Command line argument

� AddAppLauncherMenuItem.sh with arguments:

-n Entry name-c Class ID of the object-l Menu text-r Control ID for the menu item-a Installs menu items for all installed languages-f Specifies an input file containing new entries-m Name of the menu item (optional)

� DeleteAppLauncherMenuItem.sh with arguments:

-n Entry name-r revision number


� DeleteAppLauncherMenuEntry.sh with arguments:

-n Entry name-c Class ID-m Name of menu item-r Remove parent menu if empty

3.7.2 z/OS subsystems command supportCommand support has been predefined for most of the z/OS subsystems, such as DB2, CICS, or IMS. These commands are send to z/OS through Tivoli NetView for z/OS with a NETCONV session. Command are invoked using the program tgmtask from the database server.

As an example, we show the implementation on a single Started Task object with the MVS Display Active command. The steps are:

1. Define a program to invoke the MVS D A,<stcname> command in NetView. This must be done because the console reply is asynchronous.

2. Define a stored procedure to invoke the tgmtask command that sends the command to NetView.

3. Define the stored procedure as a method for the Started Task object.

4. Define the menuitem to invoke the method for a StartedTask object.

NetView commandThe NetView command is called MVSDACMD, and its content is shown in Example 3-3.

Example 3-3 MVSDACMD

/*REXX*/arg stcname . 'PIPE NETV MVS D A,'||stcname '| CORRWAIT | COLLECT | CONSOLE'exit

All console commands must be correlated and collected into a single multi-line message and shown in the console.

Stored procedureWe call the stored procedure _MVSDA. Note the underscore: All stored procedures that are used as a method for an IBM Tivoli Business Systems Manager object start with an underscore. The method nameis MVSDA (without the underscore).


Example 3-4 shows the content of the SQL command to create the stored procedure.

Example 3-4 MVSDA.sql content

CREATE PROCEDURE _MVSDA @cid ClassID, @id ObjID, @ReturnCode INT = NULL OUTPUTAS RAISERROR('_MVSDA: %s, %d', 0, 1, @cid, @id) DECLARE @command NVARCHAR(255) DECLARE @OSID ObjID DECLARE @stcname NVARCHAR(8)

IF @cid = 'LOB' SELECT @cid = phy_cid, @id = phy_id FROM lob_link WHERE dst_id = @id

SELECT @stcname = name FROM STC_V where id = @id SELECT @OSID = src_id FROM link WHERE link_type = 'PHYC' AND src_cid = 'OS' AND dst_cid = 'STC' AND dst_id = @id AND deleted = 0 IF @OSID is NULL BEGIN SELECT '_MVSDA ERROR: Cound not locate OS' RETURN 8 END SELECT @command = 'MVSDA ' +@stcname

EXEC @ReturnCode = asisp_tgmtask390 'OS', @OSID, @command

RETURN @ReturnCodeGO

The stored procedure works as follows:

1. The first two arguments must be the Object CID and ID of the method invoker. The last argument must be the return code for the caller.

2. Declare the necessary variables.

3. If this is a business systems object, try to find the original object that invoked the method.

4. Obtain the name of the started task that invoked the method.

5. Find the Operating System object to which the started task belongs.


6. Construct the command string and pass it to the asisp_tgmtask390 procedure to invoke it.

Method definitionThe method can be defined using SQL commands. We use an SQI file that can generate the necessary command as shown in Example 3-5.

Example 3-5 Defining MVSDA method: defineMVSDA.sqi

include(BusinessObject.sqi)

BEGIN_METHOD(MVSDA, 'Send MVS D A command','Display Active Task') METHOD_PARAM(ReturnCode, ASIVARIANT, 'RETURN Code', 'RETURN Code') METHOD_PARAM_FLAG(output) METHOD_PARAM(Results, ASIDBTABLE, 'Results', 'Results') METHOD_PARAM_FLAG(output) METHOD_PARAM_FLAG(collection)END_METHOD(MVSDA)

BEGIN_METHOD_CALLERS(MVSDA) METHOD_CALLER(STC)END_METHOD_CALLERS(MVSDA)

To translate the file into an executable SQL statement, use the command sh clsql defineMVSDA.sqi. This will generate the file defineMVSDA.sql that you can run through the SQL Query Analyzer.

Menu item definitionNow define the menu item by putting the menu in the main context menu and setting the flags MI_VISIBLESELF, MI_VISIBLELINK and MI_INVOKEMETHODINTEXTVIEW. Therefore the flag is x’50010000’ or 1342242816.


We use the stored procedure asisp_definemenuitem to do this, and run the query through the SQL Query Analyzer, as shown in Figure 3-16. Note that we apply the menu to a specific object with obj_id of 6. If you want to apply the menu to all objects in that class set obj_id to 0.

Figure 3-16 Running the asisp_definemenuitem


Sample resultWe implement the command to the GTMPUMP9 started task as shown in Figure 3-17.

Figure 3-17 Invoke MVS D A


The task parameter window is displayed. As we do not have any parameters, we just click Start as shown in Figure 3-18.

Figure 3-18 Task setting window

A further prompt asks for the userID and password used to access Tivoli NetView for z/OS, as shown in Figure 3-19.

Figure 3-19 Tivoli NetView for z/OS prompt


The result is presented in the Task Monitor window as shown in Figure 3-20.

Figure 3-20 Task Monitor result window

3.7.3 Tivoli task supportThe Tivoli Framework tasks can be invoked using the tgmtask command:

tgmtask -h eehost -u tmeid -k tmepw {-o tmeendpointoid|-r endpointhostname} tskname|tsklib|tskargs

where

eehost The event enablement or task server hostname

tmeendpointoid Object id of the endpoint, in the format of <tmr num>.<dispatcher num>.0+

endpointhostname Endpoint’s label

tmeid, tmepw User ID and password to access the TMR

task information Task name, task library name, and task arguments


With this capability, we can extend the menu for any distributed objects that we can identify as belonging to a Tivoli Management Region where a task server is defined. For simplicity, we define additional commands for resources that are defined from TEC, where an Event Enablement host is one of the attributes.

We pick up a generic object that is defined as cid of G02K and add an extension to perform a DIR command on a Windows platform or a df command on a UNIX platform.

The tasks are similar, except that we create a Tivoli Framework task called DIRCDrv under TBSMTasks Task Library. The script that the task runs is shown in Example 3-6.

Example 3-6 Shell script for DIRCDrv task

#!/bin/shif [ x\"$OS\" = x\"Windows_NT\" ] ; then

CMD.EXE /C DIR C:else

dffiexit 0

We then define a stored procedure called _DIRCDrv as shown in Example 3-7.

Example 3-7 _DIRCDrv Stored Procedure

CREATE PROCEDURE _DIRCDrv @cid ClassID, @id ObjID, @ReturnCode INT = NULL OUTPUTAS RAISERROR(‘_DIRCDrv: %s, %d’, 0, 1, @cid, @id) DECLARE @command NVARCHAR(255) DECLARE @userID NVARCHAR(255) DECLARE @tmeid NVARCHAR(255) DECLARE @epname NVARCHAR(255)

IF @cid = ‘LOB’ SELECT @cid = phy_cid, @id = phy_id FROM lob_link WHERE dst_id = @id

SELECT @tmeid = _EEhost, @epname = _MgedSystemName FROM G02Kcname_V where id = @id EXEC asisp_getContextUserID @userID OUTPUT

IF @tmeid is NULL BEGIN SELECT ‘_DIRCDrv ERROR: Cound not locate EE host’ RETURN 8


END SELECT @command = ‘tgmtask -d TME -h “‘ + @tmeid + ‘” -r “‘ + @epname + ‘” ‘ IF @userID IS NOT NULL SET @command = @command + ‘ -u “‘ + @userID + ‘” -k “********” ‘ SET @command = @command+’ “DIRCDrv|TBSMTasks|’

EXEC @ReturnCode = master..xp_cmdshell @command

RETURN @ReturnCode

GO

We then use DefineDIRCDrv.sqi file to define the method for G02K as shown in Example 3-8.

Example 3-8 DefineDIRCDrv.sqi


BEGIN_METHOD(DIRCDrv, ‘Dir of C drive’,’Display C Drive’) METHOD_PARAM(ReturnCode, ASIVARIANT, ‘RETURN Code’, ‘RETURN Code’) METHOD_PARAM_FLAG(output) METHOD_PARAM(Results, ASIDBTABLE, ‘Results’, ‘Results’) METHOD_PARAM_FLAG(output) METHOD_PARAM_FLAG(collection)END_METHOD(DIRCDrv)

BEGIN_METHOD_CALLERS(DIRCDrv) METHOD_CALLER(G02K)END_METHOD_CALLERS(DIRCDrv)

We run the command sh clsql DefineDIRCDrv.sqi and invoke SQL Query Analyzer to load the generated DefineDIRCDrv.sql.

Then we run asisp_definemenuitem against the G02K object. This time we apply to all instances using the command:

EXEC asisp_definemenuitem 'DIRCDrv', 'G02K', 0, 'DIR C Drive', NULL, NULL, 'DIRCDrv', NULL, '', 1342242816


The resulting menu item is shown in Figure 3-21.

Figure 3-21 Context menu for DIRCDrv


The output in the Task Monitor is shown in Figure 3-22.

Figure 3-22 Execution result for DIRCDrv


Chapter 4. User interface

The purpose of this chapter is to give an overview of the user interfaces to the IBM Tivoli Business Systems Manager. It is not the intended to provide an exhaustive explanation of the interface nor to replace the User Guide. For more information about using IBM Tivoli Business Systems Manager, refer to IBM Tivoli Business Systems Manager: User’s Guide, GC32-0798.

IBM Tivoli Business Systems Manager has two user interfaces: the Java console and the Web console. These are discussed in:

� 4.1, “Java console” on page 114

� 4.2, “Web console” on page 119

4


4.1 Java consoleThe Java console is the primary interface for most operators that use IBM Tivoli Business Systems Manager. The conceptual connectivity of the Java console is shown in Figure 4-1.

Figure 4-1 Java console structure

All Java consoles communicate with the Console Server, where the authentication is performed. The Console Server is the one that actually accesses the database.

The Java console is launched from the IBM Tivoli Business Systems Manager icon shown in Figure 4-2.

Figure 4-2 IBM Tivoli Business Systems Manager icon

When it launches, it prompts you for a user ID, password, and the host name of the Console Server, as shown in Figure 4-3 on page 115. The user ID will be authenticated to the Windows user account of the Console Server. The user also must be a member of IBM Tivoli Business Systems Manager administrative groups, which determine the user’s authority within the console.

Console Server

Database Server

Java Console

Java Console

Java Console


Figure 4-3 IBM Tivoli Business Systems Manager sign-on dialog

The initial display for the IBM Tivoli Business Systems Manager Java console is shown in Figure 4-4.

Figure 4-4 Welcome screen for IBM Tivoli Business Systems Manager

Chapter 4. User interface 115

The left side of the welcome screen shows the list of Business Systems that a user is authorized to see. Depending on the user’s authority, more or fewer items may be listed.

The primary menu is the Console menu. The menu shown in Figure 4-5 is for a Super Administrator, which has all authority. Some menu items may not appear for other types of administrators.

Figure 4-5 Primary Menu for Super Administrator

Workspaces are discussed in Chapter 13, “Setting up roles and security,” on page 421. This relates to a pre-customized display that you can store across logon sessions. You can keep the setting of the open windows and its status in the workspaces.

Special windows that can be displayed from this menu:

Task monitor Shows tasks that have been executed and the latest results.

Resource type window Shows the various IBM Tivoli Business Systems Manager resource types (object classes). You can modify some of their settings.

All Resources Shows the physical object hierarchy that IBM Tivoli Business Systems Manager is managing.

Preferences Used for setting various console properties.

Administrator preferences Shows the main settings for this console session.

Figure 4-6 on page 117 shows a sample console with both the Business Systems and All Resources views partially expanded.


Figure 4-6 Expanded console

Here you can see various managed resources and their status. Any abnormal status is indicated using a color-coded sign over the icon. You can view each object’s properties by right-clicking the object and selecting Properties. A sample property display for a DB2InstanceManager is shown in Figure 4-7 on page 118.


Figure 4-7 Property page of a DB2InstanceManager object

In the property display you can see the events and exceptions that relate to this object, as well as its attributes and other useful information.

A lesser-known feature of the Java console is its ability to go into debug mode, which provides additional information for objects and their attributes. Invoke debug mode using the key combination Ctrl+Shift+F12. In debug mode, the expanded desktop in Figure 4-6 on page 117 looks like Figure 4-8 on page 119.


Figure 4-8 Expanded console in debug mode

For more information about using the Java console, refer to IBM Tivoli Business Systems Manager: User’s Guide, GC32-0798.

4.2 Web consoleThe Web console is an implementation of the Tivoli Presentation Services for IBM Tivoli Business Systems Manager console. It sets itself as an intermediary between the Console Server and Web browser.

In a Windows environment, the Web console installs itself into four services:

� Tivoli Presentation Services HTTP Server

� Tivoli Presentation Services HTTP Administration


� Web Services for IBM Console, a Java application server for the IBM console

� Server for IBM Console, the server that processes the IBM Console

The primary objective of the IBM Tivoli Business Systems Manager Web console is to provide various Level 1/Level 2 operator views to examine the status of resources and accomplish basic troubleshooting. Usage typically takes place in short, sporadic sessions (for example, a traveling user checking the status of a critical system).

The Web console server uses Presentation Services as its interface architecture, and it differs in both appearance and behavior from the regular console. An appropriate Web browser is needed to use the Web console because it runs in kiosk mode so none of the browser’s controls, such as the menu bar and tool bar, are visible.

Using the Web console, operators can perform the same basic monitoring and problem determination tasks as with the regular console, and Administrators can perform additional tasks such as creating shared filters. The following information summarizes actions Web console users can perform:

� Manage Business Systems

– View Business Systems

– View Home Page

� Manage Events

– Create event filters

– Run event filters

� Manage Resources

– Create resource filters

– Run resource filters

– View critical resources

– View critical resources

There are differences between the IBM Tivoli Business Systems Manager console and the Web console. For example:

� The Business Impact view is shown in HyperView in the regular console, while it is a Tree view in the Web console.

� Filters work differently in the Web console.

� The Web console uses the Home page concept.


The Web console typically connects to port 8001 on the Web console Server; in our example it is 3C041. The initial page is reached by connecting to:

http://3C041:8001/IBMConsole

The resulting logon page is shown in Figure 4-9.

Figure 4-9 Sign on to the IBM Console

The initial user ID is called superadmin and its initial password is the word password. When you sign on, it launches a new browser window for the session. The welcome screen in shown in Figure 4-10 on page 122.


Figure 4-10 Welcome screen of the Web console

The left side of the console, under My Work, lists the tasks that can be performed by a specific administrator.


The superadmin’s list is shown in Figure 4-11.

Figure 4-11 Primary options


A user can be created using the Create User and Manage Users menu. An example of its properties is shown in Figure 4-12.

Figure 4-12 User profile


Available roles that can be associated with each user are shown on the Roles tab, as in Figure 4-13.

Figure 4-13 User roles


To start access to IBM Tivoli Business Systems Manager, the Signon interface prompts you for a user ID for the IBM Tivoli Business Systems Manager Console Server as shown in Figure 4-14.

Figure 4-14 TBSM Sign On screen


A sample of the Business System View is shown in Figure 4-15.

Figure 4-15 Business System View


And the All Resources View is shown in Figure 4-16.

Figure 4-16 All Resources View

For more information about using the Web console, refer to IBM Tivoli Business Systems Manager: User’s Guide, GC32-0798.


Chapter 5. Implementation planning

This chapter discusses some planning tasks and information that are needed to ensure a succesful implementation of IBM Tivoli Business Systems Manager. The topics are:

� 5.1, “Planning overview” on page 130 discusses general planning considerations

� 5.2, “Personnel” on page 130 discusses who should be involved in the implementation and considers who will use the solution later

� 5.3, “Hardware specifications” on page 132 explains some considerations that affect the specifications for the hardware that will be provided

� 5.4, “Network and connectivity” on page 133 shows some network connectivity requirements for IBM Tivoli Business Systems Manager

� 5.5, “Software level and prerequisites” on page 134 lists the prerequisite software that is needed by IBM Tivoli Business Systems Manager

� 5.6, “Operators and users” on page 138 describes the necessary considerations for setting up operators and users

� 5.7, “Business System requirements” on page 139 discusses how to design a business system, including comparison of the available approaches.

5


5.1 Planning overviewAlmost all businesses today run on computer systems or intelligent devices that are complex and varied. They need to be maintained and monitored properly to ensure optimum performance levels and to minimize prolonged downtime of system components. This helps maintain an edge over the competition in the increasingly competitive marketplace.

IBM Tivoli Business Systems Manager provides just such a solution with end-to-end monitoring of the individual components that make up these systems. Component status is presented using views designed with the enterprise’s requirements and operation needs in mind. With these views, collectively referred to as Business System Views (BSVs), the enterprise can be alerted quickly to faults in its systems, prompting early corrective actions to be taken to avoid potential disaster.

This section discusses the planning and preparation necessary for successful deployment of IBM Tivoli Business Systems Manager. The environment can be a distributed system, a mainframe system, or the complete enterprise with both distributed and mainframe systems. We also discuss how to plan and prepare the implementation of the BSVs.

The following areas must be prepared:

� Personnel

� Hardware specifications

� Network and connectivity

� Data feeds

� Software levels and prerequisites

� Operators and users

� Business system requirements

We will discuss each area in the following sections.

5.2 PersonnelThe implementation of IBM Tivoli Business Systems Manager is a complex task in terms of both implementation time and personnel, requiring close interaction between the implementation team and administrators.

Everyone involved in implementing the system should read IBM Tivoli Business Systems Manager: Installation and Configuration Guide, GC32-0800.


Additionally, the IBM Tivoli Business Systems Manager: Administrator’s Guide, GC32-0799 is required reading for both implementers and the system’s administrators.

Implementation involves various roles:

� Implementation team: Consists of core IT personnel from the enterprise whose combine their expertise with the information in the IBM Tivoli Business Systems Manager: Administrator’s Guide, GC32-0799 and IBM Tivoli Business Systems Manager: Installation and Configuration Guide, GC32-0800. They will interface with the services implementation team. Typical implementation team members are:

– Mainframe system programmer

– Network system programmer

– Database (IMS/DB2) system programmer

– Database (IMS/DB2) administrator

– CICS system programmer

– Job scheduler

– Tivoli Framework administrator

– Network/LAN administrator

– Windows system administrator

� Input providers: Provide input about how to customize and implement various IBM Tivoli Business Systems Manager functions. The implementation team may consult them as potential IBM Tivoli Business Systems Manager operators, but they do not perform software customization. They may be asked to attend operator sessions. An input provider may be a:

– System operator

– Helpdesk representative

– Business function manager

– Executive assistant

– User representative

– Application designer

– System analyst

– IT manager

– Problem and change coordinator

� Administrators: Maintain IBM Tivoli Business Systems Manager systems on day-to-day basis. They must read and understand the IBM Tivoli Business

Chapter 5. Implementation planning 131

Systems Manager: Administrator’s Guide, GC32-0799. They need advanced knowledge about how IBM Tivoli Business Systems Manager works and what is required for maintaining it. Depending on the implementation scope, administrators may have experience as a mainframe system programmer, Tivoli administrator, or Windows/LAN administrator. The administrator team’s skill base should include at least these three backgrounds.

5.3 Hardware specificationsCapacity and specifications for the IBM Tivoli Business Systems Manager’s servers must be decided before implementation can begin. This requires careful estimation and planning for the server’s expected workload.

The implementation team should consider:

� Implementation type: enterprise (mainframe and distributed) or only distributed

� Number of events

� Number of objects to be managed

� Number of operators

� Number of Business System Views

� Activation of certain functions

When planning for the number of machines that your system will require, include the following considerations:

� Database server: This has to be the machine with fastest processors and most memory.

� Propagation server and console server: For a mainframe and distributed environment, separate machines are recommended for the two servers. In a distributed-only environment, they can be combined on the same machine.

� Event server and SNA server: These two machines are recommended for SNA connectivity to the mainframe, while for IP connectivity to the mainframe, you can have only an event server, or you can split the event server’s receiving and sending functions between two servers.

� History server: This is recommended in the enterprise environment, while it is optional for the distributed environment.

� Testing and quality assurance servers: These servers are needed for testing instrumentation and feeds for new resources before they are released for production. For a standard enterprise environment, this can be implemented over three servers.


� Failover capability: The capability to switch back and forth between two sets of production machines requires you to double the number of operational servers (excluding the testing and quality assurance servers).

� Health Monitor Server (HMS): Although it would not consume a large amount of system resources, implementing the HMS on the same systems that run the services and processes it monitors is not recommended. Therefore, HMS should be installed on the history server so it has no direct impact on normal IBM Tivoli Business Systems Manager processing.

For more discussion about the number of servers and their specifications, read the IBM Tivoli Business Systems Manager: Installation and Configuration Guide, GC32-0800.

5.4 Network and connectivityAs IBM Tivoli Business Systems Manager collects information feeds from multiple system management platforms and its workload is distributed on different servers across the enterprise, well-implemented network and connectivity are essential. Be sure to establish a formal arrangement for networking support with your Network Support group before beginning implementation.

Networking infrastructure and connectivity considerations include:

� Local area network (LAN) type: Is this an Ethernet or token ring infrastructure or both? A full-duplex fast Ethernet card is recommended, with a suitable hub or switch to be used exclusively by the IBM Tivoli Business Systems Manager servers. This enables faster communication between IBM Tivoli Business Systems Manager servers.

� IBM Tivoli Business Systems Manager uses TCP/IP network connectivity. Each IBM Tivoli Business Systems Manager server must have a static IP address.

� Will the IBM Tivoli Business Systems Manager environment to be in its own network domain or part of a shared one?

� Is the other set of failover servers, if applicable, in another domain?

� Is there any firewall and/or router, with or without DNS?

Another connectivity issue concerns IBM Tivoli Business Systems Manager’s use of Windows networking. This requires a proper setup of Windows security, such as Active Directory. Applicable user accounts should be set up with appropriate access authority prior to this implementation.


5.5 Software level and prerequisitesIBM Tivoli Business Systems Manager collects information from multiple subsystems. This is called an information feed, and it is based on specific levels of software. You must collect the various data feeds and their software levels to ensure easier integration into IBM Tivoli Business Systems Manager and identify discrepancies early.

This section discusses software prerequisites for distributed and mainframe systems.

5.5.1 Planning for distributed systemsComplete understanding of an enterprise's distributed systems is required to integrate IBM Tivoli Business Systems Manager into the distributed system environment.

IBM Tivoli Business Systems Manager supports two basic interfaces for collecting distributed event data:

� An integrated interface with Tivoli Enterprise Console (TEC) using the event enablement service. Data sources that route events through TEC include:

– Application Policy Management (APM) instrumentation for heartbeat and threshold events

– Generic events initiated from rule engine ihstttec

– Tivoli Manager for products

– IBM Tivoli Monitoring modules

� Common listener service. Data sources that route events through the common listener service include:

– IBM Tivoli Monitoring (ITM)

– IBM Tivoli NetView

– Tivoli Workload Scheduler v8.1

– PATROL

– CA-Unicenter TNG

For IBM Tivoli Business Systems Manager to recognize distributed resources, they must be mapped to defined resource types within IBM Tivoli Business Systems Manager.


The tables and checklists in this section serve as a guide to preparing for deployment of IBM Tivoli Business Systems Manager for a distributed system environment.

Tivoli software inventoryFrom the Tivoli Framework, you can issue wlsinst command to check the prerequisites for your Tivoli software level.

ITM profile informationTo collect information about either your Tivoli Distributed Monitoring or IBM Tivoli Monitoring profiles and their monitoring contents, use the wlookup command to obtain the profile name:

wlookup -ar SentryProfile wlookup -ar Tmw2kProfile

With the profile name, you can collect the profile’s contents.

TEC classes and rulesYou must list all BAROC classes and rules to:

� Identify which class you want to monitor

� Decide on is the monitoring mechanism

� Match creation and clearing of event

NetView network structureYou must obtain the primary maps and sub-areas that NetView monitors.

5.5.2 Planning for mainframe systemsThe tables and checklists in this section will serve as a guide to prepare for a deployment of IBM Tivoli Business Systems Manager for mainframe environment.

The required information is presented in the following checklists:

� “Mainframe and Logical Partition (LPAR) information” on page 136

� “Subsystem information and naming convention” on page 137

� “Subsystems checklist” on page 137


Mainframe and Logical Partition (LPAR) informationThis information regarding the number and type of physical mainframes and the LPARs defined on these machines usually can be obtained from the mainframe System Support team. A sample is shown in Table 5-1.

Table 5-1 List of mainframe information

Operating System id (SMF id)

SC66 MVS1

Complex ITSO Boulder

Machine SC66Machine RETAIN-Test

LPAR SC66 PRIMARY

Operating System Version and description

z/OS v1.1Lab Test system 66

OS/390 v2.10SysProg Test system

IP address 9.12.14.22 9.99.64.54

SNA information:• VTAM CP• Source/390 majornode• IBM Tivoli Business

Systems Manager SNA server LU majornode

Not applicable Not applicable

SYSPLEX WTSCPLX1 Not applicable

CICSPLEX SC66PLX Not applicable

Job Entry Subsystem JES2 JES2

Network management NetView for z/OS NetView for OS/390

System Automation Not applicable SA/390 2.1

Job Scheduler TWS 8.1 Not applicable

MVS perfomance monitor RMF RMF

Database subsystem Not applicable DB2 and IMS

Transaction Program subsystem

CICS Not applicable

Subsystem performance monitors

CICSPlexSM Not applicable

Security RACF® RACF


Subsystem information and naming conventionIf the traditional bulk discovery process is to be employed, a solid naming convention for your system will make this process simpler to find and categorize your enterprise resources.

Table 5-2 Subsystem naming convention

Subsystems checklistMany of the MVS subsystems consist of further components, which are shown in the following tables.

IMSTable 5-3 lists the IMS subsystems checklists for IBM Tivoli Business Systems Manager implementation.

Table 5-3 IMS subsystems checklist

DB2Table 5-4 lists the DB2 subsystems for discovery.

Table 5-4 DB2 subsystems checklist

Resource Name pattern

DB2 DB%

IMS IMS??%

CICS ?CICS??

Monitor OMEG%

STC %

Subsystem Version OTMA OS

IMS1A 7.1 Yes MVS1

IMS2A 7.1 Yes MVS1

Subsystem Version Performance monitor

Data sharing OS Discovery

DB2A 6.1 DB2PM No MVS1 Yes

DSN1 6.1 No No MVS1 No




CICSTable 5-5 on page 138 lists the CICS subsystems and their corresponding components.

Table 5-5 CICS subsystems checklist

5.6 Operators and usersYou should identify early on who will use the IBM Tivoli Business Systems Manager. Console users must be identified early, as this will influence:

� Console server size

� Deployment requirements

� Business System View design

� Workspace creation

You should map the following:

� Authority group: For each user, create a user ID in the console server machine and associate it to the appropriate IBM Tivoli Business Systems Manager group

� Monitoring requirement: Each user in each function will need to monitor different areas, and this must be fulfilled within the appropriate structure of Business System View and workspace. Some examples are:

– Helpdesk needs to see overall system health

– Operators needs to monitor the IT system they are responsible for

– Business function managers need to see their business system

– IT managers need to see the IT equipment

– Network administrator only need to see the status of network devices



Subsystem Version Performance monitor

Data sharing OS Discovery

Subsystem Version CICSPlex Performance monitor

OS

SC66C 7.1 SC66PLX CICSPlexSM SC66

PCICS01 7.1 Not applicable Not applicable MVS1


� Action requirement: Some operators may need a special ability to issue an action to an object, so consider addressing this in the implementation.

5.7 Business System requirementsIBM Tivoli Business Systems Manager offers two types of views: All Resources View and Business System View. The All Resources View, sometimes called the physical view, represents the actual enterprise structure. Business System Views (BSVs) are created with managed objects from the physical view. Business System objects are additional representations of the physical objects that exist within the enterprise; specifically, a link to the actual object that resides within the All Resources View. Each link contains a set of filters and controls, so data coming into the Business System object is the only data that is important to the BSV's author. Operations performed on the physical object affect the object in the created BSVs. You create Business System objects by dragging a physical object from the physical view, or another Business System object from another BSV, into the destination BSV.

5.7.1 Business System View theoryIBM Tivoli Business Systems Manager has the capability to create logical aggregations of all the physical objects discovered within the enterprise. In order to represent critical business processes or services, the objects contained in the All Resources View can be extrapolated from their original tree and inserted into different hierarchical structures. Such new structures (Business System Views) enable you to diversify enterprise monitoring according to different IBM Tivoli Business Systems Manager operators’ business interests and needs.

5.7.2 Business System View design conceptDesigning a BSV’s structure involves understanding and accounting for the complex relationships between the objects involved and the myriad ways to represent them. This section provides our recommendations for designing correct BSVs:

� Create BSVs based on the need and required monitoring function of an operator or a group of operators. BSVs should provide critical business information about the collection of resources or applications the operators are responsible for managing.

� Create BSVs covering multiple business interests as root BSVs directly in the Business System folder so that they can be reused and incorporated in other BSVs. Dragging and dropping a child BSV into another one results in


propagation errors because the child event from the original BSV does not propagate in the dragged BSV.

� Drag objects to BSVs directly from the original objects in the All Resources View to avoid having objects in the DELETED state when the original object is deleted.

� Propagation of a child event does not happen to a leaf node (an object dragged into a BSV that has children in its physical view, such as a DB2 subsytem), so when the physical object turns red because of a child event, its corresponding leaf node does not change. Indeed, the leaf node mantains a link with its children. Opening certain IBM Tivoli Business Systems Manager views (Managed Resources view, Event Viewer) on the leaf node in the BSV enables you to see all the object children as if you had dragged them all. However, dragging another object under the leaf node (for example a DB2 database under a DB2 subsystem) breaks the existing link between the leaf node and its children.

� Some objects, such as the network interface, can represent the status of the original hosts. When a networked application cannot connect to the machine, the machine is practically useless. Therefore any component of an application in a machine will have the network interface as a critical dependent.

� The BSV Properties view must be adjusted to match the required priority and the threshold of the child event.

� Setting the individual priority of each object in the BSV must be evaluated and matched with the BSV’s child event threshold.

5.7.3 Business System View structureBSVs can contain resources directly or affect the BSV. Several methods can be used to implement these configurations, so we will give an example to illustrate the difference between the two approaches.

The WorldBank Remote Banking application depends on two Web servers, castore and polluce, running the RemoteAccess service. The core of the RemoteAccess application is the APPL CICS transaction that accesses the database HYPERDB under the DB2 Subsystem to grant user remote access.

Remote Banking’s BSV consists of:

� Remote Access service on castore� Remote Access service on polluce� HYPERDB DB2 database� APPL CICS transaction


The BSV also indirectly depends on other resources, such as:

� Network Interface NetCom for castore and polluce, to ensure that the Web servers are online

� MVS1 operating system

� JRLM DB2 subsystem

The BSV can be implemented variously as:

� No hierarchy: Using this method, all resources that the BSV depends on are laid out flat under the BSV object. Figure 5-1 shows the conceptual BSV structure.

Figure 5-1 Flat BSV for Remote Banking


� Original hierarchy: Using this method, all resources are laid out under the BSV according to its physical tree hierarchy. The objects that affect the BSV directly are listed as the leaf node of the BSV tree. Figure 5-2 shows the conceptual BSV structure.

Figure 5-2 Hierarchical BSV for Remote Banking


� Inverted hierarchy: Using this method, all resources on which a BSV depends are listed as the first-level BSV, and each resource that indirectly affects the BSV is placed under the resource it affects. This method provides the best cause/effect relationship of the objects. Figure 5-3 shows the conceptual BSV structure.

Figure 5-3 Inverted hierarchy BSV for Remote Banking


� Grouped resources: Using this method, all resources that a BSV depends on are made a first-level dependant of the BSV. Other resourceson which the BSV is not directly dependent are grouped in one or more sub-BSVs. Figure 5-4 shows the conceptual BSV structure.

Figure 5-4 Grouped resource BSV for Remote Banking


Table 5-6 shows the pros and cons of each method. The following criteria were evaluated:

� Logical cause/effect relationship of the object: Does the causal relationship of the objects in the view generate the correct propagation behavior? For example, if the host cannot be pinged, then it causes the server application to be unavailable.

� Ease of identifying a problem: Determine whether a problem is directly caused by the BSV component or by something else the component is dependent on. This can be seen from a tree view or a hyperview.

� Ease of maintenance: As with automatic placement of an object under the BSV view, automatic instance filtering can only be implemented for objects under BSV folder objects, not a BSV logical object from a physical object.

� Effect on the business impact view: We called this a fan effect because the business impact view looks like a fan with a lot of parents for an object, thus we cannot really perform a business impact analysis.

Based on Table 5-6, we decided to use the separate BSV design for implementing our BSV.

Table 5-6 Pro and cons of BSVs creation

Type Cause effect Identification Maintenance Business impact

No hierarchy No No Automated Not affected

Original hierarchy

Some Yes No Not affected

Inverted hierarchy

Yes Yes No Great impact

Separate BSV Some Yes Automated Not affected


Part 2 Distributed implementation

In this part we discuss the implementation of IBM Tivoli Business Systems Manager in the distributed environment. The chapters are:

� Chapter 6, “Base services implementation” on page 149 describes how to install the main servers for IBM Tivoli Business Systems Manager

� Chapter 7, “TEC components integration” on page 209 describes the integration of Tivoli Enterprise Console to IBM Tivoli Business Systems Manager

� Chapter 8, “IBM Tivoli Monitoring integration” on page 249 describes the integration of IBM Tivoli Monitoring to IBM Tivoli Business Systems Manager

� Chapter 9, “IBM Tivoli NetView integration” on page 279 describes the integration of IBM Tivoli NetView to IBM Tivoli Business Systems Manager

Part 2


Chapter 6. Base services implementation

This chapter provides an overview of the implementation process for IBM Tivoli Business Systems Manager. This includes our experiences while installing and customizing these base services, as well as any hints and tips that may be useful for a smooth implementation. This chapter includes:

� 6.1, “Hardware and software prerequisites” on page 150 describes the prerequisites required for IBM Tivoli Business Systems Manager

� 6.2, “Prerequisite software components installation” on page 154 discusses the important and necessary installation steps of these prerequisites for a smooth installation of IBM Tivoli Business Systems Manager base services

� 6.3, “Database server installation” on page 176 describes the steps you will need to implement the database server

� 6.4, “Console and propagation server installation” on page 190 outlines the steps for installing the console and propagation server

� 6.5, “History server installation” on page 194 discusses this optional history server installation where the reporting system resides

� 6.6, “Health Monitor Server implementation” on page 199 describes the necessary steps to set up health monitoring

6


6.1 Hardware and software prerequisitesThis chapter describes the required hardware configuration and prerequisite software components for the implementation of IBM Tivoli Business Systems Manager.

We have noted the hardware and software environment used to support the examples in this book as one possible operational configuration.

6.1.1 Hardware configurationBasic IBM Tivoli Business Systems Manager implementation requires only two Intel or compatible computers running Microsoft Windows Server operating systems, also referred to as wintel servers. This two-server configuration is adequate for most production environments although a three-server configuration also can be used. It is always advisable to consult your local IBM representatives for the optimal configuration.

The two-server basic configuration consists of a server for the SQL database and another for console and propagation. For the three-server basic configuration, the console and propagation services run on separate servers.

In additional to the basic configuration, and if it is required, the IBM Tivoli Business Systems Manager Reporting System would run on the history server.

If Web console service is needed, it should run on its own wintel server. This is highly recommended because of its demand on the usage of CPU and memory resources.

Although a Health Monitor System (HMS) is optional, it is advisable to have this feature enabled and customized to allow the monitoring of IBM Tivoli Business Systems Manager services. HMS is not very resource-consuming, so it is can share a machine with the history server. However, it is not recommended to put it on other IBM Tivoli Business Systems Manager servers.

The total number of servers from this combination makes up the total number of production system servers.

The other server considerations, besides the production servers, will be the failover and test and quality assurance (test/QA) servers:

� The Failover System set should be a duplicate of the Production System set.

� Test and QA should be run from two wintel servers. These two servers should at least match the configuration from the two-server Production System set.


Table 6-1 lists the required hardware specifications that provide the appropriate processing environment to perform the necessary processing or functionality in support of IBM Tivoli Business Systems Manager. For the latest complete information, refer to IBM Tivoli Business Systems Manager: Release Notes, GI11-0886.

Table 6-1 Required hardware configuration for TBSM

System CPU Memory System drive Data drive

SQL Database Server

Dual 700MHz 1-MB Cache Pentium III Xeon CPU on a Quad Processor–capable system

4 GB RAM

MS Windows 2000 or NT 4 Server OS. TBSM Database base services. Should have about 2 GB of free space.

SQL Database software and database. Should have at least 72 GB of free space.

Console or Propagation server

Single 866MHz Pentium III CPU on a Dual Processor–capable system

1 GB RAM

MS Windows 2000 or NT 4 Server OS. TBSM Console, Propagation or Common Listener base services. Should have about 2 GB of free space.

Should have at least 4 GB of free space.

History server

Dual 700MHz 1-MB Cache Pentium III Xeon CPU on a Quad Processor–capable system

4 GB RAM

MS Windows 2000 or NT 4 Server OS. TBSM Reporting System base services. Should have about 2 GB of free space.

SQL Database software and database. Should have at least 108 GB of free space.

Web console server

Single 866MHz Pentium III CPU on a Dual Processor–capable system

1GB RAM

MS Windows 2000 or NT 4 Server operating system. TBSM Web console base services. Should have about 2 GB of free space.

Should have at least 4 GB of free space.

Health Monitor server

Any Pentium III or IV CPU-based system

64MB or more RAM

MS Windows 2000 or NT 4 Server operating system. TBSM Health Monitor Server base services. Should have about 2 GB of free space.

4 GB free space

Chapter 6. Base services implementation 151

6.1.2 Software componentsIBM Tivoli Business Systems Manager requires the following software, which is listed with its recommended specifications. For more details, refer to IBM Tivoli Business Systems Manager: Release Notes, GI11-0886.

� Operating system: IBM Tivoli Business Systems Manager systems run on Windows server systems. For medium to large implementations (more than 30 events per minute), Microsoft Windows 2000 Advanced Server with Service Pack 2 is recommended. For small implementations, Microsoft Windows NT 4.0 Enterprise Edition with Service Pack 6a or Microsoft Windows 2000 Standard Server with Service Pack 2 are sufficient.

� Database engine: Microsoft SQL Server 7 with Service Pack 3 for Windows NT operating systems or Microsft SQL Server 2000 Enterprise Edition with Service Pack 2 for Windows 2000 operating systems.

� Toolkit: MKS Toolkit for Systems Administrators Version 7.5 or Version 8.0.

� Windows Resource Kit: The recommendation is Windows NT 4.0 Resource Kit Version 4.0 Supplement Three, which includes Regina REXX interpreter. If you use Windows 2000 Resource Kit, you must add:

– Support Kit from the Microsoft Windows 2000 Advanced Server distributed CD in the \Support\tools library

– IBM Object REXX Version 2.1

� Java Database Connectivity (JDBC) driver for the console server using Data Direct Connect version 2.2, 3.0, or 3.1; or Microsoft SQL Server 2000 Driver for JDBC (not available for Microsoft SQL Server 7.0). The Microsoft 2000 Driver for JDBC can be downloaded from http://www.microsoft.com/sql/downloads/default.asp

� Microsoft Internet Information Server (IIS), which can be from Windows NT 4.0 Option Pack or Microsoft IIS version 5.0 which comes with Windows 2000 Server.

6.1.3 Hardware and software configuration for this bookThis section discuss hardware and software configuration.

Hardware configurationsTable 6-2 shows the hardware configurations of the three servers running IBM Tivoli Business Systems Manager system in our lab.


Table 6-2 TBSM server configuration running in the lab

Software componentsTable 6-3 shows the installed prerequisite software in our servers.

Table 6-3 Prerequisite software components installed

Component SQL database server - ibmtib5

Console and propagation server - ibmtiv3

History and HMS server - ibmtiv6

CPU Dual 700MHz 1-MB Cache Pentium IV CPU on a Dual Processor–capable system

Dual 700MHz Pentium IV CPU on a Dual Processor–capable system

Dual 700MHz 1-MB Cache Pentium IV CPU on a Dual Processor–capable system

Memory 1 GB RAM 1 GB RAM 1 GB RAM

System Drive 4GB drive running MS Windows 2000 Advanced Server OS, System paging swap file, and TBSM/D Database base services.

8.5 GB drive running MS Windows 2000 Advanced Server OS, System paging swap file, and TBSM/D Console, propagation and Common Listener base services.

8.5GB drive running MS Windows 2000 Advanced Server OS, MS SQL 2000 Enterprise Server and TBSM database, System paging swap file, and TBSM/D Reporting System and HMS services.

Data Drive 8.5 GB drive contains SQL software and database.

None. None.

Software component

SQL database server - ibmtiv5



Operating System

Microsoft Windows 2000 Advanced Server with Service Pack 2



SQL Database Server

Microsoft SQL 2000 Server Enterprise Edition with Service Pack 2

Not applicable Microsoft SQL 2000 Server Enterprise Edition with Service Pack 2

Toolkit MKS Toolkit for System Administrators Version 8.0

MKS Toolkit for System Administrators Version 8.0

MKS Toolkit for System Administrators Version 8.0

Windows Resource Kit

Microsoft NT 4.0 Resource Kit Version 4.0 Supplement Three



JDBC Driver Not applicable Microsoft SQL Server 2000 Driver for JDBC

Not applicable


6.2 Prerequisite software components installationWe will not cover in detail the installation and customization of all the software components required to run IBM Tivoli Business Systems Manager. However, we provide information that we consider to be important for successful implementation. The components discussed are:

� 6.2.1, “Operating system: Windows 2000 Server” on page 154

� 6.2.2, “MKS Toolkit for Systems Administrators Version 7.5 or 8.0” on page 155

� 6.2.3, “Windows Resource Kit” on page 155

� 6.2.4, “JDBC Driver: Microsoft SQL 2000 Driver for JDBC” on page 155

� 6.2.5, “Microsoft IIS” on page 155

� 6.2.6, “Microsoft SQL Server” on page 156

6.2.1 Operating system: Windows 2000 ServerAfter installing the operating system following either standard or customized procedures, upgrade the OS to Service Pack 2.

It is advisable to complete the following tasks to ensure smooth implementation of IBM Tivoli Business Systems Manager on this system.

� The Administrator user ID must have a non-blank password. Ideally the password never expires. Experience has shown that certain services, processes, or SQL Agent jobs have to run under a local Administrator account. For example, FTP requires a valid user ID with non-blank password and appropriate access authorities.

� If the IBM Tivoli Business Systems Manager servers are installed as members of existing domains, setup security must be considered carefully prior to installation. Consult your NT domain administrator, and consider at least three levels of security:

– Communication between IBM Tivoli Business Systems Manager servers

IIS Option Pack

Not applicable Microsoft Internet Information Server (IIS) Version 5.0

Microsoft Internet Information Server (IIS) Version 5.0

Software component

SQL database server - ibmtiv5




– Users within the same domain to IBM Tivoli Business Systems Manager

– Users from outside the domain to IBM Tivoli Business Systems Manager

� If IBM Tivoli Business Systems Manager servers are installed in their own domain the same considerations should be addressed, keeping in mind that the intercommunication between these servers would not cause as much difficulty as above.

� Installing the IBM Tivoli Business Systems Manager servers as standalone servers in the same named workgroup is the most simple setup.

6.2.2 MKS Toolkit for Systems Administrators Version 7.5 or 8.0Follow the installation steps supplied with the product. The installed components must be in the Windows system path.

6.2.3 Windows Resource KitFollow the installation steps supplied with the product, keeping in mind that the installed components must be in the Windows system path.

For Windows 2000 Resource Kit, you also have to install the support tools and IBM Object REXX for Windows Version 2.1.

6.2.4 JDBC Driver: Microsoft SQL 2000 Driver for JDBCThis is available without charge if you are running Microsoft SQL 2000 Server Standard or Enterprise Edition. It can be obtained from

http://www.microsoft.com/sql/downloads/default.asp

After download, just run setup.exe as with any Windows application. To complete the installation, simply follow the instructions.

Be sure to make note of the installation path. (It is your decision whether to keep any version-related information in the installation path.) This path name will be required during the IBM Tivoli Business Systems Manager Console service installation. The Server.properties file will have to be updated with this path name under the TivoliManager\ConsoleServer directory.

6.2.5 Microsoft IISFollow the installation steps supplied with either of these products:

� Microsoft IIS Version 4.0 with Windows NT 4.0 Option Pack

� Microsoft IIS Version 5.0 with Windows 2000


6.2.6 Microsoft SQL ServerProceed with this installation only after all other prerequisite software has been installed and the server has been rebooted successfully.

We are presenting only our experiences from building our system in the lab with Microsoft SQL 2000 Server Enterprise Edition, which are meant to supplement the detailed tasks documented in IBM Tivoli Business Systems Manager: Installation and Configuration Guide, GC32-0800. Installations of other types of SQL servers could also benefit from the information here in addition to the actual tasks in the installation and configuration guide.

The four steps for installing SQL server must be completed in this sequence:

1. “Microsoft SQL 2000 Server Enterprise Edition installation” on page 156

2. “Changing SQL Server authentication password” on page 169

3. “Applying Microsoft SQL 2000 Server Service Pack 2” on page 172

4. “Updating SQL Server Client-Side Options” on page 172

Microsoft SQL 2000 Server Enterprise Edition installationExit all other Windows programs before proceeding with this setup. Do not re-install SQL server over an installed version. Uninstall the previous version and reboot the system before continuing with this installation.

It is important to complete all the dialogs as instructed. You can use the Back button to navigate backward to make any changes during installation, but it is better to cancel the installation process and re-start it than to try to fix the setup after an incomplete installation.

These are step-by-step instructions for our SQL server installation:

1. Log on to the SQL database server as Administrator.

2. Run setupsql.exe from the following directory: <drive:\mssql>\x86\setup\

3. The setup dialog begins with the InstallShield to guide you through installation. The welcome dialog is shown in Figure 6-1 on page 157.

Note: <drive:\mssql> is the drive letter of the CD-ROM or the path to an installation directory on a hard drive where the Microsoft SQL 2000 Server software resides.


Figure 6-1 InstallShield Welcome dialog

4. Click Next to go to the Computer Name dialog as shown in Figure 6-2. Select Local Computer and click Next for the Installation Selection dialog.

Figure 6-2 Computer Name dialog


5. In the Installation Selection dialog shown in Figure 6-3, select Create a new instance of SQL Server, or install Client Tools and click Next for the User Information dialog.

Figure 6-3 Installation Selection dialog

6. In the User Information dialog shown in Figure 6-4 on page 159, fill out the Name and Company fields with your information and click Next for the Software License Agreement dialog.


Figure 6-4 User Information dialog

7. In the license agreement dialog as shown in Figure 6-5, read the license agreement fully and, if you agree, click Yes to proceed to the Installation Definition dialog.

Figure 6-5 Software License Agreement dialog


8. In the Installation Definition dialog shown in Figure 6-6, select Server and Client Tools and click Next for the Instance Name dialog. This selection is required for SQL database server and the history server.

Figure 6-6 Installation Definition dialog


9. Leave Default checked, and click Next for the Setup Type dialog.

If the default option is not available, you may need to cancel the installation and remove the previously installed instances using Add/Remove Programs in Control Panel, then restart the new installation.

Figure 6-7 Instance Name dialog


10.At the Setup Type dialog in Figure 6-8, select Custom. Click the Browse button for Program Files, then Data Files to open the Choose Folder dialogs and change their respective installation folders. D:/ is the default installation folder for both Microsoft SQL 7.0 and Microsoft SQL 2000. Ensure adequate available free space as recommended for your production system servers.

Figure 6-8 Setup Type dialog

Attention: Do not put MSSQL in the installation destination path. It will be appended by the installer. If you type D:\MSSQL, then the installation will take place in D:\MSSQL\MSSQL.


11.Type the installation folder into the Path box as shown in Figure 6-9, and click OK to return to the Setup Type dialog. Click Next for the Select Components dialog.

Figure 6-9 Choose Folder dialog

12.Accept all the selected default components and their sub-components as shown in Figure 6-10. Ensure your production system servers have adequate available free space. Click Next for the Services Account dialog.

Figure 6-10 Select Components dialog


13.In the services accounts dialog shown in Figure 6-11, select Use the same account for each service. Auto start SQL Server Service. Then select Use the Local System account for the Service Settings. Click Next.

Figure 6-11 Services Account dialog


14.In the Authentication Mode dialog shown in Figure 6-12, select Mixed Mode and enter the login password for SQL sa userid. Click Next.

Figure 6-12 Authentication Mode dialog


15.From the collation setting dialog shown in Figure 6-13, select Latin1_General from the Collation designator pull-down menu. Select Binary as the Sort order. (These selections must be made as specified, or IBM Tivoli Business Systems Manager will not work properly.) Click Next.

Figure 6-13 Collation Settings dialog


16.For the Network Libraries dialog shown in Figure 6-14, keep the default settings in the Named Pipes and TCP/IP Sockets boxes. Check Multi-Protocol and Enable Multi-Protocol encryption. Do not check the other three boxes. Click Next.

Figure 6-14 Network Libraries dialog


17.In the start copying files dialog shown in Figure 6-15, click Back now if you need to change any parameters. When you are ready to continue with the installation, click Next.

Figure 6-15 Start Copying Files dialog


18.In the licensing dialog shown in Figure 6-16, select Processor License to enter the number of processors your license allows. Click Continue to proceed with the installation.

Figure 6-16 Choose Licensing Mode dialog

19.Various pop-up windows will appear at this stage of the installation showing its progress. Eventually, the Setup Complete dialog will appear. Click Finish to complete the installation.

Changing SQL Server authentication password1. Start the SQL Enterprise Manager by selecting Programs -> Microsoft SQL

Server -> Enterprise Manager. The SQL server Enterprise Manager window is shown in Figure 6-17 on page 170.

Note: It is not necessary to reboot the server after the installation. It is, however, good to do so because after the reboot you can see that all SQL services will be started automatically if the installation was successful.


Figure 6-17 SQL Server Enterprise Manager view

2. Expand the tree display of the Microsoft SQL Servers and find the following path: Console Root -> Microsoft SQL Servers -> SQL Server Group -> IBMTIV5 -> Security -> Logins as shown in Figure 6-18.

Figure 6-18 SQL Server Security options


3. Right-click the sa account in the right panel to open Properties. Type over the entry in the Password field with the new password for the General folder, as shown in Figure 6-19.

Figure 6-19 Change password

4. You will be asked to confirm the password as shown in Figure 6-20. Enter the new password and click OK to complete the password update.

Figure 6-20 Password confirmation

5. Close the SQL Enterprise Manager to complete the password update.


Applying Microsoft SQL 2000 Server Service Pack 2The following procedure upgrades Microsoft SQL Server to Service Pack 2 level.

1. Log on to SQL Database Server as Administrator.

2. Run setupsql.exe from the Service Pack 2 directory, usually in <\mssql>\x86\setup\

3. The Microsoft SQL Server Service Pack 2 setup dialog starts with the InstallShield Welcome dialog.

4. Follow the instructions in the dialog boxes. Accept the default settings and values throughout the installation.

5. Click OK on the message You should now backup your master and msdb databases since this installation has updated their content.

6. When the Setup Complete dialog opens, select Yes, I want to restart my computer now. Click Finish to conclude the upgrade.

7. The server will reboot now automatically.

Updating SQL Server Client-Side OptionsTo function correctly, IBM Tivoli Business Systems Manager requires changes to certain SQL Server client-side options, such as the ANSI NULL, paddings, and warnings. The following steps disable these options:

1. Open the SQL Query Analyzer from the Windows Start menu by selecting Programs -> Microsoft SQL Server -> Query Analyzer. This opens the Connect to SQL Server dialog as shown in Figure 6-21 on page 173.

Attention: Refer to pages 58 and 59 of the IBM Tivoli Business Systems Manager: Installation and Configuration Guide, GC32-0800 document regarding a potential problem with sp2_serv_uni.sql file. This modification, if applicable, must be made before Service Pack 2 can be applied.


Figure 6-21 Log on to SQL Query Analyzer

2. Type in your SQL server name or its IP address in the SQL Server box. Leave Start SQL Server if it is stopped clear. Select SQL Server Authentication and enter sa as the Login name and its password in the Password box. Click OK to log in.

3. From the SQL Query Analyzer window, select Query -> Current Connection Properties as shown in Figure 6-22.

Figure 6-22 Current Connection Properties


4. From the dialog in Figure 6-22 on page 173, clear the checkboxes for Set ansi_nulls, Set ansi_null_dflt_on, Set ansi_padding, Set ansi_warnings and Set quoted_identifier. This should clear Set ansi_defaults automatically. Click Apply and then OK to complete this dialog.

Figure 6-23 Connection Properties options


5. From the SQL Query Analyzer window, select Tools -> Options as shown in Figure 6-23 on page 174.

Figure 6-24 Opening the Options menu


6. In the Options dialog, choose the Connection Properties tab as shown in Figure 6-25, clear the checkboxes for Set ansi_nulls, Set ansi_null_dflt_on, Set ansi_padding, Set ansi_warnings and Set quoted_identifier. This should also clear Set ansi_defaults automatically. Click Apply and then OK.

Figure 6-25 Tools Options dialog

This concludes all the necessary steps for SQL Server installation and customization in preparation for IBM Tivoli Business Systems Manager base services installation.

6.3 Database server installationThe installation discussion in this chapter is used to set up and configure IBM Tivoli Business Systems Manager base services for a database server. The IBM Tivoli Business Systems Manager installation is performed in two steps. The first step updates some system files, extracts the main installation file into a temporary directory (typically C:\temp\tempinstall), and may reboot the machine if necessary. Then the main installation is performed.

Note: It would be advisable, though not necessary, to reboot the server before proceeding with base services installation.


The first step takes place as follows:

1. Start the IBM Tivoli Business Systems Manager installation program from the IBM Tivoli Business Systems Manager base services CD. Run setup.exe from the <CD drive>:\BaseServices directory. First, select the language used as shown in Figure 6-26.

Figure 6-26 Language selection dialog

2. After the initial preparation for the InstallShield, a welcome dialog from the System File upgrade appears as shown in Figure 6-27 on page 177. Click Next to continue.

Figure 6-27 System File Update welcome screen


3. The next dialog in Figure 6-28 prompts for a temporary directory to unpack the actual installation files. Accept the default C:\temp\tempinstall and click Next.

Figure 6-28 Temporary directory selection


4. The installation progresses, and after all files have been extracted, the Setup Complete dialog opens, as shown in Figure 6-29. Click Finish.

Figure 6-29 System File Upgrade complete

5. The second step of the installation begins with another language selection screen similar to Figure 6-26 on page 177. Then the Welcome dialog appears as shown in Figure 6-30 on page 180. Click Next to continue.

Important: If you have to reboot the computer to re-do these steps, you should not have to reboot again the next time you reach this point.


Figure 6-30 Welcome dialog for TBSM installation

6. After reading the license agreement dialog as shown in Figure 6-31, click Yes to continue.

Figure 6-31 License agreement dialog


7. Next, specify the installation directory for IBM Tivoli Business Systems Manager. It is recommended that you keep the name TivoliManager and, if necessary, change the letter of the drive where it is to be installed. We keep the installation on the C drive and select Next.

Figure 6-32 Setup path selection


8. Select Custom Setup type as shown in Figure 6-33. Click Next to continue.

Figure 6-33 Setup type selection


9. Specify the components to be installed as shown in Figure 6-34. For the SQL database server with IBM Tivoli Business Systems Manager distributed, choose the following:

– Database Server– Distributed TEC Listener– NetView for OS/390 Command Processor (selected by default)

Click Next.

Figure 6-34 Select Components for database server


10.The host name dialog is shown in Figure 6-35. Click Next to continue.

Figure 6-35 Enter Information for SQL database server host name


11.Fill in the database server field, and use sa and sa_<hostname> for the Username and Password fields as shown in Figure 6-36. If you specified a different password in “Changing SQL Server authentication password” on page 169, you should use it now.

Figure 6-36 Database parameters dialog


12.In our case, we created a new installation so we did not select Upgrade existing 1.5 databases as shown in Figure 6-37. Click Next to continue.

Figure 6-37 Database upgrade dialog

13.Now the installer is ready to copy the files. Figure 6-38 on page 187 indicates the summary of our installation options. Click Next to start the installation.


Figure 6-38 Start copying files dialog

14.After the installation, the Setup Complete dialog appears as in Figure 6-39. Click Finish.

Figure 6-39 Setup Complete dialog


15.First, stop Microsoft SQL Server Agent and MSDTC services from the Microsoft SQL Server Service Manager in your system tray.

16.Open the SQL Query Analyzer window through Programs -> Microsoft SQL Server -> Query Analyzer, and run TivoliManager\sql\DetachDatabases.sql

17.Extract the SQL database seed files from the IBM Tivoli Business Systems Manager base services CD using DBDevices\DBDevices_V2.1.exe. Run the program and, in the PKSFX window as shown in Figure 6-40, specify the directory. (The database is on our data drive (D:), so we specify D:\MSSQL\Data as the target path.) Click Extract.

Figure 6-40 Extract seed database files

Note: Now configure the database server with IBM Tivoli Business Systems Manager’s supplied seed database.


18.Back in the SQL Query Analyzer window, open the file TivoliManager\sql\AttachDatabases.sql. Update all XXXX, YYYY, and ZZZZ (some of the modifications are shown in Figure 6-41) by specifying the host name of your servers. Run the query by pressing F5.

Figure 6-41 Changes in AttachDatabases.sql

19.Open and run the following query files in the SQL Query Analyzer against the specified databases (after changing the database pull-down menu to the specified database name):

MasterDBChanges master

SchemaTypes master, tempdb, model

SchemaMessages master

After these installations a new set of services will be installed. Figure 6-42 on page 190 shows the Services setting for our ibmtiv5 machine.


Figure 6-42 Services setting

6.4 Console and propagation server installationMost of the steps used to install the database server apply to console and propagation server installation. Follow the installation procedure provided in 6.3, “Database server installation” on page 176, with the following exceptions:

1. You can follow step 1 on page 177 through step 8 on page 182 for the Systems File Upgrade.


Then, Select Components window shown in Figure 6-43, install the following components:

– Console Server– Propagation Server– Common Listener

Figure 6-43 Component selection

2. The next dialog is the host name dialog as shown in Figure 6-35 on page 184. Click Next to continue.

3. Fill in the parameters for the database server host name and enter sa and sa_<hostname> for the Username and Password fields. The dialog is shown in Figure 6-36 on page 185. If you specified a different password in “Changing SQL Server authentication password” on page 169, use it now.

4. The console server authenticates and confirms the authority of the connected users using Windows groups. Be sure Yes is chosen in the Create local groups dialog, as shown in Figure 6-44 on page 192. Click Next to continue.


Figure 6-44 Create local groups dialog

5. Choose which JDBC driver to use. We use the Microsoft SQL Server 2000 Driver, as shown in Figure 6-45. Click Next to continue.

Figure 6-45 JDBC driver selection dialog


6. Now the installer is ready to copy the files and present the summary of selected installation options as shown in Figure 6-46.

Figure 6-46 Installation options

7. The installer starts copying files. When it is finished, the Setup Complete dialog appears. Click Finish.

8. In the TivoliManager\ConsoleServer\Servers.properties file, several parameters may have to be configured manually. The file contain extensive comment and explanation of each parameter. We do not configure this file for our installation.

9. You may want to configure the banner text for the console using the html files in the TivoliManager\ConsoleServer\banner\ directory. There are different HTML files for each level of authority. Note that these banners will be shown in a fixed-height area on the console.

10.Manual configuration of the common listener is performed in the file TivoliManager\CommonListener\ASICommonListener.properties. We do not change this file for our installation.

The Services list for our ibmtiv3 server is shown in Figure 6-47 on page 194.


Figure 6-47 Services list for console and propagation server

The IBM Tivoli Business Systems Manager–related groups are shown in the Computer Management display in Figure 6-48.

Figure 6-48 TBSM operators groups

6.5 History server installationThe installation of the history server is similar to the database server installation described in 6.3, “Database server installation” on page 176. Perform step 1 on page 177 through step 8 on page 182. When the Select Component dialog appears, select History Server as shown in Figure 6-49 on page 195.


Figure 6-49 History Server component selection dialog

Customize the BCP transfer settings and history server configuration as follows:

1. From the SQL Query Analyzer, run TivoliManager\sql\detachhistorydatabases.sql.

2. Copy the Object, Meta, RODM, and WebServer databases, either from the live server or from the file DBDevices\DBDevices_V2.1.exe. If you are copying from the live server, you may want to stop the Microsoft SQL Server service first, before copying it.

3. From the SQL Query Analyzer, run TivoliManager\sql\attachhistorydatabases.sql.

4. Open and run the following query files in the SQL Query Analyzer against the specified databases (after changing the database pull-down menu to the specified database name):

MasterDBChanges master

SchemaTypes master, tempdb, model

SchemaMessages master

Tip: There are two options for installing the history server. The BCP path is recommended over the Linked Server. The following procedure implements the BCP-based history server.


5. Create a new database called History using the Enterprise Manager. Select IBMTIV6 -> Databases and right-click to open the New Database menu as shown in Figure 6-50.

Figure 6-50 Creating a new database


6. The Database Properties dialog opens. Enter the database name History as shown in Figure 6-51. Click OK to create the database.

Figure 6-51 History database properties

7. From the SQL database server, run the HistoryServerSetup.ksh command. While the script is running, you will srr two popup messages that confirm the execution, as shown in Figure 6-52.

Figure 6-52 Pop-up message for historyserversetup.ksh


The running of the program in our environment is shown in Example 6-1.

Example 6-1 Running HistoryServerSetup.ksh

C:\> sh$ HistoryServerSetup.ksh -N ibmtiv6 -R sa -W sa_ibmtiv6Setting up BCP managed History Server database on REMOTE IBMTIV6***************************************************************************************************** S E T U P H I S T O R Y S E R V E R ********************************************************************************************************Done!Done!***************************************************************************************************** S E T U P P R I M A R Y S E R V E R ********************************************************************************************************Could not find table eventbcpOLD. Will try to resolve this table name later.Could not find table event_lastbcpOLD. Will try to resolve this table name later.Creating bcp version of view event_VDone!History Server Setup Done!

8. To complete and enable the reporting system, be sure the new jobs Copy Backups from Live DB Server and Restore Databases for Reporting System are on the history server.

9. Delete any old reporting system jobs, such as Copy Backups to History Server and Update Object and Meta Databases.

You can search for these jobs on the history server by using SQL Enterprise Manager. Click Management -> SQL Server Agent -> Jobs.

10.Run a SQL database backup job on the live database server if one has not been run recently. Be sure that the user ID associated with the SQLServerAgent on both the live and history servers has TBSM_Administrator authority. This is to ensure that the Move events to History Database job on the live database server will run successfully.

11.Run the Copy Backups from Live DB Server job on the history server. Verify that the database backups have arrived on the history server. Currently these are the backup files of the Meta, Object, and RODM databases.

12.Run the Restore Databases for Reporting System job on the history server.

13.Setting up the reporting system:

Use the Reporting System Database Configuration program found in the Tivoli Manager programs folder to set up the DefaultData and PrimaryData databases with the parameters shown in Table 6-4 on page 199.


Table 6-4 Database attributes for reporting system

6.6 Health Monitor Server implementationHealth Monitor services has two components: Health Monitor Server (HMS) and Health Monitor Client. Health Monitor Server is installed through the Select Components dialog that appears during history server installation.

6.6.1 HMS InstallationHMS installation is similar to 6.3, “Database server installation” on page 176. Perform step 1 on page 177 through step 8 on page 182. Then select the Health Monitor Server component when prompted with the Select Components dialog shown in Figure 6-53 on page 200. Click Next.

Parameter Default data Live data Web server

Driver (SQL Server) (SQL Server) (SQL Server)

Server Name IBMTIV6 IBMTIV5 IBMTIV5

User ID sa sa sa

Password sa_ibmtiv6 sa_ibmtiv5 sa_ibmtiv5

Database name Object Object WebServer

Note: Other, previously installed components will appear as seleted in this dialog. Do not clear these other components from the list.


Figure 6-53 Health Monitor Server component selection dialog

In the dialogs that follow, enter the local host name and database settings, then proceed with the installation.


Fill in the Health Monitor Server host parameters as shown in Figure 6-54. For any host that you do not want to show, enter UNUSED. Click Next.

Figure 6-54 Health Monitor Server host name dialog


In the next dialog, enter the profile information for this Health Monitor Server instance. We named the profile similar to the host name of the Health Monitor Server as shown in Figure 6-55.

Figure 6-55 Health Monitor Server parameters dialog

Proceed until the Setup Complete dialog is shown. Press Finish to exit.

6.6.2 CustomizationYou should be able to start the Health Monitor service right after the installation. However, some installations may require modifying the Services setting. The Health Monitor serviceuses SRVANY.exe from the Windows Resource Kit to launch HMSQueries.ksh as a service. You may need to modify these:

� SRVANY parameters: From the registry editor (run as REGEDT32), open the SYSTEM\CurrentControlSet\Services\ASIHealthMonitor key under HKEY_LOCAL_MACHINE. If there is a sub-key called Parameters, open it; if not, create it. Enter the following values (all with the type of REG_SZ):

AppDirectory <drive>:\TivoliManager\Mgmt\HMS\ShellScript

Application sh.exe

AppParameters HMSQueries.ksh -k <profilename>

� Change the user ID that is used to start the service because it cannot be started using the local system account. It must use the account Administrator,


or you need a pre-established share to the IBM Tivoli Business Systems Manager servers machines. To do this on a Windows 2000 machine:

a. Open the services window using Program -> Administrative Tools -> Services. Right-click on the Tivoli BSM Health Monitor as shown in Figure 6-56 to open the Properties dialog.

Figure 6-56 Open the Properties dialog for Health Monitor


b. Click the Log On tab, enter Administrator as the user ID, and type in the password as shown in Figure 6-57.

Figure 6-57 Health Monitor Log On tab


� Several installation-dependent elements in the default Health Monitor profile must be customized. Check and modify the profile registry setting in HKEY_LOCAL_MACHINE under the path SOFTWARE\Accessible Software, Inc.\Access1\1.0\Health Monito\Profiles as shown in Figure 6-58.

Figure 6-58 Health monitor profile


The Default Services definition is shown in Figure 6-59.

Figure 6-59 Default services definition

The following services, shown in Figure 6-59, are not applicable in IBM Tivoli Business Systems Manager Version 2.1:

• Tivoli BSM Application Server• Tivoli BSM Console Server• Tivoli BSM Notification Server

For IBM Tivoli Business Systems Manager distributed, only the MVS-related services are not used, such as:

• Tivoli BSM MVSIPListener• TIvoli BSM MVSIPOSListener• Tivoli BSM MVSUploadRuleServer• Tivoli BSM Database Validater - Host MVS• Tivoli BSM Enqueue Proxy Server - Host MVS

For IBM Tivoli Business Systems Manager distributed edition with two-server configuration, the Common Listener resides with the console


server, so we must change the host definition for the Tivoli BSM Common Listener from $DBHost into $ASHost as shown in Figure 6-60.

Figure 6-60 Settings for Common Listener


To limit the queues that are monitored, edit the table MonitoredQueueTable, whose content is shown in Figure 6-61. You may want to delete the unnecessary rows, such as the Notification and Notification8 queues, as they are not used in IBM Tivoli Business Systems Manager Version 2.1.

Figure 6-61 MonitoredQueueTable

6.6.3 Health Monitor Client implementationTo install the Health Monitor Client, run the IBM Tivoli Business Systems Manager Base Services installation as discussed in 6.3, “Database server installation” on page 176. Select a Custom install, and install the Health Monitor Client only in the dialog shown in Figure 6-53 on page 200. There is no Custom parameter for the Health Monitor client installation.


Chapter 7. TEC components integration

This chapter describes how to integrate IBM Tivoli Business Systems Manager with Tivoli Enterprise Console (TEC). The integration enables events to be collated by TEC and then forwarded to IBM Tivoli Business Systems Manager.

The discussion consists of:

� 7.1, “Tivoli Enterprise Console overview” on page 210 introduces TEC and describes its integration with IBM Tivoli Business Systems Manager

� 7.2, “Setting up the TEC connection” on page 211 describes the tasks needed to set up the connection

� 7.3, “IBM Tivoli Monitoring modules integration” on page 226 explains the integration of the IBM Tivoli Monitoring for Databases as an example

� 7.4, “Creating a generic component” on page 230 explains the tasks to set up a generic component from the TEC interface

� 7.5, “Defining a component from DM monitors” on page 235 discusses the classic Tivoli Distributed Monitoring event integration

� 7.6, “Troubleshooting” on page 242 shows some troubleshooting tips regarding the TEC connection

7


7.1 Tivoli Enterprise Console overviewTivoli Enterprise Console (TEC) provides a central point of integration and control for enterprise client/server environments. It enables administrators to monitor information about the environments for which they are responsible. TEC assists in maintaining high availability of the myriad networks, systems, applications, and databases found within an enterprise. It also helps detect potential problems before they cause outages. When problems are detected, TEC may be configured to take action and intervene as defined by the customer.

The basic integration involves the following main tasks:

� Enabling Tivoli Enterprise Console to send events to IBM Tivoli Business Systems Manager

� Importing BAROC class files and integrating a new ruleset

The flow chart in Figure 7-1 illustrates the integration.

Figure 7-1 Event flow for IBM Tivoli Business Systems Manager integration

TBSM Database

TEC

APM Heartbeat

APM Threshold

EVENT

Sentry 2.0 Base

TBSM setemsg statusevent

Event Enablement

TBSMAgent Listener

gemeeconfig

ihstmtec

ihsthtec

ihstztec

ihstttec

Note Change Trigger

wpostemsg

OS390 ihst3tec

Task Server

Operational commands

tgmtask

interapp

ihstdmon

tbsmstatus


1. Events are generated by the ITM resource model, TEC adapter, or any other types of event. The events are sent to the TEC Event Server for processing. Depending on the event types, a specific TEC ruleset will process it:

APM events interapp.rlsSentry events ihstdmon.rlsGeneric events ihstdmon.rlsTBSM events tbsmstatus.rls

2. Depending on the event and the criteria we have set up within the rule, the ruleset uses the ihst?tec exit to forward the event information to the event enablement process.

3. Event enablement sends the formatted event to the agent listener, which resides in the IBM Tivoli Business Systems Manager database server. The agent listener evaluates the event and stores it in the IBM Tivoli Business Systems Manager database. This informs the IBM Tivoli Business Systems Manager console of the status of monitored objects’ changes.

4. When an operator invokes an operational task by clicking the context menu, a request is sent to the task server process. The task server executes the operational task using the wruntask command.

5. Changes in the event status in IBM Tivoli Business Systems Manager are forwarded using a trigger back to TEC in the form of a TBSM setemsg event.

7.2 Setting up the TEC connectionSetting up the connection from TEC to IBM Tivoli Business Systems Manager involves several steps:

� 7.2.1, “Installing event enablement and the task server” on page 211

� 7.2.2, “Setting up the user ID” on page 213

� 7.2.3, “Updating the TEC event classes and rules” on page 217

� 7.2.4, “Enabling TBSM agent listener” on page 225

7.2.1 Installing event enablement and the task serverEvent enablement is the interface between TEC and IBM Tivoli Business Systems Manager. Before installing the event enablement component, back up the Tivoli database using the wbkupdb command, then follow these steps to install event enablement onto an already functional Tivoli Management Framework environment:

1. From the Tivoli desktop, use the menu Desktop -> Install -> Install Product to display the Install Product dialog shown in Figure 7-2 on page 212.

Chapter 7. TEC components integration 211

Figure 7-2 Install Product window

2. Use the Select Media button for the path of the IBM Tivoli Business Systems Manager Distributed CD. This must be the machine that is running the TEC server. (In our environment, install onto ibmtiv9.) Select Tivoli Business Systems Manager Event Enablement 2.1.

3. Click Install & Close to complete event enablement installation. This also installs the task server by default. The files that have been installed are located in the $BINDIR\TDS directory.

4. Click Continue Install after verifying the directories, then click Close when the installation is finished.

Event enablement and the task server have been installed as daemons on a UNIX platform or as services on a Windows platform.


On UNIX:

� ihstdmai:event enablement daemon

� ihscts: task server daemon

On Windows:

� Tivoli BSM Event enablement service

� Tivoli BSM Task Server service

Figure 7-3 displays the additional services for our TEC server on Windows 2000.

Figure 7-3 Services window

7.2.2 Setting up the user IDWe now define the user account under which these services will run within the Windows 2000 environment. (This process is unnecessary if TEC has been installed on a UNIX platform, as the daemons run under the root user.)

You may create a new account or use a different account you already have on the system that has the following user rights, which are required to run the event enablement and task server services:

� Act as part of the operating system.

� Replace a process-level token.

� Log on as a service.


To define or select the user ID:

1. Select Programs -> Administrative Tools -> Local Security Policy to open the Local Security Settings window.

2. On the tree view, click Local Policies -> User Rights Assignment.

3. Right-click Act as part of the operating system and click Security as shown in Figure 7-4.

Figure 7-4 Local Security Settings window


4. If your target user ID is not listed as shown in Figure 7-5, then click Add and add the user ID.

Figure 7-5 Security setting dialog

5. Click OK when finished.

6. Repeat steps 3 through 5 for Replace a process level token.

7. Repeat steps 3 through 5 for Log on as a Service.

8. Log off and log back on for user rights to take affect.

9. Open the Services window again by selecting Start ->Programs -> Administrative Tools -> Services.

10.Right-click the Tivoli BSM Event Enablement service and click Properties.


11.Select the Log On tab, as shown in Figure 7-6.

Figure 7-6 Tivoli BSM Event Enablement Properties window

12.Select This account and enter the user ID and password that you created in step 4.

13.Repeat steps 10 through 12 for the Tivoli BSM Task Server service.

The task server runs tasks within the Tivoli Management Framework; therefore, the user ID that we have chosen within Windows to run the Task Server must be associated with a Tivoli administrator on the Tivoli Management Framework.

1. Open a Tivoli desktop and select Administrators as per Figure 7-7 on page 217. Right-click Administrators and select Open.


Figure 7-7 TME Desktop of Administrator window

2. Right-click the icon for the selected administrator. Select Edit Logins.

3. Type the login name you are using to run the task server.

4. Press enter. The new user ID should appear under Current Login Names.

5. Click Change & Close.

7.2.3 Updating the TEC event classes and rulesIn order for TEC to understand which events to forward to IBM Tivoli Business Systems Manager, we must make some modifications to the rulebase and event classes. A script has been provided during installation that will do most of the work for you. If the new rules cause problems in your environment, you can modify and add each one of the classes and rulebases manually.


The script used to configure TEC is called ihsttec.sh and it is found on the Tivoli Enterprise Console server machine in the %BINDIR%\TDS\EventService directory. We ran the script, and an excerpt from the result is shown in Example 7-1.

Example 7-1 Output from running ihsttec.sh

C:\Tivoli\bin\w32-ix86\TDS\EventService>bashbash$ ./ihsttec.sh###########################################################Creating GemEvent rules data base.

ATTENTION:If you are installing multiple TMRs, have you updatedthis file to include the defaults for your Topology Server? Input Rules Base Name? Output Rules Base Name? Routing rules?

The file name is C:/Tivoli/bin/w32-ix86/TDS/EventService/ihsttec.shIf you have not done so, please terminate now and reexecute.########################################################### Press Enter to continue or "q" to quit.

Will this copy of Event Enablement forward events toGlobal Enterprise Manager (GEM)?Enter 'Y' if GEM will be used.Enter 'N' if GEM will not be used.The default is: Nn

Please enter the name of the TEC Rules Base to copyas a starting point for creating the GemEvent rules base.If no name is entered we will use the name: DefaultNewDefault

Do you want this TEC to forward APM events to Event Enablement?Enter 'Y' to forward events.Enter 'N' to not forward events.The default is: Ny

Should TEC status changes (ACK, RESPONSE, CLOSED) associatedwith APM Threshold events be sent to TBSM?If no is specified, then APM Threshold events will beautomatically closed in TEC when they are received.Enter 'Y' send status events to TBSM.Enter 'N' to not send status event to TBSM.


The default is: Yy

Do you want this TEC to forward DM monitors to Event Enablement?Enter 'Y' to import the ihstdmon.rls file.Enter 'N' to not import the ihstdmon.rls file.The default is: Ny

Does your TEC receive OS/390 events from TBSM using theTEC EIF interface?Enter 'Y' if this feature is configured.Enter 'N' if this feature is not used..The default is: Nn

Do your DM profiles include NT Monitoring Collections?Enter 'Y' if the do.Enter 'N' if they do not.The default is: Ny

--> Does NewDefault contain a partial collection of--> NT Monitoring Collection classes?--> Enter 'Y' if you want any missing NT classes added to GemEvent.--> Enter 'N' if you do not want any missing NT classes added to GemEvent.--> The default is: Ny

Do your DM profiles include Windows/2000 Monitoring Collections?Enter 'Y' if the do.Enter 'N' if they do not.The default is: Ny

--> Does NewDefault contain a partial collection of--> Windows/2000 Monitoring Collection classes?--> Enter 'Y' if you want any missing Windows/2000 classes added to GemEvent.--> Enter 'N' if you do not want any missing Windows/2000 classes added to GemEvent.--> The default is: Ny

Do your DM profiles include OS/2® Monitoring Collections?Enter 'Y' if the do.Enter 'N' if they do not.The default is: Nn


Do your DM profiles include UNIX Monitoring Collections?Enter 'Y' if the do.Enter 'N' if they do not.The default is: NDo your DM profiles include Univeral Monitoring Collections?Enter 'Y' if the do.Enter 'N' if they do not.The default is: Nn

Do your DM profiles include OS/400® Monitoring Collections?Enter 'Y' if the do.Enter 'N' if they do not.The default is: NnCreate the GemEvent Rules BaseChecking to see if GemEvent existsRule Base Name--------------

We have not included the entire output from the running of this script because of its length and the repetitive nature of loading class files. However, it can be seen that this script creates a new rulebase called GemEvent by copying the rules and classes from a specified rulebase (in our case it was called NewDefault) using the options that we selected. We also have a profile called ClassicSentryProfile, which contains classic DM monitors that forward events to IBM Tivoli Business Systems Manager. This script’s completion results in the new rule base called GemEvent, shown in Figure 7-8 on page 221.


Figure 7-8 Event Server Rule Bases window

The GemEvent rule base can be found in %BINDIR%/TDS/EventService/config/GemEvent_rb. Right-click on its icon and select the Import option to open the Import Into Rule Base dialog shown in Figure 7-9 on page 222.


Figure 7-9 Import Into Rule Base window

Three new rules have been added using the process in Example 7-1 on page 218:

� tbsmstatus.rls� interapp.rls� ihstdmon.rls


Two new BAROC files have been added as well:

� interapp.baroc� tbsmstatus.baroc

The uses of these files are:

� tbsmstatus.rls and tbsmstatus.baroc: These ruleset and class definitions are used to maintain consistency in the status between IBM Tivoli Business Systems Manager and TEC. In TEC the status can be:

ACK An operator has acknowledged the event and assumed responsibility.

CLOSED The event has been resolved.

OPEN No action has been taken on the event.

RESPONSE A rule has responded automatically to the event.

Custom_status A site-specific status: The status has been added to the STATUS enumeration.

From the console, an operator can take ownership of an event. This is analogous to an ACK in IBM Tivoli Enterprise Console.

Events acknowledged in IBM Tivoli Enterprise Console result in a take-ownership icon appearing on the console as soon as the event arrives. When an event in IBM Tivoli Enterprise Console is closed, the severity of the corresponding event in IBM Tivoli Business Systems Manager is set to Harmless to indicate that the event has been resolved. If the status of an IBM Tivoli Enterprise Console event is changed to RESPONSE, then the automation-icon in IBM Tivoli Business Systems Manager can be set for the corresponding resource. When an IBM Tivoli Business Systems Manager operator takes ownership of an event, the status of the event in IBM Tivoli Enterprise Console is changed to ACK. And if the event is set to Harmless in IBM Tivoli Business Systems Manager, then the status of the event in IBM Tivoli Enterprise Console is changed to CLOSED. The tbsmstatus.rls is shown in Example 7-2.

Example 7-2 tbsmstatus.rls

rule:tbsm_setemsg_status_rule:( event: _event of_class 'TBSM_setemsg_status_event' where [ o_class: _o_class, o_date_reception: _o_date_reception, o_server_handle: _o_server_handle, o_event_handle: _o_event_handle, new_status: _new_status,


new_admin: _new_admin ], /* ----------------------------------------------- */ /* Find the original event in TEC */ /* Drop the new event since this is only an update */ /* Update the staus in the original event */ /* ----------------------------------------------- */ reception_action: ( drop_received_event, first_instance(event: _original_event of_class _o_class where [ date_reception: equals _o_date_reception, server_handle: equals _o_server_handle, event_handle: equals _o_event_handle ] ), set_event_status(_original_event, _new_status),

set_event_administrator(_original_event, _new_admin), commit_set )).

� interapp.rls/interapp.baroc represents a ruleset/class definition that is used to forward Application Policy Management (APM) events to IBM Tivoli Business Systems Manager. APM architecture describes event flows that support the discovery and monitoring of multiple instances of an application. IBM Tivoli Business Systems Manager supports these parts of the APM architecture.

� ihstdmon.rls represents a rule that will send classic distributed monitoring events to IBM Tivoli Business Systems Manager through TEC. This rule can be modified to suit our environment. Our modified ihstdmon.rls is shown in Example 7-3.

Example 7-3 ihstdmon.rls

rule:ihstdmon_ClassicSentryProfile: ( description: 'invoke IHSTZTEC which will get the slot \ values from the environment and forward\ the event to Event Enablement.', event: _event of_class _class where [ sub_source: equals 'ClassicSentryProfile' ], reception_action: ( exec_program(_event,


'../../TDS/EventService/ihstztec', '', [], 'YES') ) ). change_rule:ihstdmon_change_ClassicSentryProfile: ( description: 'change rule for ClassicSentryProfile.', event: _event of_class _class where [ sub_source: equals 'ClassicSentryProfile' ], attribute: status set_to _newstatus within ['ACK', 'RESPONSE', 'CLOSED'], action: ( exec_program(_event, '../../TDS/EventService/ihstztec', '-n', [], 'YES') ) ).

From this rule you can see that it will pass any event that has a subsource of ClassicSentryProfile to the agent listener by invoking the ihstztec executable from within this rule.

7.2.4 Enabling TBSM agent listenerThe agent listener communicates with the event enablement process. It runs on the database server machine and connects to all TEC servers that will feed events to it. Its configuration is maintained using the gemeeconfig command. To add a communication to ibmtiv9’s event enablement, issue the gemeeconfig -a ibmtiv9 command. This will set the communication between the agent listener and event enablement on TEC Server ibmtiv9. Example 7-4 shows that the connection to ibmtiv9 is active.

Example 7-4 Gemeeconfig command

C:\>gemeeconfig

Listing configured Event Enablers:


Event Enabler: ibmtiv9 Connection Status: Connected Enabled for connection at startup. Port: Default Port RetryTime: Default

Done.

By default the TCP/IP port 4030 is used for event enablement to agent listener communication. You can see from Example 7-4 on page 225 that when the agent listener starts, it will connect to an event enabler running on ibmtiv9. You can change any of the default parameters, such as the TCP/IP port, by using the gemeeconfig command.

7.3 IBM Tivoli Monitoring modules integrationIBM Tivoli Monitoring modules, which are based on IBM Tivoli Monitoring version 5.1.1, replace most of the Tivoli Manager for products. Although they are based on IBM Tivoli Monitoring, the interface to IBM Tivoli Business Systems Manager uses TEC instead of common listener as discussed in Chapter 8, “IBM Tivoli Monitoring integration” on page 249.

This section demonstrates the integration of IBM Tivoli Monitoring for Databases: DB2 with IBM Tivoli Business Systems Manager. These steps set up the integration:

1. Define IBM Tivoli Monitoring for Databases resources to Tivoli Business Systems Manager. This includes defining the object types, icons, operational tasks, and other necessary attributes. Use the installation program in the TBSM subdirectory of the IBM Tivoli Monitoring for Databases CD-ROM. Run install.bat on the Tivoli Business Systems Manager database server. The installation will copy the uninstallation program and start the initialization script called <component>_init_tbsm.sh, where component indicates the component to be installed.

2. Event enablement is already installed on our system so the next step is to modify the rulebase to forward DB2 events to it. To do this we use the Configure Event Server task. If you have installed event enablement on this event server, this task recognizes it and compiles the rule base that forwards events to IBM Tivoli Business Systems Manager. You can see the addition of a new rule db2_to_TBSM.rls in Example 7-5.

Example 7-5 Excerpt of db2_to_TBSM.rls

/* COPYRIGHT: Licensed material - Property of IBM *//* 5648-A46 (C) Copyright IBM Corp. 2002 */


/* All Rights Reserved *//* US Government Users Restricted Rights - *//* Use, duplication or disclosure restricted *//* by GSA ADP Schedule Contract with IBM Corp. *//* *//***************************************************************/rule:forward_DB2_event_to_tbsm:( event: _event of_class within ['DB2_Event']

where [ ],reception_action: send_to_TBSM:

( exec_program(_event,

'scripts/DB2_send_to_TBSM.sh', '', [], 'YES'),

commit_set )).

rule:forward_DB2_Clearing_Event_to_tbsm:( event: _event of_class within ['TMW_Clearing'] where [ application_class: _application_class within [ 'DB2InstanceManager', 'DB2PartitionManager', 'DB2PartitionGroupManager', 'DB2DatabaseManager', 'DB2Gateway' ], eventname: _eventname ], reception_action: send_to_TBSM: ( exec_program(_event, 'scripts/DB2_send_to_TBSM.sh', '"%s"', [ _eventname ], 'YES'), commit_set )).

This rule invokes a script called DB2_send_to_TBSM.sh as shown in Example 7-6, which in turn formats and sends the event to the event enablement engine within TEC. It uses the ihstttec exit, which is the generic event exit.


Example 7-6 DB2_send_to_TBSM.sh

#!/bin/shif [ "$1" != "" ]; then EVENT_CLASS=$1fi# The following will happen with clearing eventsif [ "$application_version" = "" -o "$application_version" = "N/A" -o "$application_version" = "n/a" ]; then application_version="7.x"fiTMP=`wtemp`LOGDIR=${TMP}/DB2if [ ! -d $LOGDIR ]; then mkdir $LOGDIRfiLOG=${LOGDIR}/trace_itmDB2_send_to_TBSM.logexec 2>$LOGset -xSOFTCOMP_NAME="DB2"FILEPREFIX="itmDB2"$TEC_BIN_DIR/../../TDS/EventService/ihstttec -b "$application_class;$application_version" -i "$application_label" -p "$EVENT_CLASS" -s "$severity" -t "EXCEPTION" -4 oid="$application_oid" -q "$origin" -m "$msg"grep "$application_class;$application_oid;$application_version;$application_label;$origin" ${TMP}/${FILEPREFIX}_DISCOVERED_to_tbsm.file >/dev/nullif [ $? != 0 ]; then echo "$application_class;$application_oid;$application_version;$application_label;$origin" >>${TMP}/${FILEPREFIX}_DISCOVERED_to_tbsm.filefi

3. Before we can obtain the status of any of the objects reflected in the TBSM console, we have to run discovery. After you define the object types, you must define the specific objects. You can do this with the ECC_TBSM_Discovery task. This task searches a managed node for objects and sends a DISCOVER event to IBM Tivoli Business Systems Manager for each object.

The shutdown of a DB2 database that has been monitored would be reflected in the IBM Tivoli Business Systems Manager console as shown in Figure 7-10 on page 229.


Figure 7-10 TBSM console: All Resources - Descendents window

This shows that the database down state has propagated up the Business System View.

For your reference, Table 7-1 shows the TEC setup tasks and the IBM Tivoli Business Systems Manager discovery tasks for other IBM Tivoli Monitoring modules.

Table 7-1 IBM Tivoli Monitoring tasks

Module TEC setup task TBSM disovery task

Databases: DB2 DB2ManagerAdminTasksECC_Configure_TEC_Classes

DB2ManagerAdminTasksECC_TBSM_Discovery

Databases: Oracle ITMOracle TasksConfigureTECOracle

ITMOracle TasksOracleTBSMDiscovery

Databases: Informix® IBM Informix Server TasksConfigure_TEC

IBM Infomric Server Task.TBSM_Discovery

Business Integration: WebSphere MQ

Configure Event Server menu from Monitoring for WebSphere MQ icon

MQS TBSM QMgr:Discover_Queue_ManagersMQS TBSM Queue: Discover_QueuesMQS_TBSM_Channel:Discover_Channels

Business Integration: WebSphere MQ Integrator

MQSI Event Tasks: Configure Event Server

MQSI Utility Task:MQSI TBSM Discover


7.4 Creating a generic componentIn this section we show how to create and define a new component using the generic event interface. The example that we perform is very simple yet shows the basic necessary actions.

First, define a generic software component within IBM Tivoli Business Systems Manager. This will enable IBM Tivoli Business Systems Manager to receive the specifically defined event from TEC and map its status onto an object, typically an icon. To create this object we run the gemgenprod.sh command on the database server. This command generates an extension to the TBSM database. The syntax of the command is:

sh gemgenprod.sh [–S server][–U user][–P password] –m manufacturer –p product –v version

where:

–S server Specifies the name of the SQL server system–U user Specifies the SQL user ID to the SQL server system–P password Specifies the SQL password to the SQL server system

Web InfraStructure: Apache

itmapache_tec_config_evtsvr.sh CREATE “new_rule_base path rule_base_activation”

itmapache_tec_config_evtsvr.sh CREATE new_rule_base path rule_base_activation

Web Infrastructure: WebSphere Application Server

WebSphere Event TasksConfigure_Event_Server

WebSphere Application Server Utility TasksSend_WebSphere_Discovery_Events_to_TBSM

Web Infrastructure: Microsoft IIS

itmiis_tec_config_evtsvr.sh CREATE new_rule_base path rule_base_activation

./itmiis_tbsm_discovery.sh

Web Infrastructure: iPlanet

WebLogic Event Tasks icon.WebLogic_Configure_TEC

./itmiplanet_tbsm_discovery

Web Infrastructure: WebLogic

WebLogic Event Tasks: WebLogic_Configure_TEC

WebLogic Server Tasks:WebLogic_TBSM_Discovery

Application: SAP mySAP Configuration TasksConfigure Event Server

mySAP Configuration TasksSynchronize mySAP Objects on TBSM

Application: Siebel Siebel Event TasksSiebel_Configure_Event_Server_Job

Siebel Event TasksSiebel_TBSM_Discover_Job

Module TEC setup task TBSM disovery task


–m manufacturer Specifies the manufacturer of the software component–p product Specifies the name product of the software component–v version Specifies the version of the software component

This script uses the manufacturer, product, and version to create the new object according to the database structure defined in Chapter 3, “Database structure” on page 77. From the script, the product field translates to that of the entry prodname within the IBM Tivoli Business Systems Manager database.

We issue the command in Example 7-7 on the database server. During the generation, the database is disabled, so you should stop all data sources before running this command. Afterward, you can restart all data sources.

Example 7-7 gemgenprod command

gemgenprod -S ibmtiv5 -U sa -P XXXX -m “SAM” -P “generictest” -v “1.0”

After running this command, we run a SQL query to see what has been generated in the IBM Tivoli Business Systems Manager database. The SQL Query Analyzer displays the GEMLookupCID table, which contains information about GEM-based classes in IBM Tivoli Business Systems Manager. The manufacturer, product, and version columns contain unique information that identify the component. It is shown in Figure 7-11.

Figure 7-11 GEMLookupCID content

We can see from the output in Figure 7-11 that a new entry has been created in the database. Apart from this, a new set of tables and stored procedure were created with the name of G02J.


To activate the database changes, you must restart several affected IBM Tivoli Business Systems Manager services:

� Agent listener� Propagation Agent dispatcher� Console server

Finally, associate an icon to this new class using the gemimageimport command. There are two types, the large icon (32 by 32 pixels) and the small icon (16 by 16 pixels). The icon must be in the JPG or BMP format, and we import both as shown in Example 7-8.

Example 7-8 Importing image icon

gemimageimport.sh -S ibmtiv5 -U sa -P XXXX -p generictest -v 1.0 -l -i gentest_l.jpg gemimageimport.sh -S ibmtiv5 -U sa -P XXXX -p generictest -v 1.0 -s -i gentest_s.jpg

Now modify a rule within TEC to send these events to IBM Tivoli Business Systems Manager. We use ITM to generate the events into TEC and write a new rule to forward these events to IBM Tivoli Business Systems Manager.

Example 7-9 TEC to TBSM rule

/*==========================================*//* Rule to submit to TBSM *//*==========================================*/rule: tbsm_submit_generic: ( description: 'do nothing except invoke IHSTTTEC which will’,

event: _event of_class _class where [

hostname: _hostname,source: equals 'TMNT',origin: _origin,modelname: _modelname,severity: _severity,msg: _msg

],

reception_action: ( exec_program(_event, '../../TDS/EventService/ihstttec','-b "%s" -i "%s" -q "%s" -p "%s" -s "%s" -o "%s" -t "%s" -m "%s"',['generictest;1.0',_hostname, _origin, _modelname, _severity, '22', 'EXCEPTION', _msg], 'YES')


) ).

This rule specifies that all events that arrive to TEC with the source equal to “TMNT” (the standard source for an IBM Tivoli Monitoring event) will invoke the exit ihstttec to send the state change information to IBM Tivoli Business Systems Manager through event enablement. The full syntax of ihstttec can be found in the Appendix of the IBM Tivoli Business Systems Manager: Administrator’s Guide, GC32-0799. The -b parameter must match that of the product name and version as created by the gemgenprod script in order to be processed correctly by IBM Tivoli Business Systems Manager.

Now we will generate an event to see what happens. First, it is received by TEC in a wtdumprl output, as shown in Example 7-10.

Example 7-10 Output from wtdumprl

1~306~65537~1038944076(Dec 03 13:34:36 2002)### EVENT ###TMW_HighProcesses;modelname="TMW_Processor";profilename="ITM511Profile#ibmtiv9-region";event_key="Processor=0;";eventid="1872068515";severity="CRITICAL";hostname="ibmtiv9";adapter_host="ibmtiv9";origin="9.3.4.59";highprocesses= 2.0000;idprocess= 3164.0000;percentprocessortime= 48.0000;process="[2]CMD";processor="0";date="12/03/2002 13:34:24 ";msg="High CPU Usage, High CPU Usage User Priv, and High CPU Usage Process are exceeded on the processor 0.";END

### END EVENT ###PROCESSED

The wtdumptr command runs the task shown in Example 7-11.

Example 7-11 Output from wtdumptr

TASK;server_handle=1;date_reception=1038944076; # Dec 03 13:34:36 2002event_handle=1;task_number=140;command='../../TDS/EventService/ihstttec -b "generictest;1.0" -i "ibmtiv9" -q "9.3.4.59" -p "TMW_Processor" -s "CRITICAL" -o "22" -t "EXCEPTION" -m "High CPU Usage, High CPU Usage User Priv, and High CPU Usage Process are exceeded on the processor 0."';start_time=1038944076; # Dec 03 13:34:36 2002status=SUCCESS;exit_status=0;message=[ ];


When the first event completes, an object is created under the hierarchy of Enterprise - Network Region - Network Location - host, as shown in Figure 7-12.

Figure 7-12 New generic test object created


Looking at the properties display, you see both the event that caused the object’s creation and the Red state, as shown in Figure 7-13.

Figure 7-13 Properties window

You can see in the top right-hand field that the Type is generictest 1.0.

When this condition no longer exists the IBM Tivoli Monitoring engine sends the TMW_Clearing event to TEC, which sets the event to HARMLESS. This in turn is forwarded to IBM Tivoli Business Systems Manager.

7.5 Defining a component from DM monitorsIn this section, we show another simple component that is based on the Tivoli Distributed Monitoring (DM) monitors; in this case, Tivoli Distributed Monitoring Classic 3.7 in the Tivoli Management Framework environment.


To implement the IBM Tivoli Business Systems Manager object that relates to a Tivoli Distributed Monitoring profile, the following steps have to be executed:

1. Create a monitoring profile with a Classic DM monitor (SentryProfiles) using any monitors that conform to the DM monitors. Define an action to send the result to TEC for each level of monitoring that you want, with at least one for the error condition and one for the resolution that will inform you that the change of status occurred. For example, we send one for the CRITICAL status and one for the HARMLESS status.

More information about this can be found in the Tivoli Distributed Monitoring manual Tivoli Distributed Monitoring Version 3.7 Users Guide, GC31-8382.

2. Define the monitoring collection to IBM Tivoli Business Systems Manager. For IBM Tivoli Business Systems Manager to recognize a forwarded DM event, you must define its underlying data structure. The gemdmmap command facilitates the association of a DM profile with an IBM Tivoli Business Systems Manager object class. This command must be executed on the database server machine. It also creates the software component if it has not been created. Our command to create the DM profile association is

gemdmmap.sh -S ibmtiv5 -U sa -P XXXX -i -D ‘ClassicSentryProfile’ -m ‘DM’ -p ‘ClassicSentryProfile ‘ -v ‘1.0’

The command associates all events from a profile called ClassicSentryProfile to a component in IBM Tivoli Business Systems Manager. After this command completes the association appears as shown in Example 7-12.

Example 7-12 List of associated DM profiles

C:\>gemdmmap -S ibmtiv5 -U sa -P XXXX -lgemsp_list_DMtoCID:DM profile name Manufacturer Product Version DM only-------------------- ------------ -------------------- ------- -------ClassicSentryProfile DM ClassicSentryProfile 1.0 yes

To activate the database changes, you must restart several affected IBM Tivoli Business Systems Manager services:

– Agent Listener– Propagation Agent dispatcher– Console Server

3. Create and associate icons to the application. The image file can be a BMP file or a JPG file. We use the gemimageimport command to associate an icon with a software component. The syntax of the gemimageimport is:

gemimageimport.sh -p product -v version [-l | -s] -i image_filename


4. Create a standard TEC rule for event forwarding. This was done by running the ihsttec.sh script as shown in 7.2.3, “Updating the TEC event classes and rules” on page 217.

Now we are ready to examine the event flow from TEC to IBM Tivoli Business Systems Manager.

Figure 7-14 Flow diagram

The flow of an 3.7 DM Classic event from the endpoint to IBM Tivoli Business Systems Manager looks something like this:

Note: You must modify the rule for step 5 if the name of the profile is not the one provided when the ihsttec.sh script is run. Open the ihstdmon.rls file and change the sub source condition (in our case it is ClassicSentryProfile) to another profile. Recompile and reload the rulebase if you do this.


1. The monitor generates an alert because a threshold on the endpoint has been breached. The monitor is enabled, so an alert will be sent to TEC.

A FATAL event is received from ibmtiv8, as shown in Figure 7-15. The icon shaped like a curved arrow shows that something has been executed against this event.

Figure 7-15 Event Viewer: Group All - All events


2. IBM Tivoli Business Systems Manager processes this event and writes any updates to the objects’ changes to the IBM Tivoli Business Systems Manager database.

An alert for this event is propagated up to show that there is a problem with the ibmtiv8, as shown in Figure 7-16.

Figure 7-16 All Resources - Descendents window

If you take ownership of the event by right-clicking on ClassicSentryProfile 1.0:ibmtiv8 and selecting Take Ownership, the ibmtiv8 - Note Editor shown in Figure 7-17 on page 240 opens.


Figure 7-17 Note editor for closing an event

3. If an IBM Tivoli Business Systems Manager administrator acts upon an event from the console (such as either an ACK or a CLOSE), this invokes a trigger within the IBM Tivoli Business Systems Manager database. This calls a routine that causes an event to be generated using postemsg and sent to TEC to advise the change in status of this event.

Example 7-13 wtdumprl

1~5~1~1038418574(Nov 27 11:36:14 2002)### EVENT ###TBSM_setemsg_status_event;source=TBSM;msg='TBSM ownership';o_server_handle=1;o_event_handle=1;o_date_reception=1038418015;o_cla


ss=w2k_MemAvailBytes;new_admin='TBSM:administrator';new_status=ACK;origin=9.3.4.55;END


1~6~2~1038418574(Nov 27 11:36:14 2002)### EVENT ###TBSM_setemsg_status_event;source=TBSM;msg='TBSM ownership';o_server_handle=1;o_event_handle=1;o_date_reception=1038418015;o_class=w2k_MemAvailBytes;new_admin='TBSM:administrator';new_status=CLOSED;origin=9.3.4.55;END


This is an example of closing the event from IBM Tivoli Business Systems Manager console. An ACK event is sent to TEC prior to the actual closing event, due to a notice creation procedure within the IBM Tivoli Business Systems Manager that creates this ACK event.

4. TEC receives this ACK event, which should have the class called TBSM_setemsg_status_event. When this event is parsed it will invoke the tbsmstatus.rls rule set, which will update the corresponding TEC status of this event. This set of rules also will drop the change-of-status event as sent by IBM Tivoli Business Systems Manager so that it is not reflected by the TEC console. You can see the rule trace in Example 7-14.

Example 7-14 rules.trace

115]=> rule set tbsmstatus[116] -> rule tbsm_setemsg_status_rule

event : 0x183fda8 of_class TBSM_setemsg_status_event[117] call condition[118] call o_class : _653 [119] exit o_class : w2k_MemAvailBytes[120] call o_date_reception : _1195 [121] exit o_date_reception : 0x3de5005f[122] call o_server_handle : _1737 [123] exit o_server_handle : 1[124] call o_event_handle : _2279 [125] exit o_event_handle : 1[126] call new_status : _2821 [127] exit new_status : CLOSED[128] call new_admin : _3363 [129] exit new_admin : 'TBSM:administrator'[130] exit condition[131] call reception_action action0[132] call drop_received_event


[133] exit drop_received_event[134] call first_instance(event : _4741 of_class w2k_MemAvailBytes where [date_reception : equals 0x3de5005f,server_handle : equals 1,event_handle : equals 1])[135] exit first_instance(event : 0x1491498 of_class w2k_MemAvailBytes where [date_reception : equals 0x3de5005f,server_handle : equals 1,event_handle : equals 1])[136] call set_event_status(0x1491498,CLOSED)[137] exit set_event_status(0x1491498,CLOSED)[138] call set_event_administrator(0x1491498,'TBSM:administrator')[139] exit set_event_administrator(0x1491498,'TBSM:administrator')[140] call commit_set[141] exit commit_set[142] exit reception_action action0

We can see the dropping of the received event [132] and the closure of the event [136-137]. This event now is cleared from the TEC console and this status also is reflected on the IBM Tivoli Business Systems Manager console.

7.6 TroubleshootingIf something goes wrong and the object is not shown at the IBM Tivoli Business Systems Manager console, we have to analyze the source of the failure.

1. First check whether the conditions have been met to cause an alert at the endpoints where the monitors have been distributed. For DM classic we use wlseng -l <enpoint_name> and for IBM Tivoli Monitoring or DM advanced edition, we use wdmlseng -e <endpoint_name> -verbose.

2. If these monitors fire correctly and the network communications within the Tivoli Management Region are working, the next step for this event is TEC.

3. When TEC receives a recognized event it is parsed by the rules engine. The rule that will parse and act upon classic DM events and send to IBM Tivoli Business Systems Manager is ihstdmon.rls.

4. The wtdumprl command is used to display all received events and their disposition whether they are processed or getting parsing failed status. When a parsing is failed, it means that either the class is not defined or there is an unknown slot (field) or an unparsable slot. The result of wtdumprl command is shown in Example 7-15 on page 243. The event is succesfully received.

Note: While setting up the monitors we also send a message to the Tivoli notice board to help troubleshoot the classes if they are not defined correctly within TEC. When everything is working, this can be disabled.


Example 7-15 Result of wtdumprl

1~1429~65537~1038357634(Nov 26 18:40:34 2002)### EVENT ###w2k_MemAvailBytes;source='SENTRY';sub_source='ClassicSentryProfile';severity='FATAL';origin='9.3.4.58';sub_origin='ibmtiv8';hostname='ibmtiv8';adapter_host='ibmtiv8';distrib_admin='ibmtiv8';response_level='normal';probe='AvailBytes';probe_arg='';tmr='1345392748';dispatcher='2';prev_value='6.80362e+008';value='6.79887e+008';effective_value='6.79887e+008';collection='w2k_Memory';info='';monitor='Available Bytes';units='(bytes)';relation='(default result)';relation_delta=' no change';msg='Distributed Monitoring ClassicSentryProfile/Available Bytes on host ibmtiv8 11/26/02 18:39:39 Central Standard Time

Status: >>> normal <<<

Available Bytes () no change (default result) (Previous: 6.80362e+008 (bytes) Current: 6.79887e+008 Effective: 6.79887e+008)';END


5. The wtdumptr command is used to display the completion of the action invoked from the TEC rules for an event. For example, the completion code of invoking the event enablement exits. It can be seen from Example 7-16 that the rule is sucessfully processed from the wtdumptr command.

Example 7-16 Result of wtdumptr

TASK;server_handle=1;


date_reception=1038357634; # Nov 26 18:40:34 2002event_handle=1;task_number=1;command='../../TDS/EventService/ihstztec ';start_time=1038357634; # Nov 26 18:40:34 2002status=SUCCESS;exit_status=0;message=[ ];

6. If the received event matches the profile of an event that has been slated to send to IBM Tivoli Business Systems Manager (in our case it was the ClassicSentryProfile subsource), a TEC exit ihstztec is invoked. This exit also is invoked when there is a change of status to this event to ACK or CLOSE. Again, we confirm this from the rule trace shown in Example 7-17.

Example 7-17 rules.trace output

[1]=> rule set tbsmstatus[2]=> rule set interapp[3]=> rule set ihstdmon[4] -> rule ihstdmon_ClassicSentryProfile

event : 0x14cab38 of_class TEC_Start[5] call condition[6] call sub_source : _621 [7] exit sub_source : ''[8] call sub_source : '' equals ClassicSentryProfile[9] fail sub_source : '' equals ClassicSentryProfile[10] fail condition[11]=> rule set tbsmstatus[12]=> rule set interapp[13]=> rule set ihstdmon[14] -> rule ihstdmon_ClassicSentryProfile

event : 0x183fda8 of_class w2k_MemAvailBytes[15] call condition[16] call sub_source : _621 [17] exit sub_source : ClassicSentryProfile[18] call sub_source : ClassicSentryProfile equals ClassicSentryProfile[19] exit sub_source : ClassicSentryProfile equals ClassicSentryProfile[20] exit condition[21] call reception_action action0[22] call exec_program(0x183fda8,'../../TDS/EventService/ihstztec','',[],YES)[23] exit exec_program(0x183fda8,'../../TDS/EventService/ihstztec','',[],YES)[24] exit reception_action action0[25]=> rule set tbsmstatus[26]=> rule set interapp


[27]=> rule set ihstdmon[28]=> rule set tbsmstatus[29]=> rule set interapp[30]=> rule set ihstdmon[31] -> rule ihstdmon_change_ClassicSentryProfile

event : 0x183fda8 of_class w2k_MemAvailBytes[32] call condition[33] call sub_source : _631 [34] exit sub_source : ClassicSentryProfile[35] call sub_source : ClassicSentryProfile equals ClassicSentryProfile[36] exit sub_source : ClassicSentryProfile equals ClassicSentryProfile[37] call slot status set_to : ACK within [ACK,RESPONSE,CLOSED][38] exit slot status set_to : ACK within [ACK,RESPONSE,CLOSED][39] exit condition[40] call action action0[41] call exec_program(0x183fda8,'../../TDS/EventService/ihstztec','-n',[],YES)[42] exit exec_program(0x183fda8,'../../TDS/EventService/ihstztec','-n',[],YES)[43] exit action action0

If you examine the trace of the rules you will see from [1] to [10] an event relating to the starting of the TEC server. This is parsed by the ihstdmon rule but fails because the condition where the ClassicSentryProfile subsource fails. The next event we can see parsed, represented by [14] to [24], shows that we have an event that has met the subsource:ClassicSentryProfile.

7. The ihstztec exit when invoked (as seen in Example 7-17 on page 244 [21] to [24] ) formats the data and passes it onto the Tivloi BSM Event Enablement service. This in turn sends this event to the agent listener. We also can see from lines [30] to [43] that we have sent an ACK (acknowledgement from the TEC console) and this state change is also sent to IBM Tivoli Business Systems Manager.

We have seen the usage of wtdumprl, wtdumptr, and the tracing of the rule base that has been used to show the data flow from within TEC. The most common problem you will see from the wtdumprl is that of an unprocessed event. If this is the case check the classes (BAROC files) whose addition may have been missed. The most useful trace is that of the rule base, as you may have made a syntax error with the customization of a rule.

The event enablement engine itself also keeps logfiles. Four log files, two for the task server and two for event enablement, are available in the $BINDIR/TDS/EventService/log directory. You need to start tracing for event


enablement to get meaningful information into the log file. Run the trace using the tserver ee_utility command. To start tracing, issue the command:

$BINDIR/TDS/EventService/bin/tserver ee_utility -t

To format these log files, we use the command ihszfmt, which is located in subdirectory $BINDIR/TDS/EventService/bin.

The next part of the data flow we examine is that of the agent listener. Verify that the agent listener is connected to the event enablement with the command gemeeconfig as shown in Example 7-4 on page 225.

The next point to check is the agent listener log file. The amount of information logged in the log file depends on the loglevel, which can be set in the Windows registry. When the loglevel is set to 0, everything will be traced. The default loglevel setting is 2. The file is named AL + Timestamp of creation, so the file AL200211141427.log is the agent listener log that is created on the 14 November 2002, at 14:27. This logfile, shown in Example 7-18, matches the event that is shown in Example 7-10 on page 233.

Example 7-18 AL200211141427.log

2002/12/03 13:36:50|593|DBG|0|AL|774|B:\ole\asiruleengine\ASIRuleEngineObj.cpp|307|GetNextEvent: got message "( assert ( APMGenericEvent 99999 "IBMTIV5" "ASIEnqueueGemMsg" 50003 "12/03/2002 13:36:50" 1038944210 2000 1004 asimcsAvailability asimpMedium 1 -1 "generictest;1.0" "ibmtiv9" "" "EXCEPTION" "TMW_Processor" "" "" "CRITICAL" "" "" "High CPU Usage, High CPU Usage User Priv, and High CPU Usage Process are exceeded on the processor 0." "ibmtiv9" 22 "ibmtiv9" "" "ibmtiv9" "" "" "" "" 1038944076 "1" "1" "1038944076" "TMW_HighProcesses" "OPEN" "" 0 ) )"2002/12/03 13:36:50|625|DBG|0|AL|774|B:\ole\asiruleengine\ASIRuleEngineObj.cpp|268|GetNextEvent: waiting for message2002/12/03 13:36:50|625|DBG|0|AL|774|B:\ole\asiruleengine\ASIRuleEngineObj.cpp|307|GetNextEvent: got message "(run)"2002/12/03 13:36:50|671|DBG|0|AL|774|B:\asidb\include\ASIDB\ASISQLDBC.ado.cpp|805|adCmdStoredProc(4) - { ? = call gemsp_processAPMGenericMsg(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) }( /*@RETURN_VALUE=<empty>(R)*/@tbsmclass=N'generictest;1.0'/*(I)*/, @instanceid=N'ibmtiv9'/*(I)*/, @instancename=N''/*(I)*/, @probetype=N'EXCEPTION'/*(I)*/, @probeid=N'TMW_Processor'/*(I)*/, @probename=N''/*(I)*/, @probeargs=N''/*(I)*/, @severity=N'CRITICAL'/*(I)*/, @probevalue=N''/*(I)*/, @probecondition=N''/*(I)*/, @msg=N'High CPU Usage, High CPU Usage User Priv, and High CPU Usage Process are exceeded on the processor 0.'/*(I)*/, @eehost=N'ibmtiv9'/*(I)*/, @hostos=22/*(I)*/, @tcphostname=N'ibmtiv9'/*(I)*/, @tmr=N''/*(I)*/,


@hostnameslot=N'ibmtiv9'/*(I)*/, @data1=N''/*(I)*/, @data2=N''/*(I)*/, @data3=N''/*(I)*/, @data4=N''/*(I)*/, @eventtime=1038944076/*(I)*/, @eventhandle=N'1'/*(I)*/, @serverhandle=N'1'/*(I)*/, @datereception=N'1038944076'/*(I)*/, @tecclass=N'TMW_HighProcesses'/*(I)*/, @status=N'OPEN'/*(I)*/, @administrator=N''/*(I)*/, @isItStatus=0/*(I)*/)

We can see that it is received by the agent listener and is being processed. For greater detail we can lower the log level and see operations such as object creation. Additional information about debugging the agent listener can be found in IBM Tivoli Business Systems Manager: Diagnosis Guide, SC23-4840.


Chapter 8. IBM Tivoli Monitoring integration

In this section we discuss integrating IBM Tivoli Business Systems Manager with IBM Tivoli Monitoring. Integration enables IBM Tivoli Business Systems Manager to view the resources monitored by IBM Tivoli Monitoring 5.1.1. The integration between IBM Tivoli Monitoring 5.1.1 and IBM Tivoli Business Systems Manager provides a complete availability solution that can be viewed at the business level.

The discussion consists of:

� 8.1, “IBM Tivoli Monitoring integration” on page 250

� 8.2, “Adapter installation and configuration” on page 252

� 8.3, “Using the TBSM adapter” on page 261

� 8.4, “Tracing an event to the Common Listener” on page 268

8


8.1 IBM Tivoli Monitoring integrationIBM Tivoli Monitoring 5.1.1 feeds the availability status of various resources to IBM Tivoli Business Systems Manager. These configured business views present data critical for managing business objects. With these views, IBM Tivoli Business Systems Manager can assess the business impact on the availability status of a resource.

The Tivoli Management Environment® framework provides a means to manage distributed resources through centralized control and configuration. IBM Tivoli Monitoring 5.1.1 is the backbone for availability monitoring across operating systems and applications and integrates tightly into the framework.

IBM Tivoli Monitoring 5.1.1 maintains many of the advances of IBM Tivoli Monitoring 5.1, such as integration with the Common Information Model (CIM) and Windows Management Instrumentation (WMI) to manage event and performance data closer to the source.

IBM Tivoli Monitoring 5.1.1 uses Java-based technology to integrate with industry-standard information models, correlating event data at the server level with event data from other monitors on the server. It can process the information intelligently to recognize critical situations by performing functions locally at the managed resource—functions such as local event analysis, event correlation, event aggregation, event management, and event logging. Overall, this reduces the number of events at the central display.

IBM Tivoli Monitoring 5.1.1 continues the approach of building monitors based on resource models. These in turn are based on the CIM, which provides industry standards for vendors and application developers who wish to instrument their software.

The software level and environment that we use is described in 1.5, “Lab environment” on page 22.

The integration between IBM Tivoli Monitoring 5.1.1 and IBM Tivoli Business Systems Manager is achieved by:

� Installing and configuring the Common Listener service on the IBM Tivoli Business Systems Manager Management Server.

� Installing and configuring the IBM Tivoli Business Systems Manager Adapter on each of the gateways whose attached endpoints are to be monitored.

The installation and the configuring of the Common Listener is covered in 6.4, “Console and propagation server installation” on page 190. In this chapter we will concentrate on the installation and the configuring of the adapter.


By integrating IBM Tivoli Business Systems Manager with IBM Tivoli Monitoring 5.1.1, the following functions are performed:

� IBM Tivoli Business Systems Manager Adapter performs endpoint registration and discovery when the wdmdiscovery command is issued on the gateway.

� IBM Tivoli Monitoring 5.1.1 events are sent directly to IBM Tivoli Business Systems Manager through the IBM Tivoli Business Systems Manager Adapter on the endpoint gateway.

Figure 8-1 presents the data flow as well as the processes that are involved when we enable IBM Tivoli Business Systems Manager integration.

Figure 8-1 IBM Tivoli Business Systems Manager for ITM diagram

The interface performs two functions: bulk discovery and event forwarding. Bulk discovery is performed using the wdmdiscovery command, while event forwarding is performed from an individual monitoring profile.

As shown in Figure 8-1, the adapter works as follows:

1. From a managed node or the TMR server, we can run the wdmdiscovery command to trigger the bulk or delta discovery.

2. The command queries all gateways for IBM Tivoli Business Systems Manager resources.

Chapter 8. IBM Tivoli Monitoring integration 251

3. From each of the endpoints, the monitoring profile (Tmw2kProfiles) performs the monitoring action. One of the indications might send an event to IBM Tivoli Business Systems Manager. If so, when the endpoint generates an exception based on its resource model, the endpoint will indicate that to the gateway.

4. The IBM Tivoli Business Systems Manager adapter running on the gateway will forward the bulk discovery, delta discovery, or endpoint event to the IBM Tivoli Business Systems Manager Common Listener process.

In 8.2.4, “Configuring the IBM Tivoli Monitoring for 5.1.1 TBSM Adapter” on page 259, we will discuss in greater detail the configuration of the IBM Tivoli Business Systems Manager Adapter running on the gateway.

8.2 Adapter installation and configurationIn addition to the prerequisite in the TMR, we install the IBM Java Runtime Environment Version 1.3.0, which is shipped with IBM Tivoli Monitoring 5.1.1, onto the gateway. This is not installed by default and is different from the Java Client Framework 3.7/3.7.1 that is installed on this TMR.

8.2.1 Installing JRE 1.3.0With all new installations of a product please ensure that you have a clean backup of the odb database, on which you have run a wchkdb -u.

Ensure that you have the image of the IBM Tivoli Monitoring Tools 5.1.1 CD. On this disk you will find a directory called jre130.image, with which you can install the Java onto the gateway. It is installed in the same way most Tivoli Framework products are installed: either via the GUI or the CLI. In our example we will use the GUI to install it.

1. From the Tivoli Desktop, select Desktop -> Install -> Install Product to open the Install Product dialog shown in Figure 8-2, “Installing JRE 1.3.0 via GUI” on page 253.


Figure 8-2 Installing JRE 1.3.0 via GUI

2. Click Select Media and point to the path of jre130.image.

3. Click Set Media & Close.

4. Select IBM Tivoli Monitoring, Version 5.1.0 - JRE 1.3.0

5. Select the Clients to Install On, which shows the gateways in your environment that have monitored endpoints. In our setting, we only have one gateway. Click Install & Close.

6. Once the dependency checks are completed, click Continue Install.

If the installation is reported successful, JRE Version 1.3.0 for IBM Tivoli Monitoring 5.1 installation is complete. Typically the JRE is installed in $BINDIR/JRE/1.3.0. We will need this information for the next step.

Before installing the IBM Tivoli Monitoring 5.1 TBSM Adapter, add $BINDIR/JRE/1.3.0/jre/bin and $BINDIR/JRE/1.3.0/jre/bin/classic to the PATH environment variable in both UNIX and Windows systems. For Windows systems, open Control Panel -> System and select the Advanced tab. Click on the Environment Variables. From here we edit the path in System variables to include the path to the JRE. Without it, a path error would appear warning that it could not find a jvm.dll file.


After installing the JRE 1.3.0 we can now install the IBM Tivoli Business Systems Manager adapter.

8.2.2 Installing the TBSM adapter for ITMThe following procedure describes the TBSM Adapter installation.

1. From the Tivoli Desktop, select Desktop -> Install -> Install Product.

2. Click the Select Media button and go to the path where the IBM Tivoli Monitoring CD is located.

Note: We also noticed that even though we had changed this and it was reflected in the DOS path variable, Windows did not use the correct path until we rebooted.


3. The Install Product dialog shows the products that can be installed. Select IBM Tivoli Monitoring TBSM Adapter Version 5.1.1, as shown in Figure 8-3.

Figure 8-3 Install Product window, ITM adapter for TBSM

4. Click Install Options and type the path where JRE is installed into the dialog box, as shown in Figure 8-4 on page 256.


Figure 8-4 Install Options window

5. Click Set, then Close.

6. Click Install & Close in the Install Product dialog box.

7. After the dependency checks are performed, click Continue Install. After the installation of IBM Tivoli Monitoring TBSM Adapter Version 5.1.1 is complete, click on Close.

If you mistype the JRE path in the Install Options dialog, you can correct it using the wdmconfig command explained in 8.2.4, “Configuring the IBM Tivoli Monitoring for 5.1.1 TBSM Adapter” on page 259.

8.2.3 TBSM adapter processesThe TBSM adapter uses two main processes:

� tmnt_tbsm_eng� tmnt_tbsm_wrapper

The tmnt_tbsm_eng process is the main parent process for the adapter. This process interacts with both the operating system and the Tivoli framework.

Note: HPUX is not supported as one of the operating systems that can serve as a gateway for this process. Architecturally, if you have an alternative gateway to which endpoints can log in if the primary is unavailable, this IBM Tivoli Business Systems Manager adapter should be installed onto it.


The tmnt_tbsm_wrapper is a child process of tmnt_tbsm_eng. This process utilizes the JVM to format and package the data and to communicate this with the IBM Tivoli Business Systems Manager Common Listener.

Example 8-1 includes a listing of the modules used by these processes. To create it, we used a product called listdlls.exe, which is freely available for download from http://www.sysinternals.com.

Example 8-1 Process listing

tmnt_tbsm_eng.e pid: 2852Command line: tmnt_tbsm_eng.exeBase Size Version Path 0x00400000 0x26000 C:\Tivoli\bin\w32-ix86\TME\Tmw2k\tmnt_tbsm_eng.exe 0x77f80000 0x7b000 5.00.2195.5400 C:\WINNT\System32\ntdll.dll 0x78000000 0x46000 6.01.9359.0000 C:\WINNT\system32\MSVCRT.dll 0x77e80000 0xb6000 5.00.2195.5400 C:\WINNT\system32\KERNEL32.dll 0x22000000 0xdc000 C:\Tivoli\bin\w32-ix86\bin\libas60.dll 0x77db0000 0x5d000 5.00.2195.5385 C:\WINNT\system32\ADVAPI32.dll 0x77d30000 0x71000 5.00.2195.5419 C:\WINNT\system32\RPCRT4.DLL 0x780a0000 0x12000 6.01.8637.0000 C:\WINNT\System32\MSVCIRT.dll 0x10000000 0x13000 C:\Tivoli\bin\w32-ix86\bin\libg++.dll 0x20000000 0x46000 C:\Tivoli\bin\w32-ix86\bin\libtas60.dll 0x1e000000 0x8000 C:\Tivoli\bin\w32-ix86\bin\libthreads60.dll 0x1c000000 0x6f000 C:\Tivoli\bin\w32-ix86\bin\libtmf60.dll 0x75050000 0x8000 5.00.2195.4874 C:\WINNT\System32\WSOCK32.dll 0x75030000 0x13000 5.00.2195.4874 C:\WINNT\System32\WS2_32.DLL 0x75020000 0x8000 5.00.2134.0001 C:\WINNT\System32\WS2HELP.DLL 0x77e10000 0x65000 5.00.2195.4314 C:\WINNT\system32\USER32.dll 0x77f40000 0x3c000 5.00.2195.5252 C:\WINNT\system32\GDI32.DLL 0x1f000000 0x90000 C:\Tivoli\bin\w32-ix86\bin\libms60.dll 0x00230000 0x3b000 C:\Tivoli\bin\w32-ix86\bin\libtmw2ksrv.dll 0x77820000 0x7000 5.00.2134.0001 C:\WINNT\system32\VERSION.dll 0x759b0000 0x6000 5.00.2134.0001 C:\WINNT\system32\LZ32.DLL 0x00270000 0x4c000 C:\Tivoli\bin\w32-ix86\bin\libdmml.dll 0x30000000 0x21000 C:\Tivoli\bin\w32-ix86\bin\libmdist260.dll 0x782c0000 0xc000 5.00.2195.4874 C:\WINNT\System32\rnr20.dll 0x77980000 0x24000 5.00.2195.5354 C:\WINNT\System32\DNSAPI.DLL 0x77340000 0x13000 5.00.2195.0002 C:\WINNT\System32\iphlpapi.dll 0x77520000 0x5000 5.00.2134.0001 C:\WINNT\System32\ICMP.DLL 0x77320000 0x17000 5.00.2181.0001 C:\WINNT\System32\MPRAPI.DLL 0x75150000 0x10000 5.00.2195.4827 C:\WINNT\System32\SAMLIB.DLL 0x75170000 0x4f000 5.00.2195.5427 C:\WINNT\System32\NETAPI32.DLL 0x77be0000 0xf000 5.00.2195.4587 C:\WINNT\System32\SECUR32.DLL 0x751c0000 0x6000 5.00.2134.0001 C:\WINNT\System32\NETRAP.DLL 0x77950000 0x2a000 5.00.2195.5400 C:\WINNT\system32\WLDAP32.DLL 0x77a50000 0xf5000 5.00.2195.5400 C:\WINNT\system32\OLE32.DLL 0x779b0000 0x9b000 2.40.4518.0000 C:\WINNT\system32\OLEAUT32.DLL 0x773b0000 0x2e000 5.00.2195.5312 C:\WINNT\System32\ACTIVEDS.DLL 0x77380000 0x22000 5.00.2195.5400 C:\WINNT\System32\ADSLDPC.DLL 0x77830000 0xe000 5.00.2168.0001 C:\WINNT\System32\RTUTILS.DLL 0x77880000 0x8d000 5.00.2195.5400 C:\WINNT\System32\SETUPAPI.DLL 0x77c10000 0x5e000 5.00.2195.5425 C:\WINNT\System32\USERENV.DLL 0x774e0000 0x32000 5.00.2195.5438 C:\WINNT\System32\RASAPI32.DLL 0x774c0000 0x11000 5.00.2195.5292 C:\WINNT\System32\RASMAN.DLL 0x77530000 0x22000 5.00.2182.0001 C:\WINNT\system32\TAPI32.DLL 0x716f0000 0x8a000 5.81.4807.2300 C:\WINNT\system32\COMCTL32.DLL 0x70bd0000 0x4c000 5.50.4807.2300 C:\WINNT\system32\SHLWAPI.DLL 0x77360000 0x19000 5.00.2195.4874 C:\WINNT\System32\DHCPCSVC.DLL 0x777e0000 0x8000 5.00.2160.0001 C:\WINNT\System32\winrnr.dll 0x74fd0000 0x1d000 5.00.2195.4874 C:\WINNT\system32\msafd.dll 0x75010000 0x7000 5.00.2195.4874 C:\WINNT\System32\wshTCP/IP.dll------------------------------------------------------------------------------tmnt_tbsm_wrapp pid: 3392


Command line: C:\Tivoli\bin\w32-ix86\TME\Tmw2k\tmnt_tbsm_wrapperBase Size Version Path 0x00400000 0xd000 C:\Tivoli\bin\w32-ix86\TME\Tmw2k\tmnt_tbsm_wrapper.exe 0x77f80000 0x7b000 5.00.2195.5400 C:\WINNT\System32\ntdll.dll 0x78000000 0x46000 6.01.9359.0000 C:\WINNT\system32\MSVCRT.dll 0x77e80000 0xb6000 5.00.2195.5400 C:\WINNT\system32\KERNEL32.dll 0x75050000 0x8000 5.00.2195.4874 C:\WINNT\System32\WSOCK32.dll 0x75030000 0x13000 5.00.2195.4874 C:\WINNT\System32\WS2_32.DLL 0x77db0000 0x5d000 5.00.2195.5385 C:\WINNT\system32\ADVAPI32.DLL 0x77d30000 0x71000 5.00.2195.5419 C:\WINNT\system32\RPCRT4.DLL 0x75020000 0x8000 5.00.2134.0001 C:\WINNT\System32\WS2HELP.DLL 0x714f0000 0xf4000 c:\Tivoli/bin/w32-ix86/JRE/1.3.0\jre\bin\classic\jvm.dll 0x780a0000 0x12000 6.01.8637.0000 C:\WINNT\System32\MSVCIRT.dll 0x714a0000 0x5000 c:\Tivoli/bin/w32-ix86/JRE/1.3.0\jre\bin\xhpi.dll 0x70740000 0xa000 c:\Tivoli/bin/w32-ix86/JRE/1.3.0\jre\bin\hpi.dll 0x77570000 0x30000 5.00.2161.0001 C:\WINNT\System32\WINMM.dll 0x77e10000 0x65000 5.00.2195.4314 C:\WINNT\system32\USER32.DLL 0x77f40000 0x3c000 5.00.2195.5252 C:\WINNT\system32\GDI32.DLL 0x707c0000 0x2c000 c:\Tivoli/bin/w32-ix86/JRE/1.3.0\jre\bin\java.dll 0x714c0000 0x10000 c:\Tivoli/bin/w32-ix86/JRE/1.3.0\jre\bin\zip.dll 0x708a0000 0x15d000 C:\Tivoli/bin/w32-ix86/JRE/1.3.0\jre\bin\jitc.dll 0x71280000 0x9000 C:\Tivoli/bin/w32-ix86/JRE/1.3.0\jre\bin\net.dll 0x74fd0000 0x1d000 5.00.2195.4874 C:\WINNT\system32\msafd.dll 0x75010000 0x7000 5.00.2195.4874 C:\WINNT\System32\wshTCP/IP.dll 0x782c0000 0xc000 5.00.2195.4874 C:\WINNT\System32\rnr20.dll 0x77980000 0x24000 5.00.2195.5354 C:\WINNT\System32\DNSAPI.DLL 0x77340000 0x13000 5.00.2195.0002 C:\WINNT\System32\iphlpapi.dll 0x77520000 0x5000 5.00.2134.0001 C:\WINNT\System32\ICMP.DLL 0x77320000 0x17000 5.00.2181.0001 C:\WINNT\System32\MPRAPI.DLL 0x75150000 0x10000 5.00.2195.4827 C:\WINNT\System32\SAMLIB.DLL 0x75170000 0x4f000 5.00.2195.5427 C:\WINNT\System32\NETAPI32.DLL 0x77be0000 0xf000 5.00.2195.4587 C:\WINNT\System32\SECUR32.DLL 0x751c0000 0x6000 5.00.2134.0001 C:\WINNT\System32\NETRAP.DLL 0x77950000 0x2a000 5.00.2195.5400 C:\WINNT\system32\WLDAP32.DLL 0x77a50000 0xf5000 5.00.2195.5400 C:\WINNT\system32\OLE32.DLL 0x779b0000 0x9b000 2.40.4518.0000 C:\WINNT\system32\OLEAUT32.DLL 0x773b0000 0x2e000 5.00.2195.5312 C:\WINNT\System32\ACTIVEDS.DLL 0x77380000 0x22000 5.00.2195.5400 C:\WINNT\System32\ADSLDPC.DLL 0x77830000 0xe000 5.00.2168.0001 C:\WINNT\System32\RTUTILS.DLL 0x77880000 0x8d000 5.00.2195.5400 C:\WINNT\System32\SETUPAPI.DLL 0x77c10000 0x5e000 5.00.2195.5425 C:\WINNT\System32\USERENV.DLL 0x774e0000 0x32000 5.00.2195.5438 C:\WINNT\System32\RASAPI32.DLL 0x774c0000 0x11000 5.00.2195.5292 C:\WINNT\System32\RASMAN.DLL 0x77530000 0x22000 5.00.2182.0001 C:\WINNT\system32\TAPI32.DLL 0x716f0000 0x8a000 5.81.4807.2300 C:\WINNT\system32\COMCTL32.DLL 0x70bd0000 0x4c000 5.50.4807.2300 C:\WINNT\system32\SHLWAPI.DLL 0x77360000 0x19000 5.00.2195.4874 C:\WINNT\System32\DHCPCSVC.DLL 0x777e0000 0x8000 5.00.2160.0001 C:\WINNT\System32\winrnr.dll 0x279c0000 0x5000 C:\Tivoli\bin\w32-ix86\TME\Tmw2k\TBSMA\libnativelistener.dll------------------------------------------------------------------------------

These listed processes may not necessarily run continuously and can be invoked when an ITM event must be sent to IBM Tivoli Business Systems Manager. The Windows Task Manager shows them running in the background.

To stop the TBSM Adapter, you can issue wdmmn -stop -b. The processes are started when there is an event to be sent to IBM Tivoli Business Systems Manager. This is most commonly used for tracing a problem after enabling logging.


8.2.4 Configuring the IBM Tivoli Monitoring for 5.1.1 TBSM AdapterThe IBM Tivoli Monitoring 5.1.1 TBSM Adapter is configured using the wdmconfig command. The adapter has to be configured before IBM Tivoli Monitoring 5.1.1 can interact with IBM Tivoli Business Systems Manager. The following parameters must be configured for this functionality:

transport.server.mqe.port The port number that is used by the Common Listener to listen. The typical port number is 8082.

transport.server.ip.address The IP address of the IBM Tivoli Business Systems Manager server where the Common Listener service is installed.

tbsma.jre_root This parameter is set during the installation of the TBSM Adapter and normally does not have to be changed manually. However, if you want to install the adapter on a group of gateways using one instance of the install action/command, for example, you must change this parameter on any gateways in the group that have JRE installed at a different location from that supplied in the Install Options dialog.

A typical wdmconfig command issued to configure the TBSM Adapter is shown in Example 8-2.

Example 8-2 TBSM adapter wdmconfig command

wdmconfig -m all -D transport.server.mqe.port =8082 \-D transport.server.ip.address=9.3.4.53 \-D tbsm.jre_root=c:\tivoli\bin\w32-ix86\JRE\1.3.0

Many other parameters can be configured using the wdmconfig command. Configurable parameters that are related to the IBM Tivoli Business Systems Manager adapter include:

adapter.working.dir Working directory that will be used by the adapter. The default is the Tivoli Monitoring middle layer directory (DBDIR/dmml), which is recommended.

trace.filename Filename to which the trace messages from the adapter will be written. The default is dm.trc.

Note: This adapter’s default port number for communication was 6969, so this value must be changed. If this value is not set correctly when a initial discovery is performed, you will get a time-out.


adapter.trace.enable Set this to true if you want to store all trace messages regarding the operations of the adapter. The messages are stored in the file identified in trace.filename. The default is false.

transport.trace.enable Set this to true if you want to store all messages regarding the transport of adapter-acquired data to the Common Listener. The messages are stored in the file identified in trace.filename. The default is false.

adapter.trace.level If you have enabled adapter trace messages, set this to low, medium or high, according to the level of details you require. The default is low.

transport.trace.level If you have enabled adapter trace messages, set this to low, medium or high, according to the level of details you require. The default is low.

transport.mqe.usefiller Set this to true if the managed node or gateway on which the adapter is installed is running Windows NT 4.0, Service Pack 5; otherwise leave as the default value of false.

dmml.trace_size Specifies the size of the profile distribution trace in bytes. The default is 500000 bytes.

dmml.trace_level Specifies the level of the profile distribution trace from 0 (minimal) to 4 (verbose). The default is 1.

After running the wdmconfig command we can examine the settings of the adapter by looking at the .config file, which is located in the $DBDIR/dmml/.config directory. Ours is shown in Example 8-3.

Example 8-3 The .config file

adapter.type = LocalAdapteradapter.working.dir = C:/Tivoli/db/ibmtiv9.db/dmmlsoap.envelope = <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body>loggingmode.default = falseloggingmode.filename = DM.logtrace.filename = DM.trcadapter.trace.enable = falsetransport.trace.enable = falseadapter.trace.level = lowtransport.trace.level = lowadapter.xml.validation = false


transport.class.name = com.tivoli.commonlistener.transport.mqe.client.ClientTransportMQetransport.local.ip.address = 9.3.4.59transport.request.address = 9.3.4.59.DM.QM+DM.Qtransport.request.port = 6969transport.response.address = 9.3.4.59.DM.QM+DM.Qtransport.response.port = 6969transport.mqe.local.queue.store = filetransport.mqe.remote.queue.store = filetransport.mqe.usefiller = falsetransport.mqe.fileregistry = com.ibm.mqe.registry.MQeFileSessiontransport.mqe.maxchannels = 1transport.server.mqe.address = ServerQM+ServerQtransport.server.mqe.port = 8082transport.server.ip.address = 9.3.4.53heartbeat.send_events_to_tbsm = falseheartbeat.send_events_to_tec = falseheartbeat.send_events_to_notice = trueheartbeat.tec_server = not-configuredtbsma.jre_root = c:\Java13\jre

We will show some of the recommended trace parameters in 8.4, “Tracing an event to the Common Listener” on page 268.

8.3 Using the TBSM adapter The discussion consists of the following:

� 8.3.1, “Discovery process” on page 261

� 8.3.2, “Event forwarding to Tivoli Business Systems Manager” on page 264

8.3.1 Discovery processOnce the IBM Tivoli Business Systems Manager adapter is installed onto the gateway, you can run a discovery. This sends a listing and locations of endpoints that are attached to the gateway to the IBM Tivoli Business Systems Manager Common Listener. This information is entered into the IBM Tivoli Business Systems Manager database.


There are two ways to carry out a discovery:

� Bulk discovery

The wdmdiscovery command can be issued from the Tivoli desktop to carry out a bulk discovery. The adapter sends details of all systems it has in its cache to the IBM Tivoli Business Systems Manager Common Listener. The bulk discovery process creates new instances of resources, deletes old ones, and updates those that already exist. Bulk Discovery is an intensive process and should be used judiciously to minimize performance degradation, especially if you are dealing with many endpoints on a gateway.

� Delta discovery

The same wdmdiscovery command can be issued from the Tivoli desktop to carry out a delta discovery. The adapter sends details of all changes since the last discovery to the IBM Tivoli Business Systems Manager Common Listener. The delta creates, deletes, and updates resources one at a time. This is the primary method to discover new resources, as it has less impact on performance. If a large number of resources is being created, updated, or deleted, bulk discovery should be used instead of delta.

In our environment, the discovery is performed as shown in Example 8-4.

Example 8-4 The wdmdiscovery command

c:\> wdmdiscovery -m all -bProcessing ManagedNode ibmtiv9...

If you have a problem issuing the discovery, it usually will be a time-out problem caused by incorrect port settings or a network problem. (By default the adapter will allow 300 seconds for the Common Listener to respond.) We can enable a trace and look at the IBM Tivoli Business Systems Manager log files to diagnose the problem. More on this later in 8.4, “Tracing an event to the Common Listener” on page 268.

After successfully running the wdmdiscovery command, we can run the wdmmngcache command, as shown in Example 8-5, to check whether the registration completed sucessfully.

Example 8-5 The wdmmngcache command

C:\>wdmmngcache -m all -l -vProcessing ManagedNode ibmtiv9...Endpoint | HB status | TBSM statusibmtiv8 HBOff Discoveredibmtiv9 HBOff Discovered


This shows that the discovery of the endpoint with IBM Tivoli Business Systems Manager was successful. If an endpoint status does not show the TBSM status as Discovered, it will be ignored by the Common Listener whenever an event is send to IBM Tivoli Business Systems Manager from this endpoint because there is no registered object to associate this change of state with. Also, on the gateway’s $DBDIR\dmml\ directory, you will see a directory <ip-address>.DM.QM created by the wdmdiscovery process.

If we open the IBM Tivoli Business Systems Manager console we can see the discovered endpoints as shown in Figure 8-5.

Figure 8-5 IBM Tivoli Business Systems Manager console window

IBM Tivoli Business Systems Manager automatically populates the new resources on a successful discovery. The object hierarchy for the IBM Tivoli Monitoring is located as follows:

Enterprise - IP Network - Network Subnet - Network Segment - Computer - resource

This hierarchy is based on the IP address of the endpoint. The mapping of the enterprise is performed from the table CL_AutoPlacement. Our content in this table is shown in Figure 8-6.


Figure 8-6 Instrumentation mapping to enterprise

In this example we have created an enterprise called Chuy Inc. To display the desired view we can drill down the menu and see that the discovered endpoints are on Network Segment: 9.0.0.0:Segment 1. Systems Manager resource view gave the listing of the two endpoints that were discovered by the IBM Tivoli Business Systems Manager Adapter, as shown in Figure 8-5 on page 263.

Our next step is to set up IBM Tivoli Monitoring to send an event to IBM Tivoli Business Systems Manager.

8.3.2 Event forwarding to Tivoli Business Systems ManagerIBM Tivoli Monitoring 5.1.1 events on the endpoints can be forwarded to IBM Tivoli Business Systems Manager using the IBM Tivoli Monitoring 5.1.1 IBM Tivoli Business Systems Manager Adapter. Two kinds of events can be sent to IBM Tivoli Business Systems Manager: heartbeat events and IBM Tivoli Monitoring 5.1.1 events. The option to forward IBM Tivoli Monitoring 5.1.1 events to IBM Tivoli Business Systems Manager is configured in the IBM Tivoli Monitoring 5.1.1 profile before distributing the profile to the endpoints.

In our example we have created a new IBM Tivoli Monitoring Profile: ITM511Profile within an ITM511 dataless profile manager. To enable the events to be sent to IBM Tivoli Business Systems Manager we select Edit -> Properties from within the IBM Tivoli Monitoring Profile window, as shown in Figure 8-7 on page 265.


Figure 8-7 Profile Properties window

Select the Send TBSM check box and click OK. We can now create an arbitrary monitor. In our example, we monitor CPU utilization and the Processor activity.

We must designate in the individual resource model that we want these events to be forwarded to IBM Tivoli Business Systems Manager. From the IBM Tivoli Monitoring Profile window select the resource model that you wish to send to IBM Tivoli Business Systems Manager and click Edit. The Edit Resource Model window appears. Select a threshold from the list and click Indications. From here you can see whether this event will be sent to IBM Tivoli Business Systems Manager as well as TEC. This is shown in Figure 8-8 on page 266.


Figure 8-8 Indications and Actions window

Here you can select whether you want this event to be sent to IBM Tivoli Business Systems Manager by selecting the Send to TBSM checkbox.

When this profile with the appropriate settings is distributed to the endpoints and an event occurs, the endpoint invokes a send_event_to_tbsm() request to the IBM Tivoli Business Systems Manager adapter tmnt_tbsm_eng on the gateway. The IBM Tivoli Business Systems Manager adapter then forwards the event to the Common Listener on the IBM Tivoli Business Systems Manager server. The IBM Tivoli Business Systems Manager database is updated by the new event information accordingly.

In our environment, we generate a High CPU usage alert and see whether this event is reflected in the IBM Tivoli Business Systems Manager console. We can see in Example 8-6 that the conditions have been met to cause an event to be sent to the IBM Tivoli Business Systems Manager console using the wdmlseng command.

Example 8-6 Using the wdmlseng -e ibmtiv9 -verbose command

C:\>wdmlseng -e ibmtiv9 -verboseITM511Profile#ibmtiv9-region TMW_PhysicalDiskModel :Running


TMW_HighPhysicalDiskReadBytesSec 100 % TMW_PhysicalPossibleFrag 100 % TMW_HighPhysicalDiskXferRate 100 % TMW_HighPhysicalDiskWriteBytesSec 100 % TMW_SlowPhysicalDrive 100 % TMW_HighPhysicalPercentDiskTime 100 % TMW_Processor :Running TMW_ProcessorBusy 100 % TMW_HighProcesses (Processor=1;) 0 % TMW_CPUCantKeepUpWithHW 100 % TMW_HWKeepingCPUBusy 100 % TMW_BusyHardware 100 % TMW_HighPercentUsageDelta (Processor=1;) 0 %

The alert that has been generated has been caused by TMW_HighProcesses. The IBM Tivoli Business Systems Manager console reflects these events.

Figure 8-9 All Resources - Descendants window

This dialog shows the All Resources View of the IBM Tivoli Business Systems Manager. A business object container has been opened, revealing a problem with the ibmtiv9 endpoint. The Tivoli endpoint object contains two sub-objects: Operating System and Software Element. The Software Element contains the heartbeat information, and the Operating System contains information about the computer and Tivoli Monitoring events. If we double-click the Operating Systems


object, the Properties window opens, as in Figure 8-10, to show a more detailed description of the problem.

Figure 8-10 Windows 2000 - Properties window

We can see that an exception has been raised showing high processor usage.

8.4 Tracing an event to the Common ListenerNow that we have installed the IBM Tivoli Business Systems Manager adapter we can use a trace to examine in detail the reception of the event from the endpoint to the IBM Tivoli Business Systems Manager adapter on the gateway.


We wrote a script to enable tracing of the of the trace simultaneously to produce smaller log files to review. The script is shown in Example 8-7.

Example 8-7 The trace batch file

wdmtrceng -e ibmtiv9 c:\sam\tmw2k.log 3 1000000wdmconfig -D tbsma.trace_level=2wdmconfig -D adapter.trace.enable=truewdmconfig -D transport.trace.enable=truewdmconfig -D transport.trace.level=highwdmmn -stop -b

We did not find anything significant in the tmw2k.log file so we will begin with the review of the trace_tmnt_tbsm_eng1.log as shown in Example 8-8.

Example 8-8 The file trace_tmnt_tbsm_eng1.log

<F>1037738265000<F>Tue Nov 19 14:37:45 2002<F>AMW<F>tbsma<F>ibmtiv9<F>2968<F>MAX<F>../../../../src/objects/TMNTUpcall/platform/TBSMAdapterProcessor_meth_imp.cpp<F>process_cached_events(cache_file_name)<F>3710496<F>Sending events' stream:<F>None.<event>

<time>1037738248</time><id>

<class>OperatingSystem</class><instid>os_ibmtiv9</instid>

</id><type>TMW_HighProcesses@TMW_Processor</type><context>[666252843]Processor=0;</context><tbsm>

<type>EXCP</type><desc>

High CPU Usage, High CPU Usage User Priv, and High CPU Usage Process are exceeded on the processor 0. (;highprocesses= 2.0000;idprocess= 204.0000;percentprocessortime= 98.0000;process="CSRSS";processor="0")

</desc></tbsm><tecstatus>

<severity>CRITICAL</severity></tecstatus>

</event><event>

<time>1037738253</time>

Note: We have reformatted most of the XML tags in these examples for easier viewing. In the real log file, the XML will be inline, appended into a single line.


<id><class>OperatingSystem</class><instid>os_ibmtiv9</instid>

</id><type>TMW_TaskResult@TMW_Processor</type><context>[666252843]Processor=0;</context><tbsm>

<type>EXCP</type><desc>The tasks associated to the event '

TMW_HighProcesses', have been submitted for execution.(;eventtriggername="TMW_HighProcesses";return_codes="[0]";task_libs="['IBM Tivoli Monitoring UtilityTasks']";tasks="['dm_mn_send_notice']")


<severity></severity></tecstatus>

</event>

We can see here that the ibmtiv9 endpoint fired and invoked a send_event_to_tbsm() request to the tmnt_tbsm_eng.exe process. This information was then passed to the IBM Tivoli Business Systems Manager wrapper process. This data also shows that we sent an information event to IBM Tivoli Business Systems Manager that shows that a task has been invoked. We set a task up to send information to the notice board in framework on an alert. Note that this second event has no severity.

Next we go the the tmnt_tbsm_wrapper. The log file, shown in Example 8-9, is trace_tmnt_tbsm_wrapper1.log.

Example 8-9 The file trace_tmnt_tbsm_wrapper1.log

<F>1037738265000<F>Tue Nov 19 20:37:45 2002 GMT<F>AMW<F>tbsma-wrapper<F><F>3996<F>MAX<F>../../src/tbsm_adapter_wrapper/TBSMAWrapper.cpp<F>send_event<F>n/a<F>Calling Adapter::sendEvent(DM+ibmtiv9-9.3.4.53-1389241399-0000000023, ...). XMLstream<F>None.<event>

<time>1037738248</time><id>








</event><event>

<time>1037738253</time><id>







</event>

The tmnt_tbsm_wrapper process encapsulates this information into SOAP format and forwards it via the sendEvent procedure to the IBM Tivoli Business Systems Manager Common Listener using a Java-based message queuing transport. Note that the time is converted to Greenwich Mean Time (GMT).

The CommonListener log file is shown in Example 8-10.

Example 8-10 CL20211191208.1.log

2002.11.19 14:38:53.062 com.tivoli.tbsm.commonlistener.ASIMQeListenerThread run INFO: Thread Thread_1 received message from: 9.3.4.59.DM.QM+DM.Q+com.ibm.mqe.adapters.MQeTCP/IPHistoryAdapter+9.3.4.59+6969


TransactionID: 0 MessageNumber: 1<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body>

<tbsm:sendEvent xmlns:tbsm="urn:tbsm:1.0"><event>

<time>1037738248</time><id>







</event><event>

<time>1037738253</time><id>







</event>


</tbsm:sendEvent></SOAP-ENV:Body></SOAP-ENV:Envelope>. . .2002.11.19 14:38:53.078 com.tivoli.tbsm.commonlistener.ASIJDBCBatchSet updateCLStageInit INFO: update CL_Stage set trTimeReceived = CURRENT_TIMESTAMP, trState=2, registrationId='1', trType='3', msgTrID='0', msgNumberBegin='1' where trId = '656'. . .2002.11.19 14:38:53.078 com.tivoli.tbsm.commonlistener.ASIJDBCBatchSet updateCLEventData INFO: insert into CL_StageEvData (trId, evDataId, root, keyword, value) VALUES('656', '1', 'event:tbsm1', 'type', 'EXCP')

We can see that this transaction is sucessfully received and that it contains two events. We can also see by looking farther down the log file that we have a trID (Transaction ID) of 656. Also of interest is the insertion into the table of the current state of this object.

We can see that this is the type EXCP, which would be a exception, and this change in value would cause a flag appear in the status of the object.

If we were to stop the root cause of the problem, we would see the results for the TBSM adapter appear as in Example 8-11.

Example 8-11 The file trace_tmnt_tbsm_eng1.log

<F>1037738310000<F>Tue Nov 19 14:38:30 2002<F>AMW<F>tbsma<F>ibmtiv9<F>2968<F>MAX<F>../../../../src/objects/TMNTUpcall/platform/TBSMAdapterProcessor_meth_imp.cpp<F>t_imp_DMMiddleLayer_Processor_send_event_to_tbsm<F>3709576<F>Endpoint 'ibmtiv9' fired the event:<F>None.<event>

<time>1037738309</time><id>

<class>$TBSM_ClassName</class><instid>$TBSM_ObjectID</instid>

</id><action>remove</action><type>TMW_HighProcesses@TMW_Processor</type><context>[666252843]Processor=0;</context><tbsm>

<type>EXCP</type></tbsm>

</event>

We can see that a clearing event created by sending a REMOVE action is being sent from the monitoring engine running on the endpoint to the IBM Tivoli


Business Systems Manager adapter process. In turn this is reflected in the tbsm_wrapper logfile as shown in Example 8-12.

Example 8-12 The file trace_tmnt_tbsm_wrapper1.log

F>1037738310000<F>Tue Nov 19 20:38:30 2002 GMT<F>AMW<F>tbsma-wrapper<F><F>3996<F>MAX<F>../../src/tbsm_adapter_wrapper/TBSMAWrapper.cpp<F>send_event<F>n/a<F>Calling Adapter::sendEvent(DM+ibmtiv9-9.3.4.53-1389241399-0000000023, ...). XML stream<F>None.<event>

<time>1037738309</time><id>

<class>$TBSM_ClassName</class><instid>$TBSM_ObjectID</instid>



</event>

Finally we can also see this in the CommonListener file as shown in Example 8-13.

Example 8-13 CL20211191208.1.log

2002.11.19 14:39:40.218 com.tivoli.tbsm.commonlistener.ASIMQeListenerThread run INFO: Thread Thread_2 received message from: 9.3.4.59.DM.QM+DM.Q+com.ibm.mqe.adapters.MQeTCP/IPHistoryAdapter+9.3.4.59+6969TransactionID: 0 MessageNumber: 2<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><tbsm:sendEvent xmlns:tbsm="urn:tbsm:1.0">

<event><time>1037738309</time><id>





</event></tbsm:sendEvent></SOAP-ENV:Body></SOAP-ENV:Envelope>. . .2002.11.19 14:39:40.265 com.tivoli.tbsm.commonlistener.ASIJDBCBatchSet updateCLEventData INFO: insert into CL_StageEvData (trId, evDataId, root, keyword, value) VALUES('657', '1', 'event', 'action', 'remove')

Note the state change that will cause the exception to be removed and returned to a normal state. We can see that the trID is 657.

We also can see these transaction objects within the IBM Tivoli Business Systems Manager database by opening a Microsoft SQL Server Enterprise Manager window to the database. We know from the traces that we will need to look at the transactions with trID 656 and 657. We choose to view any changes to the CL_Status table from these two transactions as shown in Figure 8-11.

Figure 8-11 SQL Window: Query-ibmtiv5.Object.sa

We can see more clearly here that an exception is raised (656) and removed (657) by these transactions.

In Figure 8-12 on page 276 we have run an SQL select statement to show all the data entered by these transactions. You can easily match these attributes to the XML files in the previous examples. Chapter 3, “Database structure” on page 77 covers these tables in detail.


Figure 8-12 SQL Window: Query-ibmtiv5.object.sa

The dm.trc file in the $DBDIR\dmml directory displays a less-detailed view of the IBM Tivoli Business Systems Manager adapter, as shown in Example 8-14. We have not formatted these outputs.

Example 8-14 The file dm.trc

2002.11.19 14:37:45.671 com.tivoli.commonlistener.tbsmadapter.engine.Engine sendData

SENDING DATA = <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><tbsm:sendEvent xmlns:tbsm="urn:tbsm:1.0"><event><time>1037738248</time><id><class>OperatingSystem</class><instid>os_ibmtiv9</instid></id><type>TMW_HighProcesses@TMW_Processor</type><context>[666252843]Processor=0;</context><tbsm><type>EXCP</type><desc>High CPU Usage, High CPU Usage User Priv, and High CPU Usage Process are exceeded on the processor 0. (;highprocesses= 2.0000;idprocess= 204.0000;percentprocessortime= 98.0000;process="CSRSS&


quot;;processor="0")</desc></tbsm><tecstatus><severity>CRITICAL</severity></tecstatus></event><event><time>1037738253</time><id><class>OperatingSystem</class><instid>os_ibmtiv9</instid></id><type>TMW_TaskResult@TMW_Processor</type><context>[666252843]Processor=0;</context><tbsm><type>EXCP</type><desc>Thetasks associated to the event 'TMW_HighProcesses', have been submitted for execution. (;eventtriggername="TMW_HighProcesses";return_codes="[0]";task_libs="['IBM Tivoli Monitoring Utility Tasks']";tasks="['dm_mn_send_notice']")</desc></tbsm><tecstatus><severity></severity></tecstatus></event></tbsm:sendEvent></SOAP-ENV:Body></SOAP-ENV:Envelope>

2002.11.19 14:37:45.671 com.tivoli.commonlistener.tbsmadapter.engine.Engine sendData NOTE: THIS IS NOT A LOGGING SID = DM+ibmtiv9-9.3.4.53-1389241399-0000000023

. . .

2002.11.19 14:38:30.734 com.tivoli.commonlistener.tbsmadapter.engine.XMLManagerenvelop mode = 12

text = <event><time>1037738309</time><id><class>OperatingSystem</class><instid>os_ibmtiv9</instid></id><action>remove</action><type>TMW_HighProcesses@TMW_Processor</type><context>[666252843]Processor=0;</context><tbsm><type>EXCP</type></tbsm></event>


Chapter 9. IBM Tivoli NetView integration

In this chapter, we will discuss the integration of IBM Tivoli NetView distributed, a typical intermediate manager for IP networks, into IBM Tivoli Business Systems Manager. The discussion covers the following topics:

� 9.1, “What IBM Tivoli NetView is” on page 280 discusses IBM Tivoli NetView in general and explains its capabilities and focus.

� 9.2, “NetView 7.1.3 installation and configuration” on page 283 lists the prerequisites required to install NetView under AIX Version 4.3 and higher.

� 9.3, “Adapter installation” on page 291 describes the steps you for installing the NetView IBM Tivoli Business Systems Manager adapter

� 9.4, “NetView adapter configuration” on page 293 leads you through the configuration steps on both sides of the environment

� 9.5, “Using the adapter” on page 295 gives information about verifying a successful installation of the adapter.

� 9.6, “Troubleshooting the environment” on page 305 discusses the provided troubleshoot and analysis functions

� 9.7, “Extending the menus” on page 311 shows an example of how to extend the NetView Web console.

9


9.1 What IBM Tivoli NetView isIn this section, we give a brief overview of the capabilities and features of IBM Tivoli NetView distributed. Also, you can find a short list of related documentation in this section.

For more than a decade, IBM Tivoli NetView for distributed systems (in short, NetView) is IBM’s major application to monitor and manage IP network resources in a distributed environment. It provides the capabilities pictured in Figure 9-1, which we will discuss briefly in this section. In addition, NetView can provide information to other management applications such as IBM Tivoli Business Systems Manager and the Tivoli Enterprise Console (TEC).

Figure 9-1 NetView’s main capabilities

As a typical IP manager, NetView performs a number of tasks that are needed to retrieve information from network resources and to manage them accordingly. These NetView capabilities include:

Network discovery Discovers the local IP network automatically and identifies the type and capabilities of the discovered resources.

SNMP management Proactively manages network resources through the Simple Network Management Protocol (SNMP)

N etw orkD iscovery

SN MPM anagem ent

TopologyD istributed

M anagem ent

R oot C auseAnalysis

N etw orkM anagem ent


protocol as defined in RFC 1157. NetView covers both areas in SNMP management: retrieval of information by polling SNMP MIB entries from discrete network objects and the processing of asynchronous events in the network delivered as SNMP traps to the management system.

Topology display Show the network topology including network segments and their connecting routers, as well as other connecting resources such as hubs, switching devices, terminal servers, etc.

Distributed management Accesses NetView management systems from various locations inside the network domain, and even across firewalls with the help of Java-based consoles.

Root Cause Analysis Automatically analyzes and detects the root cause of a network problem, thus eliminating the generation of a high number of unwanted events and clearly pointing to the real cause of the problem.

In version 7.1, NetView has become more tightly integrated with other management applications such as Tivoli Enterprise Console and IBM Tivoli Business Systems Manager. This extends its management flexibility with the ability to provide both network management and, to a given extent, systems management and business systems management. In this chapter, we examine the integration into IBM Tivoli Business Systems Manager.

With its ability to easily effect changes on many devices, a global support infrastructure, and the backing of hundreds of third-party vendors, NetView has become an important tool for the management of complex networks. Furthermore, NetView not only enables you to manage your network, it also provides essential information to other parts of your management environment. A sample NetView console is shown in Figure 9-2 on page 282.

Chapter 9. IBM Tivoli NetView integration 281

Figure 9-2 The NetView Web console

The new Java-based NetView client shown in Figure 9-2 enables you to access NetView from anywhere within your network, either with a standalone application you can download using NetView’s built-in Web Server or with a Java plugin for your Web browser. Access to NetView through the Web console is granted on a per-user basis. You can assign each user a definable role giving more or less restricted access to NetView, as well as a specific view and a limit on access to the graphical information.

The Web console provides graphical information about node status, as well as:

� An event browser that displays incoming events according to the actual user role and view.

� A Management information Base (MIB) browser that can retrieve MIB variables from all objects in your network.

� A set of commonly used Simple Network Management Protocol (SNMP) or IP-based diagnostcs ranging from connectivity tests to limited systems management operations such as file system monitors.

� Basic management capabilities such as manage/unmanage an object or acknowledge/unacknowledge a certain status of an object. Any changed


status is accordingly propagated among all working instances of the NetView console.

Besides its ability to manage IP networks, NetView can analyze and display ISO Layer 2 information such as Switch Port assignments, status, and more. In conjunction with a companion product, IBM Tivoli Switch Analyzer, NetView extends its root cause analysis capabilities down to Layer 2 in switched network environments.

For more information on IBM Tivoli NetView refer to the following publications:

� NetView for UNIX, User’s Guide for Beginners, SC31-8891� NetView for UNIX, Administrators Guide, SC31-8892� NetView for UNIX, Administrators Reference, SC31-8893� NetView, Web Console User’s Guide, SC31-8900

You can find publications about NetView, as well as API and programmers’ reference publications, from the main pull-down menu at:

http://www-3.ibm.com/software/sysmgmt/products/support/

A redbook covering most of the NetView Version 6 architecture and background information also is available:

� Tivoli NetView 6.01 and Friends, SG24-6019

9.2 NetView 7.1.3 installation and configurationThis chapter discusses the IBM Tivoli NetView version 7.1.3 implementation:

� 9.2.1, “Installation prerequisites” on page 283

� 9.2.2, “Suggested configuration steps” on page 284

9.2.1 Installation prerequisitesThis section discusses the prerequisites you need to fulfill in order to install and run NetView under AIX Version 4.3 and higher.

In our environment, we use IBM Tivoli NetView Version 7.1.3. We suggest that you use at least NetView Version 7.1.2. The target system in our environment is a Power PC running AIX 5.1. For reference purposes, we provide a list of prerequisites you need to run NetView under AIX:

� AIX Version 4.3 or higher; in our environment, we use AIX Version 5.1.0.0.



� The default language for NetView on AIX must be English [En_US] . You can modify the language setting with smit and its fastpath mle_lang. Select English [En_US] for both the language and the cultural conventions.

In addition, the following system components must be installed:

� X11.compat.lib.X11R5� X11.vfb� X11.compat.fnt.pc� bos.compat.links

With all the required prerequisites, NetView should install without problems. The NetView program CD contains a script to perform the installation. It will detect any problems during the installation and stop to give you the chance to correct the problem. For a complete reference about the installation, always consult the supplied README document.

In our lab, the NetView server resides on a separate network segment. The macine NetView runs is capecod.itsc.austin.ibm.com (from now on referred to by its host name, capecod).

9.2.2 Suggested configuration stepsWe performed a few configuration steps that slightly changed the appearance of NetView in order to separate the topology information from the event information.

We changed the event console configuration to disconnect from the main NetView screen. The changes were made in /usr/OV/app-defaults/Nvevents and /usr/OV/registration/C/ovsnmp/nvevents. Example 9-1 shows the changes in /usr/OV/app-defaults/Nvevents.

Example 9-1 Changes in /usr/OV/app-defaults/Nvevents

!! defines initial presentation style (card or list)!nvevents.initialPresCard : False

!! defines if application starts up outside of the control desk! valid when running integrated to OVw!nvevents.outside : True

In addition, you need to change the NetView registration file as shown in Example 9-2 on page 285. In /usr/OV/registration/C/ovsnmp/nvevents look for the Command entry and remove the -Initial attribute from the command line.


Example 9-2 Changes in /usr/OV/registration/C/nvevents

/* * Use -Shared so that only one copy of application is run. * If user selects menu item again, OVwAction causes the existing window * to raise to top of stack. * * Use -Initial so that the events categories window gets displayed when * OVW starts up. * */ Command -Shared '${nvevents:-/usr/OV/bin/nvevents}' ;

To enable access to NetView from a remote Web console (either with the Web Console Application or from within a browser applet), be sure to register and start the netviewd daemon. You can do this by issuing /usr/OV/bin/ovaddobj /usr/OV/lrf/netviewd.lrf from a command line.

Next, define at least one user by using the nvsetup application in order to gain access to NetView through the Web console. You will need a user definition to access NetView data from within IBM Tivoli Business Systems Manager.

To add a user, execute the /Usr/OV/bin/nvsetup utility to display the setup dialog as in Figure 9-3 on page 286. In this dialog select Configure -> Configure Web Console Security.


Figure 9-3 Invoking Web console Security from nvsetup

Alternatively, you can start the configuration utility from the native NetView console by clicking Administer -> Security Administration -> Web Console Security. In both cases, the Java-based Web Console Security application opens with the initial dialog box shown in Figure 9-4 on page 287.


Figure 9-4 The Web Console Security dialog box

In this dialog, you can add and edit users, roles, and views. Clicking Selected -> Add or selecting the Add icon in the button row, will open the Add User dialog shown in Figure 9-5.

Figure 9-5 The Add User dialog box


Enter a user name and a password. For now, assign the SuperUser role to the new user. Because an IBM Tivoli Business Systems Manager user might need to access all of the network topology, apply No scoping restrictions to the Scope field. Click OK to close the dialog box, then click File -> Save to save the new user definition. You will be asked to restart the Web server to activate the changes. Reply Yes to restart the Web server.

Because commands launched from IBM Tivoli Business Systems Manager to NetView are executed locally, the NetView Web console must be installed on all workstations that will be used to access IBM Tivoli Business Systems Manager and its Java console. NetView provides a download page with install images of the NetView Web console for various platforms. You can access this download page by connecting to NetView Server using a Web browser. In our case the download page is at http://capecod:/8080/download, and 8080 is the default port the NetView Web server listens. A download page is shown in Figure 9-6.

Figure 9-6 The NetView Web Console download page

For a Windows-based workstation, select nvwcinstal.exe and download the file. This is a Windows install image that you can install on the target workstation.


Figure 9-7 Changing the default path for the NetView Web Console

The install procedure creates an object on your Windows desktop. Double-click that icon to launch the Web console and open the logon dialog as shown in Figure 9-8 on page 290.

Note: With the current implementation of the NetView IBM Tivoli Business Systems Manager adapter, a launch of the NetView Web Console from the IBM Tivoli Business Systems Manager Java console will not work with the default Path the Web console installer suggests. One component installed on the IBM Tivoli Business Systems Manager side, nvlaunch.jar, only supports file paths in the classic 8.3 notation. We recommend that you change the install directory during NetView Web Console install to something like c:\NVWC as in Figure 9-7.


Figure 9-8 Web Console login dialog

Type in your user ID, password, the hstname of your NetView sever, and the port on which the NetView Web Console is listening.

After the succesful logon, select File -> Open from the menu to display a map inside the Web console as in Figure 9-9 on page 291.


Figure 9-9 Open a map

9.3 Adapter installationThe installation of the IBM Tivoli Business Systems Manager NetView Adapter consists of two tasks:

� Installing and configuring the adapter on your NetView server. Most of the required steps are performed by an installation script. We will describe the sample installation in our lab environment in 9.3.1, “Installing the NetView part of the adapter” on page 292.

� Executing a script on the IBM Tivoli Business Systems Manager database server to upgrade a few database tables. The data will be used by the IBM Tivoli Business Systems Manager common listener. You can find these installation steps in 9.3.2, “Installing the TBSM part of the adapter” on page 293.


9.3.1 Installing the NetView part of the adapterThe NetView part of the IBM Tivoli Business Systems Manager Adapter is available as a single tar archive. Put the file into an empty directory on the target system and issue a tar command to split the archive into its components. After splitting the file, you should see three files in the directory you chose, similar to Example 9-3.

Example 9-3 Directory contents

capecod:/nv713 #ls -latotal 11856drwxr-sr-x 2 sys sys 2560 Nov 08 10:55 .drwxr-xr-x 28 bin bin 1024 Nov 14 13:12 ..-rwxr-xr-x 1 101 staff 5333 Sep 26 2001 Install.ksh-rw-r----- 1 root sys 3031040 Nov 07 17:08 tbsmadapter_aix_1_1_nv71_20011114.tar-rw-r--r-- 1 root staff 3020800 Nov 14 2001 tbsmadapter_aix_kit.tar

To install the IBM Tivoli Business Systems Manager adapter you need root permissions. This is normal, as most configuration tasks on NetView require root permissions. To install the IBM Tivoli Business Systems Manager adapter on the NetView Server, execute the Install.ksh script. The script:

� Extracts the files in the archive

� Places the contents of the archive into their correct locations

� Preserves existing configuration files if this is a repeat install or upgrade

� Registers the tbsmadapter daemon to NetView

A typical output of Install.ksh is shown in Example 9-4.

Example 9-4 TBSM adapter installation output

capecod:/nv713 #Install.kshInstall.ksh (15:49:53): Installation of TBSM Adapter for NetView kit started.Install.ksh (15:49:53): TBSM Adapter software loaded correctly.ovaddobj - Static Registration UtilitySuccessful CompletionInstall.ksh (15:49:53): TBSM Adapter daemon successfully added to NetView Configuration.Install.ksh (15:49:53): Installation of TBSM Adapter for NetView kit was successful.capecod:/nv713 #

Note: As of the writing of this book, the archive nvlaunch.tar referenced in this section is not distributed with either IBM Tivoli Business Systems Manager or the NetView adapter. Contact your IBM Tivoli representative for this.


9.3.2 Installing the TBSM part of the adapterTo process and integrate the data sent from NetView to IBM Tivoli Business Systems Manager, the IBM Tivoli Business Systems Manager database server requires some additional information. The IBM Tivoli Business Systems Manager adapter package contains one single archive, nvlaunch.tar. On the IBM Tivoli Business Systems Manager database server, untar the file into the \tivolimanager directory. Extracting nvlaunch.tar will place the following files under yout \tivolimanager directory:

� .\bin\nvlaunchconfig.sh� .\sql\netviewlaunch.upg� .\sql\LookupNetViewURLs.sqi� .\sql\_LookupNetViewURLs.sql

The .\bin\nvlaunchconfig.sh file needs some customization. Open the file with a text editor and locate the lines shown in Example 9-5. Replace the XXXXX placeholder with the correct values of your database server name, the SQL username, and the SQL password. After making the chages, save the file. This finishes the IBM Tivoli Business Systems Manager side configuration.

Example 9-5 nvlaunchconfig.sh customization

# Replace XXXXX with the name of the TBSM database serverSQLSERVER=ibmtiv5# Replace XXXXX with the name of the SQL Server user accountSQLUSER=sa# Replace XXXXX with the password for the SQL Server user accountSQLPWD=sa_ibmtiv5

9.4 NetView adapter configurationBefore the IBM Tivoli Business Systems Manager adapter is able to send any information to NetView, a few configuration files must be customized on the NetView server as they were on the IBM Tivoli Business Systems Manager database server. You can find all the relevant configuration files under /usr/OV/conf. The examples in this section contain only the relevant lines requiring changes during the adapter configuration. For complete listings of the configuration files, refer to “NetView adapter configuration files” on page 566.

1. Open /usr/OV/conf/nvid.conf. This file holds unique information about the NetView site. This enables IBM Tivoli Business Systems Manager to work with multiple NetView managers from different locations as well as with two NetView managers per site in a fallover configuration. Table 9-1 on page 294 explains the keywords used in nvid.conf.


Table 9-1 nvid keywords

With the information provided in the table, we customized the nvid.conf file for the NetView server being used in our lab environment as shown in Example 9-6.

Example 9-6 nvid.conf

nvid=TI7043TBSMnetworkid=NV0primaryURL=capecod.itsc.austin.ibm.com.ibm.com:8080secondaryURL=backupnetview.ibm.com:8080contact=Peter Glasmacherdescription=The coolest NetView on earth

2. The next file to change is called /usr/OV/conf/topxlistener.conf. For now, specify your own address and the address of the node where the IBM Tivoli Business Systems Manager common listener is executed. Later on in section 9.6, “Troubleshooting the environment” on page 305, we will access the file again. Change entries in this file in two places:

a. Look for the section transport base properties and replace any occurence of localhost with the fully qualified ip name of your NetView server.

b. Then look for the section only for client and replace the localhost entry in the transport.server.ip.address field with the fully qualified IP name of the node where the IBM Tivoli Business Systems Manager common listener gets executed.

Keyword Comment

NVID Reserved for future use. Must not exceed 15 characters. No spaces allowed.

NetworkID This identifier is used by the IBM Tivoli Business Systems Manager adapter. It is appended to all IBM Tivoli Business Systems Manager object instances and uniquely identifies all the objects from each side. The value should be significantly shorter than NVID, for example NV0. It is limited to the alphanumeric character set A-Z,a-z,0-9, no spaces.

PrimaryURL This is the IP host name and the port for the NetView Web server running on this node. Must be entered in the form <hostname>:port where hostname is the fully qualified host name and port is the listener port of the Web server (normally 8080).

secondaryURL Specifies a backup NetView server that shares the same nnid.conf file


Leave the port numbers as they are for now. You can change theTCP port assignments if you need to; for example, if these ports are already occupied by other TCP-based services. Example 9-7 shows the changes we applied in our lab environment.

Example 9-7 usr/OV/conf/topxlistener.properties

# transport base properties..transport.local.ip.address = capecod.itsc.austin.ibm.comtransport.request.address = capecod.itsc.austin.ibm.com.BASETEST.QM+BASETEST.Qtransport.request.port = 9898transport.response.address = capecod.itsc.austin.ibm.com.BASETEST.QM+BASETEST.Qtransport.response.port = 9898..# only for client # server transport.server.mqe.address = ServerQM+ServerQ transport.server.mqe.port = 8082 transport.server.ip.address = ibmtiv3.itsc.austin.ibm.com

3. The last file you need to modify is /usr/OV/conf/topxgate.conf. This file contains all events to be forwarded to IBM Tivoli Business Systems Manager. If you want to prevent a specific trap from being forwarded to IBM Tivoli Business Systems Manager, place a comment sign (#) in front of the trap definition.

9.5 Using the adapterThis section covers the use of IBM Tivoli Business Systems Manager Adapter.

9.5.1 Bulk discoveryAfter a successful installation, you can use the following steps to verify the NetView side of the adapter installation:

1. Use NetView’s /usr/OV/bin/ovstatus or the /usr/OV/service/nvstat utility to verify that a new daemon, tbsmadapter, is running and registered to NetView. You should see a new daemon in the list of running NetView daemons as shown in Example 9-8.

Example 9-8 The new tbsmadapter daemon (partial output of nvstat)

capecod:/ #nvstatNOTE: ovspmd is process 27850


DAEMON NAME PROCESS PARENT DEPENDENCIESactionsvr 25698 ovspmd nvsecd,nvcorrdems_log_agent 31236 ovspmd nvsecd,ems_sieve_agent..tbsmadapter 19662 ovspmd nvsecd..webserver 17584 ovspmd ovwdbcapecod:/ #

2. Next, open a NetView GUI and select the Tools menu. You will see a new menu entry TBSM Adapter Manager: Bulk Upload as in Figure 9-10.

Figure 9-10 The TBSM Bulk Upload entry

Select this menu entry. This will start a Bulk Upload of the NetView topology data to IBM Tivoli Business Systems Manager. During the update the message shown in Figure 9-11 on page 297 will appear.


Figure 9-11 NetViews bulk upload message

Alternatively, you can issue the /usr/OV/bin/tbsmbulkupload.ksh command from the command line to initiate a bulk upload. After executing the bulk upload, you should see your NetView resources in IBM Tivoli Business Systems Manager. In case of problems, refer to 9.6, “Troubleshooting the environment” on page 305.

9.5.2 How NetView resources are handled

Once you have executed the bulk upload, you can display the resources in IBM Tivoli Business Systems Manager either in a typical Explorer view or in Hyperview presentation. A bulk upload from NetView to IBM Tivoli Business Systems Manager builds the initial set of resources. Subsequent updates to this set of resources are always triggered by a NetView event. The upload follows these simple rules:

� All visible elements in and including the IP Internet set of submaps will be populated to IBM Tivoli Business Systems Manager upon initial population during bulk upload.

� To prevent a resource from being uploaded to IBM Tivoli Business Systems Manager you must hide them on the NetView map.

� Unmanaged resources will be uploaded, but none of the lower-level resources will be uploaded. For unmanaged routers, the interfaces will not be uploaded even if they are managed.

� After the initial population, changes in the IBM Tivoli Business Systems Manager views usually are triggered by NetView events through tbsmtrap.

To demonstrate this behavior, we executed the following steps:

1. We stopped the IBM Tivoli Business Systems Manager adapter, and ran Server Setup -> Control -> Restart Automatic Map Generation to build a fresh initial NetView Map.


Figure 9-12 The initial NetView Map contents

2. We reorganized the initial map to show only our central router and a location containing the network segment hosting our NetView server. Figure 9-12 shows the related submaps.

3. Then we started the IBM Tivoli Business Systems Manager adapter. We verified the connection to the common listener by checking the existence of two connections between NetView and the node where the common listener executes. An easy way to look for TCP connections is using the netstat command: netstat -a | grep <CL_node>, where <CL_node> is the name or IP address of the node the common listener runs. The command should return with a list containing two TCP connections, as shown in Example 9-9.

Example 9-9 TCP connections between NetView and TBSM

capecod:/ #netstat -a|grep ibmtiv3tcp4 0 0 capecod.itsc.aus.9898 ibmtiv3.itsc.aus.1521 ESTABLISHEDtcp4 0 0 capecod.itsc.aus.39109 ibmtiv3.itsc.aus.8082 ESTABLISHED

4. With this environment set up, we were ready to upload the initial resources using a bulk upload to IBM Tivoli Business Systems Manager. To issue the bulk upload with NetView, refer to Figure 9-10 on page 296.


5. With the bulk upload successfully finished, we logged on to IBM Tivoli Business Systems Manager using the Java console. To check the upload, we chose Console -> Open All Resources from the menu. As expected, we were able to identify our NetView resources inside IBM Tivoli Business Systems Manager as shown in Figure 9-13.

Figure 9-13 Initial NetView resources uploaded to TBSM


6. Then we switched to the hyperview for the view of IBM Tivoli Business Systems Manager shown in Figure 9-14.

Figure 9-14 Hyperview view of NetView resources


7. After these initial checks, we discovered the remaining segments of our lab environment in NetView. We added another location and named it Isolated Subnets to hold the isolated network segments. Our final NetView topology is shown in Figure 9-15.

Figure 9-15 The final discovery in NetView


8. Shortly after NetView finished its discovery, the corresponding hierarchy was available in IBM Tivoli Business Systems Manager. From this point on, all changes in the NetView hierachy and in the status of the NetView resources were reported to IBM Tivoli Business Systems Manager.

Figure 9-16 The corresponding TBSM hierarchy

With the data uploaded, you can now drill down and display different views of the network, such as table view or the topology view shown in Figure 9-17 on page 303.


Notice that the topology view in IBM Tivoli Business Systems Manager is somewhat different from NetView as the relationship between the displayed resources is drawn as you drill down into the topology.

Figure 9-17 Various network views in TBSM

9.5.3 Launching NetView Web console from TBSM

NetView reports all its resources and their attributes to IBM Tivoli Business Systems Manager as discussed in 9.5.2, “How NetView resources are handled” on page 297. Events received by NetView also are reported to IBM Tivoli Business Systems Manager, and they change the status of the affected resources accordingly. In addition, NetView reports all the attributes a resource owns in NetView to IBM Tivoli Business Systems Manager.

For more information from NetView in case of a status change or an event signalling a possible problem, open the NetView IBM Tivoli Business Systems Manager adapter’s interface to the NetView Web console from the IBM Tivoli Business Systems Manager Java console. For all the physical objects reported by NetView, IBM Tivoli Business Systems Manager offers a Launch submenu


that contains three entries you can use to retrieve information direct from NetView, as shown in Figure 9-18.

Figure 9-18 TBSMs Launch submenu

NetView Console Launches the NetView Web console and displays the actual submap where the resource resides.

NetView Diagnostics Lauches the Web console diagnostic dialog and performs an initial quicktest against the selected resource.

NetView Object Properties Lauches the NetView properties page for the selected object providing all the attributes NetView holds in its database to describe the resource.

Figure 9-19 shows all three dialogs you can launch. In 9.7, “Extending the menus” on page 311, we will show how to extend your IBM Tivoli Business


Systems Manager console menu in order to launch all available NetView information at once.

You should now have a working interface between NetView and IBM Tivoli Business Systems Manager and should be able to launch the NetView Web console from your IBM Tivoli Business Systems Manager Java console.

Figure 9-19 The Web Console Launch results

9.6 Troubleshooting the environmentThe following section discusses a few troubleshooting issues in case the connection between NetView and IBM Tivoli Business Systems Manager fails to work as expected. The information is based mainly on our experience with the components in our lab environment as outlined in Figure 1-11 on page 22.

9.6.1 TBSM adapter basicsFirst, ensure all relevant IBM Tivoli Business Systems Manager processes are running. The TBSM adapter requires three running processes to work correctly:

tbsmadapter Executed under control of the NetView process launcher, ovspmd. Start or stop it using the /usr/OV/bin/ovstart


and /usr/OV/bin/ovstop commands. To check its current status, use either the /usr/OV/bin/ovstatus <process_name> command, where <process_name> is the name of the NetView process to be checked, or use /usr/OV/service/nvstat to check the status of all NetView processes. Example 9-10 shows the expected output of the ovstatus command along with a ps -ef command with the process PID filtered.

The tbsmadapter is a Java application that formats the data to be transferred to the remote IBM Tivoli Business Systems Manager Common Listener. It also maintains a TCP connection to the Common Listener.

Example 9-10 Checking the tbsmadapter status

capecod:/usr/OV/www/logs #ovstatus tbsmadapter object manager name: tbsmadapter behavior: OVs_WELL_BEHAVED state: RUNNING PID: 19870 last message: Initialization complete exit status: -capecod:/usr/OV/www/logs #capecod:/ #ps -ef|grep 19870|grep -v grep root 19640 19870 0 16:57:13 - 0:23 /usr/OV/jre/bin/java -classpath /usr/OV/jars:/usr/OV/jars/jlog.jar:/usr/OV/jars/adapter.jar:/usr/OV/jars/ASICommonListener.jar:/usr/OV/jars/MQeGateway.jar:/usr/OV/jars/xerces.jar:/usr/OV/jars/scaffold.jar tbsma root 19870 15480 0 16:57:13 - 0:00 /usr/OV/service/spmsur -w 15 /usr/OV/bin/start_tbsmadapter.sh

tbsmtopo Starts with the netviewd daemon or the NetView GUI. It is responsible for handling requests to extratct data from the NetView database. It also translates this data into XML records before it is given to the tbsmadapter process.

tbsmtrap Also launched by the netviewd daemon or the NetView GUI. It listens for traps and NetView-generated events. For a trap specified in /usr/OV/conf/topxgate.conf, it creates the IBM Tivoli Business Systems Manager message appropriate for this trap. For a topology change event, it signals to tbsmtopo to generate either an IBM Tivoli Business Systems Manager delta upload or an IBM Tivoli Business Systems Manager delete event in case the NetView object was deleted.


Use the ps command to verify that both processes are running. Example 9-11 on page 307 show the expected output. Both processes must be running. These processes get launched together with the netviewd daemon or the NetView GUI.

Example 9-11 Checking tbsmtopo and tbsmtrap

capecod:/ #ps -ef|grep tbsm|grep -v tbsma|grep -v grep root 19168 17354 0 18:15:33 - 0:00 /usr/OV/bin/tbsmtopo 6770 1 root 23684 17354 0 18:15:33 - 0:00 /usr/OV/bin/tbsmtrap capecod:/ #

9.6.2 TBSM communicationIf you experience problems in updating IBM Tivoli Business Systems Manager with NetView data, check whether a communication link exists between the common listener and the NetView TBSM adapter. During the configuration of the TBSM adapter, you had to edit the /usr/OV/conf/topxlistener.properties file. (Refer to Example 9-7 on page 295.) In this file, two TCP ports are specified: one port for the NetView adapter end of the connection, and the second port to specify the listening port of the common listener. The two default assignments are port 8082 for the common listener end of the communication link, and port 9898 for the adapter side of the link.

You should check /usr/OV/conf/topxlistener.properties for the actual port assignments, then use the netstat command on the NetView server to verify that two connections exist. As Example 9-12 shows, you can filter the output of the netstat command to limit the display to the existing connections from the NetView server to the common listener. Example 9-12 also shows the correct directions of the connections from both systems. Our common listener is connected to port 9898 at the NetView server while the NetView server maintains a connection to port 8082 on the common listener side. Both connections must be in the ESTABLISHED state. That means data can be exchanged via both connections.

Example 9-12 Checking TBSM adapter connections

capecod:/ #netstat -a|grep ibmtiv3tcp4 0 0 capecod.itsc.aus.9898 ibmtiv3.itsc.aus.2245 ESTABLISHEDtcp4 0 0 capecod.itsc.aus.45632 ibmtiv3.itsc.aus.8082 ESTABLISHEDcapecod:/ #c:\>netstat -a|grep capecodTCP ibmtiv3:2245 capecod.itsc.austin.ibm.com:9898 ESTABLISHEDTCP ibmtiv3:8082 capecod.itsc.austin.ibm.com:45681 ESTABLISHEDc:\>


9.6.3 Testing the launch functionsIf launching a NetView Web console from the IBM Tivoli Business Systems Manager Java console does not work, you will, in most cases, receive the error message shown in Figure 9-20 on page 308. The message does not give you any hints about the nature of the problem, so follow these steps to figure it out:

� Carefully examine the function and parameter strings provided for the launch menu in the IBM Tivoli Business Systems Manager object database. Inspect the launch parameters in the object database RDM_LAUNCHER table.

Figure 9-20 Launch error message

� If the table entries seem to be correct, try to launch the suspicious command direct from your console workstation using nvlaunch.jar.

a. In the <NVWC>\bin directory, where <NVWC> is the path to the NetView Web console code on your workstation, locate the script nvlaunch.bat.This script requires four parameters in the formnvlaunch.bat port <port_number> stdin <parameter_file> where <port_number> is any free TCP port and <parameter_file> is a text file containing a single line to insert the parameters required to launch the NetView Web console. Specify the parameter in a keyword=value form as shown in Example 9-13. The parameters are:

serverinfo The IP address or name of your NetView server.

scripturl The location of the script being executed at the server side. The location must be specified relative to /usr/OV/www/webapps.

targetnode The name or IP address of the node under investigation.

Remember to put all the parameters in a single line separated by blanks.


Example 9-13 Contents of a nvlaunch.bat parameter file

serverinfo=capecod scripturl=/netview/scripts/3beansalad.js \targetnode=capecod.itsc.austin.ibm.com

b. In a console window, enter the nvlaunch command as in Example 9-14 on page 309. For the parameter file launch.txt this would appear as:

nvlaunch port 1234 stdin ..\bin\launch.txt

Note the specification of the parameter file. The nvlaunch script changes the working directory to <NVWC>\lib, so you must provide the path to your parameter file. You can provide the full (absolute) path or use the notation shown in Example 9-14.

Example 9-14 Executing a Web console launch manually

C:\NVWC\bin>nvlaunch port 1234 stdin ..\bin\launch.txtC:\NVWC\lib>"c:\NVWC\jre\bin\java.exe" -jar launch.jar --port 1234 --stdin 0<..\bin\launch.txtC:\NVWC\lib>goto LAUNCH_NT_W2K_DONEC:\NVWC\lib>popdC:\NVWC\bin>if NOT "Windows_NT" == "Windows_NT" goto SKIP_ENDLOCALC:\NVWC\bin>ENDLOCALC:\NVWC\bin>

� If the parameters provided are correct, a Web console screen opens. After you enter your user name and password, the Web console should display the functions specified in the server script.

9.6.4 TBSM adapter log and trace filesAll three TBSM adapter processes write their own log files. In addition, the tbsmtopo process can be triggered to write a trace. All the log files are written into NetView’s default log directory /usr/OV/log.

tbsma.logThe tbsma.log contains log data from the local IBM Tivoli Business Systems Manager transport code. It logs the start sequence of the adapter and all operations initiated by the two processes tbsmtrap and tbsmtopo, as shown in example Example 9-15. The file is truncated at each stop/start of the tbsmadapter.

Example 9-15 tbsma.log contents

5:25:55 PM CST INST_ID: TBSM Instrumentation for Distributed NetView - TI7043TBSM5:25:57 PM CST Asking for adapter...5:26:10 PM CST setAdapterListenerIF...


5:26:10 PM CST Asking for SID...5:26:21 PM CST Session identifier: [TBSM Instrumentation for Distributed NetView - TI7043TBSM-9.3.4.53-680817032-0000000055]5:26:21 PM CST Serving port 4321.5:26:21 PM CST Waiting for connections.

tbsmatopo.logThis file shows the activities of the tbsmtopo process, as well as its start and stop. It is not truncated when the process is recycled (through stopping netviewd or the native GUI). The most valuable information is the data about delta discovery and bulk uploads, as shown in Example 9-16, which shows start/stop messages and the totals of a bulk upload.

Example 9-16 Contents of tbsmatopo.log

Tue Dec 3 17:28:02 2002 default 23420 Started with revision level 7.1.0Tue Dec 3 17:28:51 2002 default 23420 Callback parameters: -f /usr/OV/tmp/tbsm -s -n TBSM -d 13 -m (map_permit=ovwMapReadWrite, rev=7.1.0)Tue Dec 3 17:28:58 2002 default 23420 IP Internet Totals: Networks : 7 Segments : 8 Locations : 2 Routers : 12 Bridges : 0 Hubs : 0 Hosts : 102 Interfaces : 140Tue Dec 3 17:28:58 2002 default 23420 Callback return code 0Tue Dec 3 17:33:24 2002 default 23420 Ending for the following reason: NetView/6000 ending.

tbsmatrap.logContains information about the trap processing. Each NetView event or trap is intercepted by the tbsmtrap process and is analyzed to determine whether it should be sent to IBM Tivoli Business Systems Manager. Example 9-17 shows the information written for a single trap sent to IBM Tivoli Business Systems Manager. The log file logs both the original trap format as well as the actual XML record, which is sent to IBM Tivoli Business Systems Manager.

Example 9-17 Contents of tbsmatrap.log

Got a trap! Specific: 50790416 varbind 1: varbind 2: 9.13 varbind 3: Network 9.13 Managed.


varbind 4: 1038958353 1208 varbind 5: openview varbind 6: 9.13.0.0 varbind 7: varbind 8:Network managed: Specific: 50790416Sending message:TRAP:EVENT<event>

<id><class>NetworkSubnet</class><instid>9.13:NV0</instid>

</id><type>MNET_EV</type><context>Network</context><tbsm>

<type>MSG</type><desc>Network 9.13 Managed.</desc>

</tbsm></event>Finished processing trap 50790416.

tbsmatrace.logYou can create this file and start additional trace logging at any time. As soon as an empty file named tbsma.trigger is created, tracing of adapter activity is written into tbsmatrace.log.

9.7 Extending the menusBoth the IBM Tivoli Business Systems Manager Java console and the NetView Web console offer some (more or less limited) capabilities to customize and change their behavior. We will now show two examples of how to extend the consoles with custom command.

The first example shows how you can extend the NetView Web console to include the IBM Tivoli Business Systems Manager bulk upload, normally only available with the NetView native GUI.

The second example shows how to extend the IBM Tivoli Business Systems Manager Java console to call additional NetView Console Views.


9.7.1 Extending the NetView Web consoleStarting with NetView Version 7.1, the NetView Web console is meant to be the main interface to NetView. The native console should be used only for administrative purposes such as modifying maps and NetView working options.

IBM Tivoli Business Systems Manager also launches the NetView Web console on demand in order to show NetView-related topology information, diagnostic tools, and object properties. Unfortunately, to initate a bulk upload to IBM Tivoli Business Systems Manager, you have to start the native NetView GUI. We will now show how to extend the menus of the NetView Web console to make the bulk upload menu available in the console, as well.

The NetView Web console offers limited extension capabilities. You can extend the menus and execute commands as long as the output can be displayed in a Web browser window. The supplied Web console functions and menus are defined in two files:

� /usr/OV/www/webapps/netview/warf/Actions.xmlThis file contains all the actions and functions provided by the Web console in a compressed format.

� /usr/OV/www/webapps/netview/warf/Templates/WebConsoleThis file conatins the menu definitions for the actions and functions provided by the Web console.

You can modify these two files, but in the event of a NetView update or patch apply, the update may overwrite them. To prevent this, you can supply your own action definition file and your own menu file, which will not be overwritten. We will provide the extensions in separate definition files.

Note the warf subdirectory in the file path: NetView Web console definition files' role and behavior are similar to NetView Application Registration Files (arf), so they are called Web Application Registration Files (warf) and are located in the path's warf subdirectory. The main difference between warf files and arf-type registration files is the format. Unlike standard NetView registration files and their descriptive C-style format, the warf files use XML as their description language.

Each distinctive function of the NetView Web console consists of two definitions:

� An action definition, which you must store under /usr/OV/www/webapps/netview/warf. The action definition defines what you want executed when selected.

� A menu definition that you must store under /ust/OV/www/webapps/netview/warf/Templates/WebConsole. This definition specifies the position of your new menu under the menu tree.


With this information, we will now show all the steps required to extend the Web console with a new menu, which enables us to trigger a bulk upload from the Web console. You can use this example as a template for own extensions of the Web console. For a brief explanation of the contents of the definition files, Example 9-18 on page 313 lists the action definition and Example 9-19 on page 315 contains the Menu definition.

You also may refer to the section “Web Console Enhancements” in the NetView 7.1.3 Release Notes, GI11-0927-2 for additional information about action and menu definitions.

Example 9-18 The new action definition MyActions.xml

<?xml version="1.0" encoding="UTF-8"?><WARF xmlns:xlink="http://www.w3.org/1999/xlink">

<Meta name="Version" value="2.0" /><Meta name="Written" value="2002 ITSO Austin/Glasi GA24-6610" /><Application name="my-webconsole">

<Action id="launchbu" securityConstraint="RelaxedAccess" roles="SuperUser,User">

<Name>TBSM_BulkUpload</Name><Mnemonic>U</Mnemonic><ShortDescription>Bulk Upload</ShortDescription><LongDescription>Trigger a TBSM Bulk Upload</LongDescription><ActionHandler name="LaunchServerAppHandler">

<Method><MethodName>

com.tivoli.netview.client.NetViewApplet.launchServerApp</MethodName><ArgList>

<Val><Array>

<Val>Glasikey1</Val><Val>/usr/OV/bin/tbsmbulkupload.ksh</Val>

</Array></Val>

</ArgList></Method>

</ActionHandler></Action>

</Application></WARF>

<?xml ...> You must not change the first three entries in a warf file, especially the first line that specifies the encoding. Be sure it specifies UTF-8 as the character set.

<Application> Defines the name of the application. You can assign any unique name to your application. Note that webconsole is a reserved name already used in the main action definition.

<Action id=> This keyword specifies a unique id, which you will reference in your menu definitions. You may apply all the roles you want to allow to perform the action, but leave the securityConstraint= entry unchanged.

<Name> Defines a name for the action.

<Mnemonic> Defines a menu shortcut for your action. Be sure the mnemonic is specified out of the characters used in the name definition.

<ShortDescription> Here you can specify a short description of your new menu. It will appear in the role dialog of the NetView Security Console, as shown in Figure 9-21 on page 317.

<LongDescription> Defines a more specific explanation of your new menu. Appears in the roles dialog as well.

<ActionHandler> Specifies the handler meant to execute the action. Don’t change the name LaunchServerAppHandler. This handler will execute your action on the NetView server.

<Method> Starts a method subsection in which you will define the program to be executed, along with all arguments it might require.

<MethodName> Specifies the method assigned to the application handler. The full path of the method is required. In our case it iscom.tivoli.netview.client.NetViewApplet.launchServerApp

<ArgList> Starts an argument list subsection. Each of the arguments is defined inside a <Val></Val> definition.

<Array> Our action, issuing a bulk upload to IBM Tivoli Business Systems Manager, is actually implemented as a Korn shell script. Parameters to a shell script are passed in the form of an array. Even though our bulk upload script does not require any parameters, you must supply the parameter array. The first value in the array acts as a key, which must be unique for all actions defined to execute under a given action handler. In our case, the key must be unique for all actions executed under LaunchServerAppHandler.The second value in the array must be the program name. A full path is required. Therefore, our array will be<Array>


<Val>Glasikey1</Val><Val>/usr/OV/bin/tbsmbulkupload.ksh</Val></Array>.

You can put multiple action definitions into one single file. Each definition requires the full set of keywords as discussed.

The second set of definitions required are the menu entries. As mentioned previously in this section, menu definitions are stored under:/usr/OV/www/webapps/netview/warf/Templates/WebConsole

Example 9-19 lists our menu definition.

Example 9-19 The Menu definition file MyMenubar.xml

<?xml version='1.0' encoding='UTF-8'?><WARF xmlns:xlink='http://www.w3.org/1999/xlink'>

<Meta name="Written" value="2002 ITSO Austin/Glasi GA24-6610" /><Application name='webconsole'>

^M<MenuBar name="MyMenuBar">

<Menu name="tools"><Separator/><Menu name="TBSM">

<Mnemonic>T</Mnemonic><Name>TBSM</Name><MenuItem name="TBSM_BulkUpload">

<ActionRefxlink:href='MyActions.xml#xpointer(id("launchbu"))'/>

</MenuItem></Menu>

</Menu></MenuBar>

</Application></WARF>

<?xml ...> The same as for the action definition. Don’t change the first three lines, and be sure the character set encoding is set to UTF-8.

<Application> Use the same name as in your action definition.

<MenuBar> Starts a menu bar definition. Apply the same rules as for the application name. The name must be unique. (You can’t give it the name ‘MenuBar’ because this name is already used for the default menubar of the Web console.)

<Menu> Specifies an existing menu where our submenu should be placed. The NetView Web console already features a tools menu like the native GUI. Thus, we specify name="tools" as the menu entry where our new menu will reside.

<Separator/> Causes a separator line being inserted into the menu. You can use it anywhere inside a menu definition.

<Menu> The second menu keyword specifies the name of the menu being placed under tools. We gave it the name “TBSM” for IBM Tivoli Business Systems Manager.

<Mnemonic> Again, this specifies a shortcut to the menu name.

<Name> As mentioned, our new menu should appear as TBSM in the tools submenu.

<MenuItem> The MenuItem keyword specifies the entry in the menu tree that triggers the action. We gave it the name "TBSM_BulkUpload". You can specify additional IBM Tivoli Business Systems Manager–related extensions as new menu items under the IBM Tivoli Business Systems Manager submenu.

<ActionRef> This entry is the most important keyword in our menu definition as it defines the connection to the action definition. Remember, we named our action ‘launchbu’ and it was stored in the MyActions.xml file. This information forms the Actionref attributexlink:href='MyActions.xml#xpointer(id("launchbu"))'.

To activate the new menu, launch Web Console Security. As we write this book, there is no other way to activate Web console extensions.

Launch the security console using one of these methods:

� Using the NetView GUI. Select:Administer -> Security Administration -> Web Console Security

� Using nvsetup. Select:Configure -> Configure Web Server -> Configure Web Console Security

� Directly issue /usr/OV/bin/launch_securityconsole

In the console, select Roles, then the role where you want to activate the new entry. You should be able to see your new created menu in the list of menus, as in Figure 9-21 on page 317. Be sure you mark the new entry as active for the wanted role.


Figure 9-21 The Roles dialog with the new menu entry

In case either the action or the menu file is malformed, an error dialog as shown in Figure 9-22 will appear. Review your definitions and correct any errors.

Figure 9-22 Parsing error

You can find additional information in /usr/OV/securityconsole.log. Near the end of the log file, you will find entries such as the one shown in Example 9-20 on page 318, which further specifies the type and location of the error.


Example 9-20 Parsing errors in securityconsole.log

2002-11-26 13:53:38,762 [Thread-4] ERRORcom.tivoli.netview.securityconsole.server.JDOMHelper -

failed to parse byte stream -- org.jdom.JDOMException: Error on line 26: The element type "ArgList" must be terminated by the matching end-tag "</ArgList>".

2002-11-26 13:53:40,283 [AWT-EventQueue-0] ERROR com.tivoli.netview.securityconsole.server.User - 1.Failed to parse file "/usr/OV/www/webapps/netview/warf/MyActions.xml" -- Error on line 26: The element type "ArgList" must be terminated by the matching end-tag "</ArgList>".

If the security console is displayed and the menu is activated for all necessary roles, click File -> Save even if you did not change any entries. Saving will initiate a Web server restart and a reread of all console defintions.

To test the function of the new entry, open the NetView Web console using your favorite method. Figure 9-23 shows the new submenu in the Tools menu, the TBSM BulkUpload entry that we defined previously in this section.

Figure 9-23 NetView Web console and the new menu


Now you can trigger a bulk upload from the Web console. When you do, a browser window opens showing the result of the operation, as in Figure 9-24.

Figure 9-24 The resulting output

9.7.2 Extending the TBSM Java consoleIn 9.7.1, “Extending the NetView Web console” on page 312, we extended the NetView Web console. The other main tool you use when working with IBM Tivoli Business Systems Manager is the IBM Tivoli Business Systems Manager Java console. In working with the NetView interface, the IBM Tivoli Business Systems Manager Java console gives three menu entries under the Launch Submenu, as shown in Figure 9-25 on page 320, that you can use against a physical resource such as a workstation or a router. The entries provide various components of the NetView Web console:

NetView Console Launches the NetView Web console and displays the submap where the physical resource resides.

NetView Diagnostics Launches the NetView Web console and displays a diagnostics screen for the physical resource. In addition an initial ICMP echo request (ping) is issued against that resource.

NetView Object Properties Launches the NetView Web console and displays the object attributes of the resource as they are defined in the NetView object database.


Figure 9-25 The Launch submenu

Each display can be helpful in various situations, but sometimes you would rather display all the information at once when you launch the NetView Web console. We now show how this can be done.

How menu data is defined and executedThe menus that appear on the Java console are stored in IBM Tivoli Business Systems Manager’s object database. For more information about the database structure, see Chapter 3, “Database structure” on page 77.

In general, all NetView-related launch menu actions are formed and executed identically. Upon starting the IBM Tivoli Business Systems Manager Java console, the menu tree and method information are transferred to the local workstation along with data, regardless of whether a launch menu entry is available for a given resource.

As soon as you select an entry from the Launch submenu, the launch process is executed as shown in Figure 9-26 on page 321.


Figure 9-26 NetView Console launch process

The process is:

1. The Java console sends information about the menu entry selected and the physical resource to the Console Server.

2. The Console Server retrieves the necessary data, depending on the physical resource under investigation from the object database, and passes the data back to the Java console. The data can be different for the various resources. For example, the launch of the NetView diagnostics for an Ethernet switch may differ from a launch for a router.

3. The launch command invokes the launch.jar java application on the local workstation and passes the parameters to it. The passed parameters contain the target NetView Server, the resource under investigation, and the name of a NetView server-side script that supplies the requested action.

4. The server-side script, usually found under /usr/OV/webapps/netview/scripts, launches the NetView Web console through launch.jar and displays the results.

A real-life example of a new menu entryAs you can see from the previous chapter, a new menu entry meant to allow new or different actions against a network resource requires modification on both the IBM Tivoli Business Systems Manager side and the NetView side.

TBSM Console

NetView server

TBSM Database ServerTBSM Console Server

nvlaunch.jar

1. Request Launch entry

2. Launch command

3. R

equ

est

data

4. Populate console


As a real-life example, we show the steps you need to implement in order to provide a new menu that:

� Provides all three types of supported actions in a single launch of the Web console,

� Changes the order of the different panes inside the NetView Web console to display the diagnostic pane on top,

� Changes the diagnostics to run the more useful NetView quicktest instead of a simple ICMP echo request against the resource under test. The NetView quicktest is especially useful for IProuters. It checks all of the router’s displays and shows its status.

Here are the steps:

� On the NetView server, go to /usr/OV/www/webapps/netview/scripts. As shown in Example 9-21, you will find a few files with a .js extension. These are server scripts that are executed by the NetView Web server. A closer look at the names will reveal the actions the script is supposed to carry out:

diagnostics.js Provides the diagnostics pane in the Web console.

objectproperties.js Displays the NetView object properties pane in the Web console.

submapexplorer.js Displays the NetView submap where the object under investigation is located.

The remaining scripts shown in Example 9-21 are not used by IBM Tivoli Business Systems Manager.

Example 9-21 The existing server scripts

capecod:/usr/OV/www/webapps/netview/scripts #ls3beansalad.js diagnostics.js resolvetarget.jsREADME.txt objectproperties.js submapexplorer.js

A closer look at the file 3beansalad.js shows what the name implies: The script displays all three panes used by IBM Tivoli Business Systems Manager in a single script. You can check this by launching the script manually as shown in 9.6.3, “Testing the launch functions” on page 308. However, the panes’ order could be more useful than displaying the diagnostic pane overlapping the other two panes, as shown in Figure 9-27 on page 323.


Figure 9-27 3beansalad.js display

To rearrange the three panes:

� Make a copy of 3beansalad.js and give it a different name. For reference, it is listed in Example C-5 on page 574. We renamed ours TBSMsummary.js.

� Open the file with a text editor. Examining the script code, you can easily recognize the four sections in the script. The first three sections provide the data for the panes being displayed while the fourth section (just one line) displays the result.

� You don’t have to be fluent in JavaScript to move the sections that change the display order. For our example, we rewrite our script to open the submap explorer first, followed by the object properties pane, then the diagnostics pane. This places the diagnostics pane on top when the console is launched.

� In the diagnostics block, locate the statement:

diag.performTest("Test", "Ping", targetnode);

� Replace the Ping parameters by a call to Quicktest:

diag.performTest("Test", "QuickTest", targetnode);

Example 9-22 on page 324 shows the complete, revised script.


Example 9-22 TBSMsummary.js

/* TBSMsummary.js: This is a modified 3beansalad.js file * to demonstrate custom TBSM menus used in SG24-6610 * 3-dec-2002 glasi *//*************** First display the explorer submap **********?var mapconn = new Packages.com.tivoli.netview.mapconnector.client.MapConnector(protocol, hostname, port);if (!mapconn.isOkToSkipOpenMapDialog()) { var dialog = mapconn.createDialog(null); dialog.setVisible(true);}var mapport = mapconn.getMapServerPort();var mapname = mapconn.getMapName();if (0 != mapport) { var subexp = new Packages.com.tivoli.netview.maptree.client.submapexplorer.SubmapExplorer(); subexp.setProtocol(protocol); subexp.setHostName(hostname); subexp.setPort(port); subexp.setMapPort(mapport); subexp.setMapName(mapname); subexp.setTargetNode(targetnode); subexp.activate(); framefactory.addFrame(subexp, "Submap Explorer", "anm_wc_win_subexplorer");}/********************** second, display the object properties *******************/var objprop = new Packages.com.tivoli.netview.objectproperties.client.ObjectProperties();objprop.setProtocol(protocol);objprop.setHostName(hostname);objprop.setPort(port);objprop.resetTargetNode(targetnode);framefactory.addFrame(objprop, "Object Properties", "anm_wc_win_objprops");/*************** third launch a Quicktest against the node ******************/var diag = new Packages.com.tivoli.netview.diagnostics.client.Diagnostics();diag.setProtocol(protocol);diag.setHostName(hostname);diag.setPort(port);diag.performTest("Test", "QuickTest", targetnode);framefactory.addFrame(diag, "Diagnostics", "anm_wc_win_diagnostics");

Packages.com.tivoli.netview.client.global.NetView.bringToForeground();

� Save the script and test it as described in 9.6.3, “Testing the launch functions” on page 308. This should produce a NetView Web console that displays all three selected panes with the Quicktest diagnostic pane on top as in Figure 9-29 on page 327.


� Now, having the NetView part up and running, you have to provide IBM Tivoli Business Systems Manager with the correct information to actually launch it.

� On your database server, go to the \TivoliManager\bin directory. Locate the file nvlaunchconfig.sh, copy it, and give the copy a new name, for example newmenu.sh.

� Open the file with an editor. Assign

– the SQL server name– the SQL user account – the SQL password

to the top three variables in the script. (This likely has already been done, because we are using a copy of the nvlaunchconfig.sh script).

� From the add_entries and delete_entries sections in the script, remove all the diagnostics entries and the object properties entries. We will need just one block of definitions.

� In each AddAppLauncherEntry.sh line, replace the -n flag with a new name such as NVsum. We suggest keeping the last letter unchanged: NVConsR then becomes NVsumR, and so on.

� In each AddAppLauncherEntry.sh line, replace the value of the scripurl parameter by the path to our modified NetView Server script. In our example, replace submapexplorer.js by TBSMsummary.js

� In each AddAppLauncherMenuItem.sh line, replace the -n and -r flag values with the name assigned to the AddAppLauncherEntry.sh -n flag, which in our case is NVsum. As before, we suggest you keep the last letter as is.Then replace the description supplied with the -l flag by a new menu name, such as “NetView Overview” in our example.

For reference, Example 9-23 shows an example line for each command type being executed inside newmenu.sh.

Example 9-23 The modified command parameters

AddAppLauncherEntry.sh -S $SQLSERVER -U$SQLUSER -P$SQLPWD -nNVsumR \-l"Windows NT" -cSockets -m8899 -x8899 -w5000 -r18 \-g"cmd /c %NVWC_HOME%\bin\nvlaunch.bat port 8899 > nvlaunch.log 2>&1" \-a"serverinfo=%nvserver% \scripturl=/netview/scripts/TBSMsummary.js sctargetnode=%name% tbsm=true"

AddAppLauncherMenuItem.sh -S $SQLSERVER -U$SQLUSER -P$SQLPWD -nNVsumR \-cROUT -l"NetView Overview" \-r"NVsumR,name=%IPHostName%,nvserver=%this.LookupNetViewURLs%"

DeleteAppLauncherMenuItem.sh -S $SQLSERVER -U$SQLUSER -P$SQLPWD -nNVsumR -r


DeleteAppLauncherEntry.sh -S $SQLSERVER -U$SQLUSER -P$SQLPWD -nNVsumR \-l"Windows NT"

Carefully review the script. Then run the script and provide the add parameter to the command. As it runs, the script will issue messages that rows have been successfully added and a warning that the parent menu already exists.

Figure 9-28 The new menu entry

Now you can open the IBM Tivoli Business Systems Manager Java console. Select Console -> Open All Resources. Under the Enterprise:NetView tree, select a physical resource, such as a PC or a router, and right-click to open the context menu. A launch menu should be available. When selected, you can see your new Network Overview menu as shown in Figure 9-28.

Select NetView Overview and you should see the all-in-one Web console shown in Figure 9-29 on page 327 with the Quicktest results at the top.


Figure 9-29 The Web console display launched by the new menu


Part 3 z/OS integration

This part of the book discusses the implementation of the z/OS component for IBM Tivoli Business Systems Manager. The chapters are:

� Chapter 10, “z/OS installation and configuration” on page 331 discusses the necessary installation and configuration for setting up the connection to z/OS from IBM Tivoli Business Systems Manager servers.

� Chapter 11, “z/OS data feeds and discovery” on page 347 describes the implementation and discovery of some z/OS-based data feeds. The feeds are:

– System Automation for z/OS– DB2– IMS– CICS with CICSPlex– TWS for z/OS– RODM– RMF– SMS– DFSMS/hsm– WebSphere HTTP Server

Part 3


Chapter 10. z/OS installation and configuration

This chapter describes the steps to implement Source/390 on a z/OS platform for integrating the mainframe environment into IBM Tivoli Business Systems Manager.

In this chapter, the following topics are discussed:

� 10.1, “Source/390 implementation” on page 332

� 10.2, “Setting up Tivoli NetView for z/OS” on page 338

� 10.3, “Implementing the Event Server” on page 342

10


10.1 Source/390 implementationThis section discuss the implementation of the Source/390 subsystem on the z/OS. The examples here show the implementation on our lab system SC69. The tasks described here assume that you already have the necessary software prerequisites and have completed the SMP/E installation of IBM Tivoli Business Systems Manager for z/OS. The topics are:

� 10.1.1, “Pre-installation tasks” on page 332

� 10.1.2, “Installing Source/390” on page 333

� 10.1.3, “Bulk discovery configuration” on page 337

� 10.1.4, “Source/390 tuning considerations” on page 337

� 10.1.5, “Source/390 security” on page 338

10.1.1 Pre-installation tasksBefore you activate the Source/390 subsystem in your mainframe, you may need to collect some information from your system. You can use the TSO command prompt, typically in ISPF option 6, to issue the command similar to the one in Example 10-1.

Example 10-1 Running the GTMINFO command

CALL 'GTMV2R1.SGTMMODS(GTMINFO)' SMFID: SC69 SYSTEM_NAME: SC69 NETID: USIBMSC.SC69M IPADDRESS: 9.12.6.22 HOSTNAME: WTSC69.ITSO.IBM.COM READY

In Example 10-1, IBM Tivoli Business Systems Manager for z/OS is installed with the high-level qualifier (hlq) of GTMV2R1. It collects the information, such as SMFID and TCP/IP data, that is needed for further setup of Source/390.

Additionally, it is helpful to gather the names of the existing managed endpoints that will provide the data feeds that you will be integrating into your IBM Tivoli Business Systems Manager environment. Table 10-1 on page 333 provides an example of this.


Table 10-1 z/OS data sources

Determine the method of communication to be used between the Source/390 components and the IBM Tivoli Business Systems Manager workstation server components. This will be either TCP/IP or SNA LU6.2. TCP/IP is replacing many SNA communication environments and is relatively straightforward to implement. This scenario will use TCP/IP communication.

10.1.2 Installing Source/390The IBM Tivoli Business Systems Manager for z/OS is installed using the System Modification Program Extended (SMP/E) tool as described in the program directory. Successful installation will load the following data sets:

� hlq.SGTMDATA� hlq.SGTMEXEC� hlq.SGTMMODS� hlq.SGTMMSGS� hlq.SGTMSAMP

Again, we use GTMV2R1 as the high-level qualifier. To add the SGTMMODS to the APF authorized list, edit IEAAPFxx or modify PROGxx. We choose to modify PROGxx, which facilitates dynamic update. Alternately, you can define the APF authorization using the following command:

SETPROG APF,ADD,DSN=GTMV2R1.SGTMMODS,VOL=ZOS3DK

Now we can set up the address spaces start-up procedure and parameters. Source/390 has three address spaces, the dataspace, object server, and object pump. For customization purposes, we create a customizable data set that will

Resource Name

Automation Products:� System Automation for OS/390� RODM

SC69ARODM

MVS MVS console, RMF, Omegamon for MVS

Job Scheduler TWSC

DB2 DSNT, DSN2

IMS IMSQ

CICSPlex/SM SCSCCMAS

Storage Management DFSMSHSM, XRC, SMS

WebSphere /etc/httpd.conf

Chapter 10. z/OS installation and configuration 333

contain the configuration parameters for each system. We call the data set GTMV2R1.LOCAL.PARMLIB.

In our lab, the parameter member in the PARMLIB is PxSSSSyy where:

Px The parameter type: PD for dataspace, PS for object server and PP for object pump.

SSSS The SMF id of the z/OS image.yy The instance of the Source/390. The default is instance 0,

while we can have up to 99 instances (mainly for testing).

Source/390 dataspace installationThe dataspace acts as an intermediate repository for the event messages. Copy the sample GTMDSPC member of hlq.SGTMSAMP into a system PROCLIB, and modify the JCL to reflect the correct hlq references for Source/390 libraries. Our GTMDSPC is shown in Example 10-2.

Example 10-2 GTMDSPC startup procedure

//GTMDSPC PROC MBR=PD&SYSNAME.00 //* //DSPC EXEC PGM=GTMACC17,PARM=&MBR @P1C //STEPLIB DD DISP=SHR,DSN=GTMV2R1.SGTMMODS //ACC1PARM DD DISP=SHR,DSN=GTMV2R1.LOCAL.PARMLIB

This started task uses a parameter member. The sample member is PARMDSPC from hlq.SGTMSAMP. We copy this member to the LOCAL.PARMLIB and call it PDSC6900. In Example 10-2, the &SYSNAME indicates the system name as the symbolic substitution for the system name in the sysplex so that we can use the same start-up procedure for all system images.

The content of our PDSC6900 is shown in Example 10-3. The DATASPACESIZE parameter shipped in the PARMDSPC member is obsolete, as the size is now derived from the combined queue sizes.

Example 10-3 Dataspace parameters

********************************************************************** DATASPACE PARAMETERS **********************************************************************DATASPACESIZE=10000000 OSQUEUESIZE=100 OPQUEUESIZE=10 LOGQUEUESIZE = 50


Source/390 object server installationThe object server handles communication between Source/390 and the workstation server. Copy the sample GTMSRVR member from hlq.SGTMSAMP into a system PROCLIB and modify the JCL to reflect the correct hlq references for Source/390 libraries. Our GTMSRVR is shown in Example 10-4.

Example 10-4 GTMSRVR startup procedure

//GTMSRVR PROC MBR=PS&SYSNAME.00 @P1A99 //*//SRVR EXEC PGM=GTMMAINS @P2C//STEPLIB DD DISP=SHR,DSN=GTMV2R1.SGTMMODS//AOPLOG DD SYSOUT=*,DCB=(LRECL=136,BLKSIZE=1004,RECFM=VB)//AOPSYSIN DD DISP=SHR,DSN=GTMV2R1.LOCAL.PARMLIB(&MBR) @P1C//SYSOUT DD DUMMY @P1A//SYSTCPD DD DISP=SHR,DSN=TCP.&SYSNAME..TCPPARMS(TCPDATA) @P1A

Include the correct SYSTCPD that refers to your TCP/IP data that can identify the correct TCP/IP subsystem in your environment.

The sample parameter for the GTMSRVR is in the member PARMSRVR, which uses SNA LU6.2 implementation. If you use a TCP/IP implementation, you must use the sample PARMSRIP member. Our sample PSSC6900 is shown in Example 10-5, which is derived from the PARMSRIP.

Example 10-5 Object Server parameter

********************************************************************* * * STARTUP PARMS FOR TBSM OBJECT SERVER * PROTOCOL=IP TCPIP_ADDRESS=9.3.5.11 Event handler server IP address TCPIP_PORT=1022 Listening port for ASIMVSIPOSListenerSvcTCPIP_SERVER_PORT=1024 Listening port for the object server VALIDCLIENT=9.3.5.11 IP address of host running IP sender svcLOG1=GTMV2R1.SC69N.SRVR.LOG1 Object server event log LOG2=GTMV2R1.SC69N.SRVR.LOG2 Object server event log REGTRACE=YES Writes registration msgs to AOPLOG

As shown in Example 10-5, two log files are used by the object server. Modify hlq.SGTMSAMP(DEFLOGS) to reflect the correct hlq references for the object server log data sets, and run the job to allocate the log data sets.

The TCPIP_PORT control card must be the same value as defined in the makemvscomponents’s -v parameter, which specifies the MVS Listener Service IP port. The TCP_SERVER_PORT control card must be the same value as defined


in the makemvscomponents’s -w parameter, which specifies (along with the z/OS IP address or host name) the MVS Sender Service IP port.

An optional TCPIP_ADDRESS_BACKUP and TCPIP_PORT_BACKUP control card may be coded to specify a backup connection for communication with the ASIMVSIPOSListenerSvc.

Source/390 object pump installationThe object pump performs data collection and traps events for monitored objects. Copy the sample GTMPUMP member from hlq.SGTMSAMP into a system PROCLIB and modify the JCL to reflect the correct hlq references for Source/390 libraries. Either remove the DD cards for the REXX alternate runtime library if you have REXX run time Library installed on your system, or modify these DD cards with the correct hlq reference and ensure that this data set is APF authorized. Our GTMPUMP member is shown in Example 10-6.

Example 10-6 GTMPUMP startup procedure

//GTMPUMP PROC MBR=PP&SYSNAME.00//*//* REF : SAMPLE PROCEDURE TO RUN THE PUMP//*//PUMP EXEC PGM=GTMMAINP,TIME=1440,REGION=400M @P1C//STEPLIB DD DISP=SHR,DSN=GTMV2R1.SGTMMODS <== AUTH LIB//* DD DISP=SHR,DSN=REXX.V1R3M0.SEAGALT <== AUTH LIB// DD DISP=SHR,DSN=CICSTS13.CPSM.SEYUAUTH <== AUTH LIB//AOPAUTH DD DISP=SHR,DSN=GTMV2R1.SGTMMODS <== AUTH LIB//* DD DISP=SHR,DSN=REXX.V1R3M0.SEAGALT <== AUTH LIB//AOPEXEC DD DISP=SHR,DSN=GTMV2R1.SGTMEXEC//AOPOUT DD SYSOUT=A,DCB=(LRECL=404,BLKSIZE=1004,RECFM=VB)//AOPLOG DD SYSOUT=A,DCB=(LRECL=136,BLKSIZE=1004,RECFM=VB)//AOPEXT DD DUMMY//SYSOUT DD DUMMY <== FOR SORT//GTMJCL DD DISP=SHR,DSN=GTMV2R1.LOCAL.PARMLIB <== Job submission//AOPSYSIN DD DISP=SHR,DSN=GTMV2R1.LOCAL.PARMLIB(&MBR)

This started task uses a parameter member similar to the sample member PARMPUMP. We modify this and call it PPSC6900. Our initial PPSC6900 is shown in Example 10-7.

Example 10-7 Object pump parameter

********************************************************************* SUBSYSTEM_NAME=TM69 TM + &SYSCLONE. CONSOLE=TM39069 TM390 + &SYSCLONE. MAX_TRAPS=10000 MAX # TRAPS TO SUPPORT TERMINAL_PREFIX=TM390 FIXED PART OF 3270 POOL TERMINAL NAMES


NUMBER_OF_TERMINALS=0 # VIRTUAL TERMINALS IN POOL MODEL2_LOGMODE=D4A32782 LOGMODE NAME FOR MODEL2 VIRTUAL TERMINALSMODEL3_LOGMODE=D4A32783 LOGMODE NAME FOR MODEL3 VIRTUAL TERMINALSMODEL4_LOGMODE=D4A32784 LOGMODE NAME FOR MODEL4 VIRTUAL TERMINALSMODEL5_LOGMODE=D4A32785 LOGMODE NAME FOR MODEL5 VIRTUAL TERMINALSLOG_SCREENS=NO WRITE SCREEN IMAGES TO AOPLOG EDI_BUFFER_SIZE=2048 EDI BUFFER SIZE IN K SUBSYSTEM_MAXTHREADS=3 MAX CONCURRENT COMMANDS MAXTHREADS_PROMPT=NO NO PROMPT WHEN AT MAX THREADS * OMEGAMON_REFRESH_PERIOD=00:04:00 LEXSY REFRESH INTERVAL OMEGAMON_EXCEPTION_CNTRL=ALL SEND ALL EXCEPTIONS TRAP_REPORT=SYSOUT(A) REPORT TO SYSOUT(X) LOG_FILE=SYSOUT(A) LOGFILE TO SYSOUT(X) LOG_FILE_RECORD_LENGTH=200 LRECL FOR LOG FILE LOG_SPIN_INTERVAL=04:00:00 SPOOL LOG EVERY 4 HOURS COMMAND_PREFIX=TM69 TM + &SYSCLONE.

The CONSOLE_MSCOPE parameter defaults to LOCAL, which specifies that only messages from the image where Source/390 is running are captured. For SYSPLEX environments, specifying ALL on this control card causes messages from all images within the SYSPLEX to be captured.

This member will be further customized for each of the feeds from each systems.

10.1.3 Bulk discovery configurationBulk discovery is the process for batching load resource information from the various data sources into the IBM Tivoli Business Systems Manager database. The GTMAOPE0 utility is used to send this data to the IBM Tivoli Business Systems Manager server running the ASIMVSIPListenerSvc service.

The Source/390 common global variables used by the GTMAOPE0 utility are defined in hlq.SGTMSAMP(IHS$PARM). Modify the IHS$DISC_NVTCP/IP control card as shown below with the TCP/IP address of the host running the IP listener service. Modify the JOBCARD in hlq.SGTMSAMP(IHS$DISC) as necessary.

IHS$DISC_NVTCP/IP TCP/IP_ADDRESS=9.3.4.55

10.1.4 Source/390 tuning considerationsSource/390 uses REXX heavily and provides its own version of the IRXANCHR table located in hlq.SGTMMODS. This table reserves storage for REXX environments and is defined with 4000 entries, which is quite adequate for most environments. Be aware that if another version of this table is being run due to a


LNKLST or concatenation order, you may be running with fewer entries defined. In a later chapter covering the Tivoli NetView for z/OS data source integration, we will verify the actual REXX environment utilization.

10.1.5 Source/390 securityThe user ID that the Source/390 started tasks run under must have ALTER authority to the object server log data sets as well as READ access to the remaining Source/390 data sets.

If using the RACF class OPERCMDS, then the MVS.MONITOR resource must be defined and the ID that the GTMPUMP started task runs under must have READ access to it. Use the following command:

permit mvs.monitor class(opercmds) id(STC) access(read)

10.2 Setting up Tivoli NetView for z/OSMany of the data sources use IBM Tivoli NetView for z/OS as the interface to get the feed into IBM Tivoli Business Systems Manager. This is because IBM Tivoli NetView for z/OS provides a programmable interface with an automation capability that is needed to perform monitoring and management.

The data sources that use IBM Tivoli NetView for z/OS are:

� System Automation for OS/390 Version 2.1� CICSPlex� DB2� IMS� RODM

This section describes the common configuration steps for IBM Tivoli NetView for z/OS. The configuration for IBM Tivoli NetView for z/OS is mostly independent from the feeds it manages. Specific configuration steps are provided related to the feeds itself in Chapter 11, “z/OS data feeds and discovery” on page 347.

The tasks that are needed to customize IBM Tivoli NetView for z/OS are:

� 10.2.1, “Modify the NetView started task procedure” on page 339

� 10.2.2, “Modify the DSIPARM members” on page 339

� 10.2.3, “Enable the PPI connection” on page 339

� 10.2.4, “Enable NETCONV connection” on page 340

� 10.2.6, “Tuning considerations” on page 341


10.2.1 Modify the NetView started task procedureModify the IBM Tivoli NetView for z/OS startup procedure to concatenate the IBM Tivoli Business Systems Manager libraries as shown in Table 10-2.

Table 10-2 Modification to IBM Tivoli NetView for z/OS startup procedure

10.2.2 Modify the DSIPARM membersThis section describes the required modification of the NetView DSIPARM members.

� Modify hlq.SGTMSAMP(IHS$MAT) to comment out the unused interfaces and include this member at the top of the current message table. Typically add in the DSITBL01 a line such as

%INCLUDE IHS$MAT

� Add an include statement in DSICMD for IHS$CMD, such as

%INCLUDE IHS$CMD

� Modify hlq.SGTMSAMP(IHS$OPF) to comment out the unused interface(s). Add an include statement in DSIOPF for IHS$OPF, such as:

%INCLUDE IHS$OPF

� Modify hlq.SGTMSAMP(IHS$CAT2) to comment out the unused interface(s) and include this member in CNMSCAT2 or your local command authorization table.

� Ensure that your local version of CNMSCAT2 permits the groups NVOPS1 and NVOPS2 to the MVS and EXCMD commands.

10.2.3 Enable the PPI connectionUncomment the statement in the object pump parameter member to enable the program-to-program interface (PPI) to IBM Tivoli NetView for z/OS as shown in Example 10-8 on page 340.

DD name TBSM library Notes

STEPLIB hlq.SGTMMODS TBSM modules

DSICLD hlq.SGTMEXEC REXX programs

DSIPARM hlq.SGTMSAMP sample members

DSIMSG hlq.SGTMMSGS message files


Example 10-8 Enabling PPI for TBSM

* To activate the NetView PPI interface uncomment * the following line * PPI=YES

The result from the DISPPI command issued in NetView indicates that the default PPI receiver name, NETVAOP, is active, as shown in Example 10-9. Note that the name NETVAOP is reserved.

Example 10-9 DISPPI output

DISPPIRECEIVER RECEIVER BUFFER QUEUED TOTAL STORAGE RCVRIDENTITY STATUS LIMIT BUFFERS BUFFERS ALLOCATED ASID-------- -------- ---------- ---------- ---------- ---------- ----NETVALRT ACTIVE 1000 0 3 0 005FISTMTRCV ACTIVE 500 0 38 0 001ADSIMCAT ACTIVE 25 0 0 0 005FSC69NSCO ACTIVE 1000 0 0 0 005FSC69NHTM ACTIVE 1000 0 0 0 005FNETVRCV ACTIVE 500 0 103 0 005FDSIQTSK ACTIVE 100 0 0 0 005FNETVAOP ACTIVE 1000 0 405 0 0071IHSATEC ACTIVE 5000 0 21 0 006DEND OF DISPLAY

10.2.4 Enable NETCONV connection A NETCONV connection between the IBM Tivoli Business Systems Manager task server and the NetView for z/OS focal point enables commands to be issued from the IBM Tivoli Business Systems Manager console, executed in NetView, and the response returned to a command response window on the IBM Tivoli Business Systems Manager console. The steps to configure a NETCONV session from NetView for z/OS are:

1. Verify that the DUIFPMEM member in DSIPARM contains the following parameters:

TCPANAME The name of the local TCP/IP stack.

USETCP/IP Must be YES.

SOCKETS Specifies the number of supported connections.

PORT Listening port number, typically 4020. This number must match the tserver_390 parm on the task server.

2. Verify that the DUIIGHB member in DSIPARM contains the parameter TCPANAME that identify the name of the local TCP/IP stack.


Start the NETCONV session to the task server after the workstation steps have been completed for NETCONV communication. The format of this command and the response are shown in Example 10-10. The IP address is for the host running the task server, typically the database server.

Example 10-10 NETCONV connection

NETCONV ACTION=START,IP=ibmtiv5.itsc.austin.ibm.comDUI401I NETCONV COMMAND PROCESSED SUCCESSFULLY. COMMUNICATION TO IP ibmtiv5:4020 (9.3.4.55:4020) STARTED.

This NETCONV connection must be available continuously for IBM Tivoli Business Systems Manager to send commands to the z/OS system, so it must be issued from an AUTOTASK. We use AUTO2 to keep this connection, using the EXCMD command to let the NETCONV command be executed by AUTO2.

10.2.5 Enabling communication between NetView systemsFor commands to be available to all z/OS systems, these systems must be running IBM Tivoli NetView for z/OS. The system may be running a procedural version of IBM Tivoli NetView for z/OS instead of the enterprise version that is required for the focal point.

IBM Tivoli NetView for z/OS uses the RMTCMD mechanism to ship commands to remote nodes. This connection requires that NetView can authenticate the operator and to have knowledge of the remote nodes.

10.2.6 Tuning considerationsThese are the recommended tuning considerations:

� REGION size

Changing the region size to 0 enables the IBM Tivoli NetView for z/OS program to allocate the storage it needs.

� DSISVRT VSAM files

IMS data source integration uses the save/restore VSAM files. Review and modify size if necessary.

� IRXANCHR

Issuing the IHS$DBUG ENVIRO command from IBM Tivoli NetView for z/OS shows the number of REXX environments in use.

� DSICTMOD

Issue QRYGLOBL COMMON from IBM Tivoli NetView for z/OS, and increase the number of common global variables if necessary using CNMS0055.


� DEFAULT

Set the default setting of AUTOLOGN to YES. This enables IBM Tivoli NetView for z/OS to start an autotask for an operator who is not currently logged on to it. This is used when attempting to issue commands to NetView from the IBM Tivoli Business Systems Manager console through the NETCONV session.

10.3 Implementing the Event ServerIn this section, we discuss Event Server implementation using TCP/IP. We will not implement SNA connectivity in this book. This means that we do not need the SNA server or the host integration server, so the Event Server can be used to distribute the load for sending and receiving messages from z/OS.

The prerequisite software that must be installed in the Event Server is:

� Microsoft Host Integration Server or Microsoft SNA Server (even though we will be running TCP/IP connection only)

� Microsoft Windows NT Resource Kit Supplement 3

� MKS Toolkit

After these prerequisites are implemented as discussed in 6.2, “Prerequisite software components installation” on page 154, we can install the IBM Tivoli Business Systems Manager base component. The installation steps are similar to the installation of other IBM Tivoli Business Systems Manager servers discussed in Chapter 6, “Base services implementation” on page 149. The only component that we have to choose is the Event Server component.

Once the Event Server is installed, the following services should be active:

� Tivoli BSM Database Validater

� Tivoli BSM Enqueue Proxy Server

� Tivoli BSM MVS Upload Rule Server

The following tasks have to be performed:

1. Setting up the high-level objects, you can either create them manually or use the bulk object discovery as discussed in 2.4.4, “Bulk discovery” on page 62. We use the bulk discovery method with the input file shown in Example 10-11. This is performed on the database server.

Example 10-11 Input file for the high level load

Mainframes/ITSO Enterprise/ITSO//SC64Machine//Primary//SC64/Mainframes/ITSO Enterprise/ITSO//SC66Machine//Primary//SC66/


Mainframes/ITSO Enterprise/ITSO//SC69Machine//Primary//SC69/Mainframes/ITSO Enterprise/RETAIN-Test//9672-Y56//Primary//MVS1/

2. Still in the database server, we must clean up the ASIRuleSvc..ObjectSync table, which contains the synchronization time for the MVS Upload rule server. Every time a new OS object is created, you must delete the rows in this table and restart the MVS Upload Rule Server. You can use the SQL Query Analyzer to run the following SQL command:

delete from ASIRuleSvc..ObjectSync

3. We thenopen a IBM Tivoli Business Systems Manager console window to check the Upload Enable box on the property page of each OS object. It is found in the Source/390 page as shown in Figure 10-1 on page 344.


Figure 10-1 Property page of OS object to enable upload

Alternately you can run a query to enable upload using the SQL Query Analyzer and run the following SQL script:

Update OS_A set _UploadEnabled = 1 where deleted = 0

4. After all the mainframe operating systems are defined, we create the mainframe services in the Event Server. From the Event Server, invoke the MakeMVSComponent.ksh command for each of the OS objects. The execution is shown in Example 10-12 on page 345.


Example 10-12 Running makeMVSComponent.ksh

C:\>sh makeMVSComponents -BSC64 -OSC64 -wWTSC64.ITSO.IBM.COM:1024 -v1022Validating component code(s): [EH] [LS] [SS] [FR]Using Database Host=[ibmtiv5], MVS Host=[IBMTIV3]Found OS id=0000020006 for [SC64]Populating database table MVSSenderSvcMap for os_id=0x000002, svc_host=[IBMTIV3], svc_name=[SC64]Creating registry settings for the Event Handler...Creating registry settings for the IP Listener...Creating registry settings for the IP Sender Service...Creating registry settings for the File Receiver...Copying the Event Handler service bootstrap executable to the proper location/name...//IBMTIV3/C$/TivoliManager/bin/ASIServiceApp.exe -> //IBMTIV3/C$/TivoliManager/bin/services/ASIEH_SC64.exeCopying the Sender Service service bootstrap executable to the proper location/name...//IBMTIV3/C$/TivoliManager/bin/ASIServiceApp.exe -> //IBMTIV3/C$/TivoliManager/bin/services/ASISS_SC64.exeCopying the File Receiver service bootstrap executable to the proper location/name...//IBMTIV3/C$/TivoliManager/bin/ASIServiceApp.exe -> //IBMTIV3/C$/TivoliManager/bin/services/ASIFR_SC64.exeCreating service [ASIMVSEventHandlerSvc-SC64]...Creating service [ASIMVSIPSenderSvc-SC64]...Creating service [ASIFileReceiverSvc-SC64]...Creating service [ASIMVSIPOSListenerSvc]...Done.

The MakeMVSComponent command creates new services in the Event Server:

– Tivoli BSM MVS IP OS Listener– Tivoli BSM MVS EventHandler-OSid– Tivoli BSM MVS IP SenderSvc-OSid– Tivoli BSM MVS File Received-OSid

From these services, make Tivoli BSM MVS IP OS Listener, Tivoli BSM MVS EventHandler-OSid, and Tivoli BSM MVS IP SenderSvc-OSid autostarting. The File Receiver is not needed.

5. Start the Source/390 subsystems in the z/OS. Verify that communication works both ways. (See 2.4.3, “Object registration process” on page 60.)


Chapter 11. z/OS data feeds and discovery

This chapter discusses various data feeds that supply IBM Tivoli Business Systems Manager with status information about components as discussed in 11.1, “z/OS data feeds overview” on page 348. Each feeds must be configured to supply data, and the IBM Tivoli Business Systems Manager will perform discovery so that the resource can be managed.

The feeds are:

� 11.2, “System Automation for OS/390 Version 2.1” on page 349

� 11.3, “Database 2 (DB2) for z/OS” on page 353

� 11.4, “Information Management System (IMS)” on page 357

� 11.5, “CICSPlex System Manager Version 2.2” on page 361

� 11.6, “Tivoli Workload Scheduler for z/OS” on page 372

� 11.7, “Resource Object Data Manager” on page 376

� 11.8, “Resource Measurement Facility (RMF)” on page 381

� 11.9, “System Managed Storage (SMS)” on page 385

� 11.10, “DFSMS Hierarchical Storage Manager” on page 388

� 11.11, “WebSphere HTTP Server for OS/390” on page 391

11


11.1 z/OS data feeds overviewIBM Tivoli Business Systems Manager integrates topology and status data from many existing data sources that are already installed on your z/OS environment and presents that data on a single console. In this chapter we discuss the data feed and discovery integration process for several endpoint managers on the z/OS environment. The structural feeds are shown in Figure 11-1.

Figure 11-1 Feeds for z/OS systems

Initial discovery of the data from the various data sources results in a resource view. The resources from this view can then be dragged and dropped into

z\OS

TBSM SOURCE/390

SOURCE/390Object Pump

WebSpherefor OS/390

DFSMShsm

SMS

XRC

MVSConsole

Messagesand

Commands

CICSPlex SystemManager for OS/390

Resource ManagementFacility

CICS Transient Data


CICSPlex

IMS

DB2

System Automation forOS/390 V2R1

Tivoli NetViewfor z/OS

CPSM API

GPMSERVE

External DataInterface (EDI)

Program-to-program

Interface (PPI)

SOURCE/390 Dataspace

SOURCE/390 Object Server

RODM

EKGNotify


Business System Views (BSVs) that represent key business processes. Key business processes most likely span multiple platforms within the enterprise. When IBM Tivoli Business Systems Manager is configured to disover both distributed and mainframe environments, then resources from both platforms that comprise your business process can be dragged and dropped into a BSV. Discovery and data source integration into IBM Tivoli Business Systems Manager is the foundation that additional functionality will be built on to provide a complete enterprise management solution.

The discussion in this chapter contains setup and discovery of mainframe data sources, such as:

� System Automation for OS/390 Version 2.1

� Resource Object Data Manager (RODM)

� Tivoli Workload Scheduler for z/OS

� DB2

� IMS

� CICSPlex/SM

� DFSMShsm™ and System Managed Storage (SMS)

� Resource Management Facility

� WebSphere HTTP Server

11.2 System Automation for OS/390 Version 2.1System Automation for OS/390 is the data source that integrates the discovery and monitoring of the started task and subsystem environment on z/OS into IBM Tivoli Business Systems Manager.

11.2.1 ConceptFigure 11-2 on page 350 shows the conceptual component of the System Automation for OS/390 connection to IBM Tivoli Business Systems Manager.

Note: IBM Tivoli Business Systems Manager supports more data feeds than those listed here. These are the data feeds that we had the time to test and evaluate.

Chapter 11. z/OS data feeds and discovery 349

Figure 11-2 System Automation for OS/390 2.1 connection to TBSM

The primary interface between SA OS/390 and Source/390 is the program-to-program interface (PPI). This interface registers a receiver ID with the IBM Tivoli NetView for z/OS program-to-program interface to communicate with the Source/390 object pump.

When SA OS/390 is started, the Message Automation Table IHSSMAT initializes and invokes IHSSSTRT. IHSSSTRT invokes IHSSINIT for the initial discovery and registers IHSSOBSX as the status observer. Applications defined to the SA OS/390 control file have their status monitored by the status observer component of the Automation manager. IBM Tivoli Business Systems Manager IHSSOBSX registers itself as the status observer to forward status changes to the object pump. The status observer reports the resource and status information to IBM Tivoli Business Systems Manager over the PPI.

The external data interface (EDI) is also available but is not as seamless in its implementation. This interface can be utilized to support customized automation messages to be reported to IBM Tivoli Business Systems Manager. Systems Automation for OS/390 version 1.3 uses the EDI interface. We will not discuss this interface here.

11.2.2 Integration setup The steps to install the IBM Tivoli Business Systems Manager interface to SA OS/390 are:

1. Define auto-operator entries for the IBM Tivoli Business Systems Manager autotasks IHSSAUT1 and IHSSAUT2 to your automation active control file.

NetView System Automation

TBSMObject Pump

PPI

IHSSOBSX

IHSSSTRT

IHSSMAT

IHSSDISC

IHSMSG

statuschange

IHSSBCPJBulk

DiscoveryData

IHSSINIT

discovery


2. Modify the parameter for the object pump.

– Add the following control card to the PARMPUMP parameter member:

SA390_JOBNAME=stcname

where stcname is the started task name for the SA OS/390.

– Modify the existing control card in the PARMPUMP parameter member to increase the EDI buffer size to 5000.

EDI_BUFFER_SIZE=5000

3. Modify IBM Tivoli NetView for z/OS members to include IBM Tivoli Business Systems Manager definitions for Systems Automation for z/OS:

– Ensure that the include statement for the SA OS/390 message automation table is uncommented in hlq.SGTMSAMP(IHS$MAT) for the line:

%INCLUDE IHSSMAT

– Ensure that the include statement for the SA OS/390 OPF member is uncommented in hlq.SGTMSAMP(IHS$OPF) for the line:

%INCLUDE IHSSOPF

– Ensure that the GROUP authorization statements for the SA OS/390 operators are uncommented in hlq.SGTMSAMP(IHS$CAT2) for the lines:

GROUP NVOPS1 IHSSAUT1,IHSSAUT2 GROUP NVOPS2 IHSSAUT1,IHSSAUT2

11.2.3 Object discoveryThe discovery of SA OS/390 resources is an automatic function that happens on the startup of SA OS/390 or when the ACF REFRESH command is run. You can also manually initiate discovery by running the pre-discovery IHSSDISC command and then run the job IHSSBCPJ.

Example 11-1 shows the result of running IHSSDISC for initial pre-discovery.

Example 11-1 Running IHSSDISC

IHSSDISC NETVUSER.TBSM69.SA390.DATAIHS703I GATHERING DATA - INGLISTIHS703I GATHERING DATA - DISPSTATIHS703I GATHERING DATA - UNLOADING AUTOMATION MANAGERIHS703I GATHERING DATA - VTAMOPTSIHS703I GATHERING DATA - XCFIHS702I IHSSDISC : END OF PROCESSING


The discovery result is a PDS with the following members: INGLIST, DISPSTAT, INGRVTPO, VTAMOPTS, XCF. These members correspond to the output of the following commands:

PIPE NETV INGLIST OUTMODE=LINEPIPE NETV DISPSTAT ALL2CONS=YES OUTMODE=LINE PIPE NETV INGRVTPO NETOP1 GET_DATAPIPE CC ROUTE *ALL,D NET VTAMOPTS,OPTION=(SSCPNAME,NETID)PIPE CC MVS D XCF

We can then run the IHSSBCPJ to send the output as BCP format to the Tivoli BSM MVSIPListener process. Our modified IHSSBSCP is shown in Example 11-2.

Example 11-2 Modified IHSSBCPJ

//IHSSBCPJ JOB ,SA390DISCOVERY,CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)//*---------------------------------------------------------------------//*// SET SAINDSN='NETVUSER.TBSM69.SA390.DATA'// SET BCPOUT='NETVUSER.TBSM.BCPOUT' // SET TBSMHLQ='GTMV2R1' //*//* CREATE BCP FILE//*//STEP1 EXEC PGM=IRXJCL,PARM='IHSSBCP'//SYSEXEC DD DISP=SHR,DSN=&TBSMHLQ..SGTMEXEC//SYSTSPRT DD SYSOUT=*//OUTBCP DD DSN=&BCPOUT,DISP=(,CATLG),// SPACE=(CYL,(1,1)),// DCB=(RECFM=VB,LRECL=400,BLKSIZE=32760)//DISPSTAT DD DISP=SHR,DSN=&SAINDSN(DISPSTAT)//INGLIST DD DISP=SHR,DSN=&SAINDSN(INGLIST)//INGRVTPO DD DISP=SHR,DSN=&SAINDSN(INGRVTPO)//VTAMOPTS DD DISP=SHR,DSN=&SAINDSN(VTAMOPTS)//*//* FTP BCP FILE TO IBM TIVOLI BUSINESS SYSTEMS MANAGER SERVER//*//STEP2 EXEC PGM=GTMAOPE0,COND=(4,LT,STEP1)//STEPLIB DD DISP=SHR,DSN=&TBSMHLQ..SGTMMODS//SYSPRINT DD SYSOUT=*//SYSUT1 DD DISP=SHR,DSN=&BCPOUT//SYSIN DD *TCP/IP_NAME=IBMTIV5.ITSC.AUSTIN.IBM.COMTCP/IP_PORT=1021CODEPAGE=037BUFFERSIZE=1TIMEOUT=30CONVERT=NO


TEXT=NOCOMMAND=SA390DISCOVERYFORMAT=X'07'/*

The SA390DISCOVERY data is processed by the SQL Server Agent jobs: Automation Discovery Load and Automation Discovery Process.

For the SA OS/390, when the address space is restarted, object information is sent to the IBM Tivoli Business Systems Manager object pump and populated in the database. Figure 11-3 illustrates the discovered resources from the SA OS/390 control file.

Figure 11-3 Subsystem objects from System Automation for OS/390

11.3 Database 2 (DB2) for z/OSThe following section describes the configuration steps for DB2 data source integration into IBM Tivoli Business Systems Manager.

This scenario does not address the integration of DB2 Performance Monitor.


11.3.1 Integration setupPerform the following steps to configure the NetView components.

1. Modify DSIPARM members:

– Ensure that the include statement for the DB2 message automation table is uncommented in hlq.SGTMSAMP(IHS$MAT) for the line:

%INCLUDE IHSBMAT

– Ensure that the include statement for the DB2 command modules member is uncommented in hlq.SGTMSAMP(IHS$CMD) for the line:

%INCLUDE IHSBCMD

– Ensure that the include statement for the DB2 OPF member is uncommented in hlq.SGTMSAMP(IHS$OPF) for the line:

%INCLUDE IHSBOPR

– Ensure that the GROUP authorization statements for the DB2 operators are uncommented in hlq.SGTMSAMP(IHS$CAT2) for the operators IHSB* in the group NVOPS1 and NVOPS2

2. Concatenate the DB2 SDSNLOAD load library to the STEPLIB DD card in the IBM Tivoli NetView for z/OS startup procedure. IBM Tivoli Business Systems Manager supports data source integration for DB2 versions 5.1, 6.1, and 7.1. If you are running multiple DB2’s at various levels, concatenate the earliest version of the DB2 load library into the IBM Tivoli NetView for z/OS startup procedure. Ensure that any earlier running version of DB2 has maintenance applied to make it upwardly compatible with the later running version.

3. IHS$PARM members of hlq.SGTMSAMP may be modified to adjust polling and discovery parameters, such as:

IHSBPOLL.THRESHOLD This parameter protects the Windows server from DB2 message flooding. The default is 500 messages per interval.

IHSBPOLL.INTERVAL Initial poll interval in minutes for DB2 subsystem. Individual intervals can be set from the IBM Tivoli Business Systems Manager console. The default is 15 minutes.

IHSBCLER.INTERVAL An interval for clearing a DB2 and DB2PM exception that has not recurred in the last polling interval. The default is 15 minutes.

IHSBRSLV.INTERVAL An interval for resolving a DB2 and DB2PM exception that is cleared within the polling interval. The default is 2 minutes.

IHS$DISC_FROM Limit of initial discovery messages. Default is 500.


IHS$DISC_NVTCP/IP Indicates the IP address of the MVS IP Listener. Our setup uses TCP/IP_ADDRESS=9.3.4.55.

4. IHS$EXCL member of hlq.SGTMSAMP provides filtering of unnecessary messages. The syntax of the file is:

TYPE NAME EVENTID SYSNAME COMMENT

where:

TYPE Object class targetNAME Matching name of the objectEVENTID Message or event idSYSNAME OS identifier or SMFid

5. The IHSBTBND job must be run for each DB2 subsystem or each DB2 Data Sharing Group being monitored by IBM Tivoli Business Systems Manager. This job will bind the DB2 plan and grant DB2 security access to the appropriate IBM Tivoli NetView for z/OS autotask user IDs.

The sample IHSBTBND member that we use is shown in Example 11-3. Note that the GRANT statements must apply to all IHSBAT* user IDs and the IBM Tivoli NetView for z/OS started task user ID.

Example 11-3 Sample IHSBTBND

//IHSBTBND JOB (),'DB2 BIND',// CLASS=A,MSGCLASS=A,REGION=0M,NOTIFY=&SYSUID//*//COPYDBRM EXEC PGM=IEBGENER//SYSPRINT DD SYSOUT=*//SYSUT1 DD * . . . /*//SYSUT2 DD DISP=SHR,DSN=GTMV2R1.LOCAL.PARMLIB(IHSBSQL) //SYSIN DD DUMMY//*//BIND EXEC PGM=IKJEFT01,DYNAMNBR=20//STEPLIB DD DISP=SHR,DSN=DB2.V7R1.SDSNLOAD <=== 4.//SYSTSPRT DD SYSOUT=*//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSTSIN DD * DSN SYSTEM(DB2O) /* <=== 2. */ BIND PLAN(IHSBSQL) - LIB('GTMV2R1.LOCAL.PARMLIB') /* <=== 3. */ - MEM(IHSBSQL) ACT(REP) ISOLATION(CS) RETAIN END//*//*//GRANT EXEC PGM=IKJEFT01,DYNAMNBR=20


//STEPLIB DD DISP=SHR,DSN=DB2.V7R1.SDSNLOAD <=== 4.//SYSTSPRT DD SYSOUT=*//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*//SYSTSIN DD * DSN SYSTEM(DB2O) /* <=== 2. */ RUN PROGRAM(DSNTIAD) PLAN(DSNTIA71) /* <=== 5. */ - LIBRARY('DB2.RUNLIB.LOAD') /* <=== 6. */ END//SYSIN DD *GRANT EXECUTE ON PLAN IHSBSQL TO IHSBAT00 ;GRANT SELECT ON SYSIBM.SYSTABLES TO IHSBAT00 ;GRANT SELECT ON SYSIBM.SYSTABLESPACE TO IHSBAT00 ;GRANT SELECT ON SYSIBM.SYSTABLEPART TO IHSBAT00 ;GRANT SELECT ON SYSIBM.SYSINDEXES TO IHSBAT00 ;GRANT SELECT ON SYSIBM.SYSINDEXPART TO IHSBAT00 ;GRANT SELECT ON SYSIBM.SYSVIEWS TO IHSBAT00 ;GRANT SELECT ON SYSIBM.SYSVIEWDEP TO IHSBAT00 ;GRANT SELECT ON SYSIBM.SYSDATABASE TO IHSBAT00 ;GRANT MONITOR1 TO IHSBAT00 ;GRANT DISPLAY TO IHSBAT00 ;GRANT TRACE TO IHSBAT00 ;//*

Modify the following parameters in hlq.SGTMSAMP(IHSBTBND) as directed in the JCL and run the job. You may need some assistance from the DB2 administrator to collect some of this information.

11.3.2 Object discoveryRecycle the IBM Tivoli NetView for z/OS started task to pick up the DB2 integration configuration. This also initiates a full discovery of the DB2 environments that will be displayed, registered, and monitored by IBM Tivoli Business Systems Manager. An example of a topology view of the DB2 subsystem is shown in Figure 11-4 on page 357.


Figure 11-4 DB2 topology display

11.4 Information Management System (IMS)The following sections describe the configuration steps for IMS data source integration into IBM Tivoli Business Systems Manager.

11.4.1 Integration setupThe following steps must be completed before integration:

� “NetView-related setup” on page 358

� “IMS-related setup” on page 359


NetView-related setupIBM Tivoli NetView for z/OS should be changed as follows:

1. Modify DSIPARM members:

– Ensure that the include statement for the IMS message automation table is uncommented in hlq.SGTMSAMP(IHS$MAT) for the line

%INCLUDE IHSIMAT

– Ensure that the include statement for the IMS command modules member is uncommented in hlq.SGTMSAMP(IHS$CMD) for the line

%INCLUDE IHSICMD

– Ensure that the include statement for the IMS OPF member is uncommented in hlq.SGTMSAMP(IHS$OPF) for the line

%INCLUDE IHSIMOPR

– Ensure that the GROUP authorization statements for the IMS operators are uncommented in hlq.SGTMSAMP(IHS$CAT2) for operators started with IHSI in the group NVOPS1 and NVOPS2.

2. The IHS$PARM member of hlq.SGTMSAMP may be modified to adjust such polling and discovery parameters as:

IHSI.$ARCHTIME Default wait time (in minutes) for the IMS archive log to run before a logging event is generated.

IHSI.$DBSINT Default interval between database status checks.

IHSI.$LOGAVAIL Default minimum number of available IMS online logs (OLDS) before an event is generated.

IHSI.$MSCINT Default interval for checking MSC links.

IHSI.$MTOINT Default interval for checking Master Terminal.

IHSI.$PGMINT Default interval for checking program status.

IHSI.$TXNINT Default interval for checking transaction status.

IHSI.$TXQLEN Default maximum queue length for transaction.

IHSI.$POLLTHRESHOLD Threshold on the number of messages to be sent to Windows server to avoid message flood.

IHS$DISC_FROM Limit of initial discovery messages. Default is 500.

IHS$DISC_NVTCP/IP IP address of the MVS IP Listener. Our setup is TCP/IP_ADDRESS=9.3.4.55.


3. The IHS$EXCL member of hlq.SGTMSAMP provides filtering of unnecessary messages. The syntax of the file is:

TYPE NAME EVENTID SYSNAME COMMENT

with these variables:

TYPE Object class targetNAME Matching name of the objectEVENTID Message or event IDSYSNAME OS identifier or SMFid

4. Estimate the number of NetView global variables required for each IMS region using the formula provided in the Install and Configuration Guide and modify accordingly the IBM Tivoli NetView for z/OS constants module, DSICTMOD.

5. IMS intergration makes use of EMCS consoles. Verify that your NetView environment is set up to enable the MCS extended console interface. For example, the MSGIFAC parameter in both the NetView subsystem interface start procedure and in CNMSTYLE should be set to SYSTEM.

6. If you are running DBCTL regions and wish to suppress certain DFS™ messages from SYSLOG, review and run hlq.SGTMSAMP(IHS$MPF) to modify MPF.

IMS-related setupPerform the following steps to configure each IMS region.

1. Install the IMS Automated Operator (IMSAO) exit. Typically, IMS messages are only sent to the IMS master terminal and do not get into the Subsystem interface for monitoring from NetView. IBM Tivoli Business Systems Manager uses an IMSAO type 2 exit called IHSIAOE0 to trap these messages. This exit must be installed in each region. If your environment is such that other users and/or products also require this exit interface, then an optional controller exit (IHSIAOEC) can be installed that enables four other IMS AO type 2 exits to coexist with IHSIAOE0. Perform the following steps to install the IMS AO exits:

a. Modify and run hlq.SGTMSAMP(IHSIAOML) to assemble and linkedit the AO message table. The message table is stored in member IHSIAOMT of SGTMSAMP.

b. Modify and run hlq.SGTMSAMP(IHSIAO0J) to linkedit the AO exit IHSIAOE0.

c. If you need multiple IMSAO exits (for other automation software), you must create the IHSIAOEC module. Modify hlq.SGTMSAMP(IHSIAOEE) that contains the name of the modules for the IMSAO controller exit. Adapt and run IHSIAOEJ and IHSIAOCJ to assemble and link-edit IHSIAOEE and IHSIAOEC.


These exits must be stored in the IMS RESLIB or concatenated in the STEPLIB of the IMS Control Region. At the startup of the IMS Control Region, the messages shown in Example 11-4 on page 360 indicate a successful installation of the IHSIAOE0 exit.

Example 11-4 Messages from IHSIAOE0

IHS370I AO Exit IHSIAOE0 initialized for IMS v7.1.0 TM/DB system IMSQIHS371I Successfully loaded Message Table IHSIAOEM IMSQ

2. Enable Open Transaction Manager Access (OTMA). IBM Tivoli Business Systems Manager integration uses OTMA for issuing IMS commands from the IBM Tivoli Business Systems Manager console. To enable OTMA, you can specify parameters at IMS startup as shown below.

S IMS710Q,PARM1='OTMA=Y,GRNAME=WTSCPLX1'

where GRNAME represents the Sysplex group name on which IMS runs.

The OTMA command interface program DFSYSVI0 also must be run immediately after IPL, before any address space that uses OTMA is started. You can achieve this by running the JCL stored in DFSYINIT in the IMS library SDFSISRC. A sample is shown in Example 11-5.

Example 11-5 DFSYINIT

//OTMAINIT JOB ,'OTMA INITIALIZATION',CLASS=A,REGION=4M//*//IEFPROC EXEC PGM=DFSYSVI0//*//STEPLIB DD DISP=SHR,DSN=IMS710Q.SDFSRESL//SYSPRINT DD SYSOUT=*//SYSUDUMP DD SYSOUT=*

3. Configure IMS security. The NetView autotasks specific to IMS integration (IHSIAUT0, IHSIAUT1, IHSIAUT2 and IHSIAUT3) must be defined as RACF user IDs. These user IDs require the following access:

– Access to issue all IMS display commands through the OTMA interface and for the EMCS interface for DBCTL regions. To enable OTMA interface access, you can set the IMS startup parameter OTMASE=F (full security) and tailor your security product to have access to IMS display commands.

– Access to IMSXCF.group.IHSI* RACF profile.– Allocate temporary data sets.– READ access to IMS data sets ACBLIB, MODBLKS, RESLIB and

PROCLIB.– CONTROL access to recovery control (RECONxx) data sets.– Access to run DSPURX00 (DBRC utility), which is usually protected using

the PROGRAM profile.


11.4.2 Object discoveryRecycle the NetView started task to pick up the IMS integration configuration. This also will initiate a full discovery of the IMS environments that will be displayed, registered, and monitored by IBM Tivoli Business Systems Manager. Figure 11-5 illustrates a discovered IMS environment view.

Figure 11-5 IMS descendants

11.5 CICSPlex System Manager Version 2.2The following section describes the configuration steps for integrating the CICSPlex System Manager (CPSM) data source into IBM Tivoli Business Systems Manager.


11.5.1 Integration setupSeveral tasks must be performed for this integration:

� “IBM Tivoli NetView for z/OS changes” on page 362

� “CICSPlex system availability monitoring” on page 362

� “CICSPlex MAS resource monitoring (MRM)” on page 367

� “TBSM Windows server updates” on page 369

IBM Tivoli NetView for z/OS changesPerform the following steps to configure the NetView components:

� Modify DSIPARM members to ensure that the include statement for the CICSPlex message automation table is uncommented in hlq.SGTMSAMP(IHS$MAT) for the line

%INCLUDE IHSCMAT1

� CICSPlex integration requires that the NetView auto-operator AUTOAMI is defined and activated by enabling the Application Management Interface (AMI) tower within CNMSTYLE:

TOWERS = AMI

CICSPlex system availability monitoringEvents being sent to IBM Tivoli NetView for z/OS for monitoring and forwarding to IBM Tivoli Business Systems Manager require PTF UQ64483 for CICS Transaction Server Version 2.2. This enables the sending of additional information about alerts to IBM Tivoli NetView for z/OS.

For each of the CICSPlex resources, you must update the real-time availability monitoring specification (RTASPEC) to invoke an action definition (ACTNDEF) that sends an alert to IBM Tivoli NetView for z/OS. Additionally, this function must be activated by specifying EYUPARM (ALERTVER(1)) on the CMAS named in the ACTNDEF.

To set up CICSPlex SM system availability monitoring (SAM):

1. Access the CPSM interactive panels as shown in Figure 11-6 on page 363. Select option 2 for CPSM and ensure that the context name is correct for the CICSPlex service point (not the CMAS).


Figure 11-6 CPSM main panel

2. From the panel shown in Figure 11-7, enter RTASPEC to return a list of CICS resources whose real-time specifications can be defined or updated .

Figure 11-7 View selection panel

----------------------------CICSPlexSystemManager--------------------------- OPTION ===> 2 0 PROFILE - User Session Parameters 1 PLEXMGR - List of Service Points 2 CPSM - CICSPlex SM Default Criteria for CPSM: Context ===> SC66PLEX Scope ===> Warning Record Count ===> 0 0 for no checking Require Set ===> YES YES, NO

Licensed Materials - Property of IBM 5697-E93 (C) Copyright IBM Corp. 1994, 2001. All Rights Reserved. U.S. Government Users Restricted Rights - Use, Duplication or Disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

19:12:06 ----------- INFORMATION DISPLAY ---------------------------COMMAND ===> RTASPEC SCROLL ===> PAGE CURR WIN ===> 1 ALT WIN ===> W1 =MENU==============SC66PLEX=CSYS1H1==11DEC2002==19:12:06====CPSM=========16CMD Name Description --- ------------------------------------- ANALYSIS Real Time Analysis Operations Views CONFIG CMAS Configuration Operations Views MONITOR Monitoring Views OPERATE Operations Views TOPOLOGY Topology Operations Views WORKLOAD Workload Operations Views ======== ================================================================ ADMSAM RTA System Availability Monitoring Administration Views ADMMRM RTA MAS Resource Monitoring Administration Views


3. In the panel shown in Figure 11-8, tab to the corresponding CICS resource that you want to monitor and enter upd (update) next to it.

Figure 11-8 RTASPEC panel

4. In the panel shown in Figure 11-9, specify an action definition (ACTNDEF) for each of the six system availability conditions listed. If appropriate, you can use an existing definition here. We used “TBSMA1” for the definition that we will create in a later step. Press ENTER to update the RTA specification.

Figure 11-9 Real time analysis specification update

11DEC2002 19:44:00 ----------- INFORMATION DISPLAY ---------------------------COMMAND ===> SCROLL ===> PAGE CURR WIN ===> 1 ALT WIN ===> W1 =RTASPEC===========SC66PLEX=CSYS1H1==11DEC2002==19:43:55====CPSM=========10CMD Spec Description --- Name---- ------------------------------ upd SCSCPAA1 Generated by CICS PM SCSCPAA4 Generated by CICS PM SCSCPAA8 Generated by CICS PM SCSCPJA2 Generated by CICS PM SCSCPJA6 Generated by CICS PM SCSCPJA7 Generated by CICS PM SCSCPLA1 Generated by CICS PM

----------------- Update Analysis Specification for SC66PLEX ------------------COMMAND ===> RTA Spec Name SCSCPAA1 Description ===> Generated by CICS PM System availability management: Action or Generic Severity SAM ===> TBSMA1 ===> SOS ===> TBSMA1 ===> SYSDUMP ===> TBSMA1 ===> TRANDUMP ===> TBSMA1 ===> MAXTASK ===> TBSMA1 ===> STALL ===> TBSMA1 ===> Press ENTER to update the RTA Specification. Type END or CANCEL to cancel without updating.


5. The main RTASPEC panel opens, as shown in Figure 11-8 on page 364. Enter ACTNDEF in this panel for a list of current action definitions.

6. From the ACTNDEF panel shown in Figure 11-10, you may either modify an existing action by using the UPD command next to the desired definition, or create a new definition by entering CRE at the command line. We create a new definition in our scenario.

Figure 11-10 Action definition selection panel

7. Figure 11-11 on page 366 shows the panel that is used to create an action definition. Enter an Action Name and a brief description. Ensure that the following fields are defined:

– ALERT must be set to YES.

– CMAS Name must be set to the local CMAS. This is the CMAS where EYUPARM must be specified in order to send generic alerts to IBM Tivoli NetView for z/OS. The parameter for this is EYUPARM (ALERTVER(1)). Press ENTER to create the Action Definition.

12DEC2002 10:19:52 ----------- INFORMATION DISPLAY ---------------------------COMMAND ===> cre SCROLL ===> PAGE CURR WIN ===> 1 ALT WIN ===> W1 =ACTNDEF===========SC66PLEX=CSYS1H1==12DEC2002==10:19:51====CPSM========106CMD Name Event View Msg Alert ARM Description --- -------- ----- -------- --- ----- --- ------------------------------ CMZAF361 YES NO NO NO Region SOS CMZA5742 YES NO NO NO Times MAXT reached CMZBCF03 YES NO NO NO CMZBCF81 YES NO NO NO total tsks wait for strings CMZBC721 YES NO NO NO General SOS alert CMZBE804 YES NO NO NO Max Active Threads CMZBFE82 YES NO NO NO curr strg waits CMZB5901 YES NO NO NO ESDSA Requests suspended CMZB5922 YES NO NO NO Count of buffer waits CMZB8081 YES NO NO NO Current number of tasks CMZB8883 YES NO NO NO SDSA Requests suspended CMZC0503 YES NO NO NO tot strg waits


Figure 11-11 Creating TBSMA1 action definition

8. Your new action definition should appear now in the action definition list shown in Figure 11-12.

Figure 11-12 Updated action definition list

-------------------- Create Action Definition for SC66PLEX -------------------- COMMAND ===> Action Name ===> TBSMA1 Description ===> TBSM Action Event ===> YES Generate Event (Yes/No) Event View ===> View for Event Priority ===> 1 Event Priority (1 to 255) Event Text ===> TBSM Action External Msg ===> NO Generate External Message (Yes/No) Enter Msg ===> Exit Msg ===> Alert ===> YES Generate Alert (Yes/No) CMAS Name ===> SCSCCMAS CMAS to Issue Alert Enter Text ===> Exit Text ===> Restart ===> NO Cancel for ARM Restart (Yes/No) Press ENTER to create the Action Definition.

12DEC2002 11:00:13 ----------- INFORMATION DISPLAY ---------------------------COMMAND ===> SCROLL ===> PAGE CURR WIN ===> 1 ALT WIN ===> W1 =ACTNDEF===========SC66PLEX=CSYS1H1==12DEC2002==11:00:09====CPSM========105CMD Name Event View Msg Alert ARM Description --- -------- ----- -------- --- ----- --- ------------------------------ CMZ86980 YES NO NO NO test db2 threshold CMZ89702 YES NO NO NO Storage Cushion releases CMZ9DD85 YES NO NO NO rls wait CMZ9D303 YES NO NO NO SOS Below the line CMZ93784 YES NO NO NO A Task is waiting on DB2 CMZ94884 YES NO NO NO Short on Storage CMZ97686 YES NO NO NO Current nmber of tasks CMZ99525 YES NO NO NO UDSA Cushion Release TBSMA1 YES NO YES NO TBSM Action


CICSPlex MAS resource monitoring (MRM)New definitions from IBM Tivoli Business Systems Manager must be loaded to the CICSPlex MAS address space to monitor the status of CICS resources. The following samples of these MRM definitions are provided in hlq.SGTMSAMP:

IHSCGRP CICS groups

IHSCFILE Files

IHSCTRAN Transactions

IHSCMAS CICS regions and connections

IHSCDB2C DB2 connections

IHSCCORB Corba servers and JAR files

IHSMISC Miscellaneous resources

Modify the members for your environment as directed in the JCL, and submit them using the batched repository update facility (BATCHREP) in the CPSM interactive panel interface. Perform the following steps to install each file:

1. Access the CPSM interactive panel shown in Figure 11-13. Select option 2 for CPSM and ensure that the context name is correct for your local CMAS.

Figure 11-13 CICSPlex System Manager panel

2. From the panel shown in Figure 11-14 on page 368, enter BATCHREP to access the batched repository update facility.

----------------------------CICSPlex System Manager---------------------------- OPTION ===> 2 0 PROFILE - User Session Parameters 1 PLEXMGR - List of Service Points 2 CPSM - CICSPlex SM

Default Criteria for CPSM: Context ===> SCSCCMAS Scope ===> CSYS1H1 Warning Record Count ===> 0 0 for no checking Require Set ===> YES YES, NO

Licensed Materials - Property of IBM 5697-E93 (C) Copyright IBM Corp. 1994, 2001. All Rights Reserved. U.S. Government Users Restricted Rights - Use, Duplication or Disclosure restricted by GSA ADP Schedule Contract with IBM Corp.


Figure 11-14 CPSM primary option

3. From the panel shown in Figure 11-15, issue sub at the command line.

Figure 11-15 BATCHREP display panel

4. From the panel shown in Figure 11-16 on page 369, complete the fields as described and then press ENTER to run the job.

– Data Set Name: Specify the PDS where the definition members reside.

– Data Set Member: Specify the definition member name.

– Print Node: Specify the local (or owning) JES node name.

– Output Userid: Specify your user ID to send the spool output.

– Run Type: Specify EXECUTE to run the job.

12DEC2002 13:11:21 ----------- INFORMATION DISPLAY ---------------------------COMMAND ===> BATCHREP SCROLL ===> PAGE CURR WIN ===> 1 ALT WIN ===> W1 =MENU==============SCSCCMAS=CSYS1H1==12DEC2002==13:11:21====CPSM=========16CMD Name Description --- ------------------------------------- ANALYSIS Real Time Analysis Operations Views CONFIG CMAS Configuration Operations Views MONITOR Monitoring Views OPERATE Operations Views TOPOLOGY Topology Operations Views WORKLOAD Workload Operations Views ======== ================================================================ ADMSAM RTA System Availability Monitoring Administration Views ADMMRM RTA MAS Resource Monitoring Administration Views ADMAPM RTA Analysis Point Monitoring Administration Views

12DEC2002 13:14:09 ----------- INFORMATION DISPLAY --------------------------- COMMAND ===> sub SCROLL ===> PAGE CURR WIN ===> 1 ALT WIN ===> W1 =BATCHREP==========SCSCCMAS=CSYS1H1==12DEC2002==13:14:09====CPSM=========== BBMXBD15I There is no data that satisfies your request -Related:BBMXBD23I 0 records presented by the product


Figure 11-16 BATCHREP submission panel

5. Because you specified your own ID as the output user ID, you can issue a TSO RECEIVE command to receive the generated repository request report. Browse the report for errors. A good practice to follow is to set the Run Type to CHECK initially and browse the report to correct problems. Then set the Run Type to EXECUTE for a clean execution.

TBSM Windows server updatesThis section describes the steps required to enable CICSPlex SM integration on the IBM Tivoli Business Systems Manager server environment.

1. Enable and schedule the following SQL server jobs on the database server.

– CICS Discovery Load

– CICS Discovery Process

2. Insert a CICSPlex resource under the operating system object.

Select Additional Information on the Properties page for the CICSPlex resource that you just created, as shown in Figure 11-17 on page 370. Update the following information:

– CICSPlex Maintenance Point CMAS Name

– Name of discovery job

– OS ID of system running maintenance point CMAS

Select Apply and OK to save the information.

------------------------ Start Batch Run for SCSCCMAS -------------------------COMMAND ===> Data Set Name ===> GTMV2R1.LOCAL.SGTMSAMP Data Set Member ===> IHSCGRP Print Class ===> A Print Node ===> WTSCPLX1 Output Userid ===> TIVO01 Run Type ===> EXECUTE (CHECK or EXECUTE) Press ENTER to Run the Job. Type END or CANCEL to cancel without Running.


Figure 11-17 Property of a CICSPlex definition

11.5.2 Object discoveryCICSPlex discovery processing is performed by running IHSCCRUN from a discovery request initiated from the IBM Tivoli Business Systems Manager console. Modify hlq.SGTMSAMP(IHSCCRUN) according to the instructions in the JCL. Our sample IHSCCRUN is shown in Example 11-6.

Example 11-6 IHSCCRUN

//IHSCCRUN JOB ,CLASS=A,MSGLEVEL=1/*JOBPARM SYSAFF=SC66//*//EXTRACT EXEC PGM=IHSCPBCH,// PARM='#PARM#'//STEPLIB DD DISP=SHR,DSN=CICSTS22.CPSM.SEYUAUTH// DD DISP=SHR,DSN=GTMV2R1.SGTMMODS//AOPEXEC DD DISP=SHR,DSN=GTMV2R1.SGTMEXEC//SYSPRINT DD SYSOUT=*//AOPDFILE DD DISP=(NEW,PASS,DELETE),DSN=&&TEMP,// SPACE=(TRK,(10,1)),UNIT=SYSDA//*


//TRANSMIT EXEC PGM=GTMAOPE0,COND=(0,NE,EXTRACT)//STEPLIB DD DSN=GTMV2R1.SGTMMODS,DISP=SHR//SYSPRINT DD SYSOUT=*//SYSUT1 DD DSN=*.EXTRACT.AOPDFILE,DISP=(OLD,DELETE,DELETE)//SYSIN DD *TCP/IP_ADDRESS=9.3.4.55TCP/IP_PORT=1021CODEPAGE=037COMMAND=CPSMDISCOVERYCONVERT=NOTEXT=NODATA_SEPARATOR=X'25'FORMAT=X'0A'/*

Initiate a discovery request from the IBM Tivoli Business Systems Manager console by right-clicking the CICSPlex resource and selecting CICSPlex Information -> CICSPlex Discovery Request as shown in Figure 11-18.

Figure 11-18 Initiating CICSPlex SM discovery


Figure 11-19 illustrates a discovered CICSPlex environment topology view.

Figure 11-19 CICSPlex SM CICS Topology display

11.6 Tivoli Workload Scheduler for z/OSThe following section describes the configuration steps for Tivoli Workload Scheduler for z/OS data source integration into IBM Tivoli Business Systems Manager.

11.6.1 ConceptThe discovery of TWS for z/OS is processed from the Extend Daily Plan job report. This report must be downloaded to the IBM Tivoli Business Systems Manager database server and loaded using the OPCParseDailyPlan.ksh program.


Startup and completion events for each TWS for z/OS job with the external monitoring flag set to On are sent to IBM Tivoli Business Systems Manager through the AOPEDI interface.

11.6.2 Integration setupSeveral tasks must be performed for setting up the integration:

� “Disabling the old interface” on page 373

� “Configuring Tivoli Workload Scheduler for z/OS” on page 374

� “Preparing the TBSM database” on page 375

Disabling the old interfaceIf you previously integrated Tivoli OPC Version 2.2 or Version 2.3 into IBM Tivoli Business Systems Manager, you must disable any WTO and user exit 7 processing that was set up for these versions. This is the procedure:

1. Change the OPC initialization parameter as shown in Example 11-7. Remove the commented portion. Remove the WTO alerts from the ALERTS initialization statement in OPC and disable the call to exit 07 EQQUX007.

Example 11-7 OPC initialization parameter changes

ALERTS GENALERT(OPCERROR) MLOG (ERROROPER) # WTO (DURATION # ERROROPER # LATEOPER # OPCERROR # QLIMEXCEED # RESCONT)

. . .

#EXITS CALL07(YES) EXITS CALL07(NO)

2. Remove the IBM Tivoli Business Systems Manager version of EQQUX007 from any library in LNKLST, or concatenated in the TWS for z/OS’s STEPLIB DD statement.


Configuring Tivoli Workload Scheduler for z/OSTo implement the new interface:

1. Add this EXTMON parameter to the OPCOPTS statement in your TWS initialization member:

OPCOPTS EXTMON(YES)

2. The IBM Tivoli Business Systems Manager module AOPEDI must be made available to either the tracker or controller procedures. Either concatenate hlq.SGTMMODS into the STEPLIB DD statement of the tracker or controller procedure, or copy hlq.SGTMMODS(AOPEDI) into the TWS load module library EQQ.SEQQLMD0.

3. To enable IBM Tivoli Business Systems Manager monitoring of a job, you must set the External Monitor job option of an operation to YES(Y). This can be done using the ISPF panels for either job as shown in Figure 11-20. A mass update also may be performed.

Figure 11-20 Detailed operation information

------------------- BROWSING DETAILED OPERATION INFORMATION ------------------- Command ===> Application : FXXXDWPARMUPDATE Upd parms on UNIX FTAs Operation : DUMY 5 Update parms. on F100 Occurrence token : B873886335D1A664 Jobname and Jobid : DUMMYSTR Reader date and time : Status : Completed on Work Station : Job or Sysout class : Auto submit: Yes Hold/release : Yes Form number : Time depend: No Suppress late: No Priority : 5 Rerouteable: Restartable : Deadline WTO : No Ext monitor: Yes WLM Critical : No Policy : Date and time for : Planned Actual Input arrival : 02/10/30 09.00 02/10/30 12.33 Start : End : 02/10/30 12.33 User field: Deadline : 02/10/30 18.00 Duration : 00.00.30 00.00.00 Latest start : 02/10/30 17.58 Resources : Parallel servers R1 R2 Special resources Required number : 1 0 0 0


Preparing the TBSM databasePreparing the TBSM database requires the following steps:

� Insert the BATCH SCHEDULE SET object on the console.

� Define the mapping of batch schedules.

In this section, we define which applications should be monitored and how these applications should be grouped. Perform the following steps:

1. Define the dynamic path where you want to put the batch job objects from TWS. Our definition was created in the OPC_Class_Definition.sqi file shown in Example 11-8.

Example 11-8 Dynamic object path for Tivoli LOB


BEGIN_DYNA_OBJ_PATH(OPC, Group all OPC backup processes) DYNA_OBJ_PATH(BUSC,BUSC) DYNA_OBJ_PATH(ENT,ITSO) DYNA_OBJ_PATH(COMP,Poughkeepsie) DYNA_OBJ_PATH(BCYS,BACKUPSYSTMS, OPC backup applications for Backup Batch) DYNA_OBJ_PATH(BTCY,BACKUPSYSTMS, OPC backup applications for Backup Batch)END_DYNA_OBJ_PATH(OPC)

BEGIN_DYNA_OBJ_PATH(OPC LOB, Group all OPC LOBs) DYNA_OBJ_PATH(LOBC,LOBC) DYNA_OBJ_PATH(LOB,OPC Applications) DYNA_OBJ_PATH(BCYS,BACKUPSYSTMS, OPC backup applications for His Company Backup Batch) DYNA_OBJ_PATH(BTCY,BACKUPSYSTMS, OPC backup applications for His Company Backup Batch)END_DYNA_OBJ_PATH(OPC LOB)

2. Define the file selection filter for the individual batch jobs that will be matched with the dynamic path that we defined. Our definition was created in the OPC_Appl_Definition.sqi file shown in Example 11-9.

Example 11-9 Pattern matching for OPC dynamic path

include(BusinessObject.sqi)OPC_APP_PATTERN(OPC, ITSO.BATCH, %SAMPLE[A-Z]%, %, %)OPC_APP_PATTERN(OPC LOB, ITSO.BATCH, %SAMPLE[A-Z]%, %, %)

3. Pre-process the sqi file using the clsql script and run the resulting sql files. We used the shell script shown in Example 11-10 on page 376 to perform this function.


Example 11-10 Applying OPC definitions

sh clsql OPC_Class_Definition.sqish clsql OPC_Appl_Definition.sqiisql -U sa -P sa -S itsovas3 -i OPC_Class_Definition.sqlisql -U sa -P sa -S itsovas3 -i OPC_Appl_Definition.sql

The result of the definitions is stored in the following tables:

dyn_obj_path Stores the dynamic path identification.

dyn_obj_path_detail Stores the dynamic path details referring to dyn_obj_path.

opc_app_pattern Stores the pattern created from OPC_Appl_Definition.sqi.

11.6.3 Object discoveryThe following object discovery action must be performed regularly:

1. From the TWS z/OS ISPF panels, extend the current plan, and FTP (in ASCII) the report for the extend current plan job into the \TivoliManager\Data\OPC directory on the database server.

2. Run the \TivoliManager\bin\OPCParseDailyPlan.ksh script to parse, load, and map the daily plan into the IBM Tivoli Business Systems Manager OPCLoad database.

11.7 Resource Object Data ManagerThe Resource Object Data Manager (RODM) data cache contains information about the SNA network on z/OS. SNA topology and resource information is available to NetView from the VTAM Common Management Information Protocol (CMIP) agent. CMIP services interfaces with the SNA topology manager (SNATM) application in IBM Tivoli NetView for z/OS. SNATM loads these SNA resources into RODM, which is then extracted and sent to the IBM Tivoli Business Systems Manager database with a batch job. An SNA/APPN Network object must be inserted under the OS object that owns this network for these discovered SNA resources.

TCP/IP resource discovery on z/OS also is supported with NetView for z/OS Version 5.1 with Linux on z/OSeries. The TCP/IP information is again loaded into RODM and sent to the IBM Tivoli Business Systems Manager database. TCP/IP resources are defined in RODM as GMFHS aggregates, so a GMFHS aggregates folder must be inserted under the OS object for these discovered TCP/IP resources.


In our project, we only discuss the configuration for SNA resource data feed and discovery.

11.7.1 ConceptThe RODM notify method AOPNOTF provides resource status updates for IBM Tivoli Business Systems Manager. A standard Data Model load and RODM setup is assumed and the configuration for this is not covered in this project.

11.7.2 Integration setupTo install the IBM Tivoli Business Systems Manager interface to RODM:

1. Add the RODM control cards shown in Example 11-11 to the object pump parameter member.

Example 11-11 RODM setting for the object pump

* To activate the RODM Interface uncomment the following* line(s) RODM_NAME=RODM specify the RODM name RODM_USERID=TIVO02 default to object pump jobname

RODM_NAME The RODM name, typically RODM, assigned to the RODM address space.

RODM_USERID The user ID for logging on to the RODM. It must be RACF-defined and have access to RODMMGR profiles.

The following message in the object pump startup indicates a successful RODM integration with Source/390.

GTM7815I TBSM HAS CONNECTED TO RODM : RODM

2. Insert an SNA/APPN Network object under the logical partition object from the IBM Tivoli Business Systems Manager console. Ensure that the network name matches the network ID name specified in VTAM. Obtain this network name by issuing the VTAM command as illustrated in Example 11-12.

Example 11-12 Getting the SNA NetID

* SC69N D NET,VTAMOPTS,OPTION=NETID ' SC69N IST1188I VTAM CSV1R2 STARTED AT 15:55:52 ON 10/23/02 IST1349I COMPONENT ID IS 5695-11701-120 IST1348I VTAM STARTED AS END NODE IST1189I NETID = USIBMSC IST314I END


a. Select an OS object and right-click to invoke Insert -> SNA/APPN Network as shown in Figure 11-21. We create this under SC69.

Figure 11-21 Inserting SNA APPN network object

b. In the New SNA/APPN Network dialog, type in the Network ID that we got from Example 11-12 on page 377, which in our example is USIBMSC as shown in Figure 11-22 on page 379.


Figure 11-22 Setting the NetID name

c. On the Properties page, select Additional Information and enter the correct OS object path as shown in Figure 11-23. Click OK to save it.

Figure 11-23 Setting the OS path

11.7.3 Object discoveryModify hlq.SGTMSAMP(GTMSAM16), which is the RODM unload job that sends RODM data to the MVS IP Listener. The job that we use is shown in Example 11-13 on page 380.


Example 11-13 GTMSAM16 job

//RODMUNLD JOB (RODMUNLD,0000),'TBSM RODM UNLD',CLASS=A,MSGCLASS=X//*//EKGKUNLD EXEC PGM=EKGKUNLD//STEPLIB DD DSN=NETVIEW.SEKGMOD1,DISP=SHR//SYSPRINT DD SYSOUT=*//LINKS DD DSN=&&LINKS,DISP=(,PASS),SPACE=(CYL,(10,5)),UNIT=SYSDA//OBJVAL DD DSN=&&OBJVAL,DISP=(,PASS),SPACE=(CYL,(10,5)),UNIT=SYSDA//OBJECTS DD DSN=&&OBJECTS,DISP=(,PASS),SPACE=(CYL,(10,5)),UNIT=SYSDA//CLASSES DD DUMMY//CLASSVAL DD DUMMY//REPORT DD DUMMY//SYSIN DD *RODM=RODMCLASS=UniversalClassDEPTH=ALLWRITEMODE=OVERWRITEWHITESPACE=HIGHREPORTONLY=NO/*//RODMXMIT EXEC PGM=GTMAOPE0//STEPLIB DD DSN=GTMV2R1.SGTMMODS,DISP=SHR//SYSPRINT DD SYSOUT=*//SYSUT1 DD DSN=&&LINKS,DISP=(OLD,DELETE)// DD DSN=&&OBJVAL,DISP=(OLD,DELETE)// DD DSN=&&OBJECTS,DISP=(OLD,DELETE)//SYSIN DD *TCP/IP_ADDRESS=9.3.4.55TCP/IP_PORT=1021CODEPAGE=037TIMEOUT=600TEXT=YESCOMMAND=RODMDISCOVERY/*

Run the RODM processing jobs from the SQL Server Agent. Run the RODM Discovery Load and then RODM Discovery Process. This should create the network objects.

Figure 11-24 on page 381 illustrates the discovered resources from the RODM data cache. Right-click the SNA/APPN Network USIBMSC.SC69M object and select Open -> Topology Views -> General.


Figure 11-24 SNA topology view

11.8 Resource Measurement Facility (RMF)IBM Tivoli Business Systems Manager integrates with RMF Monitor III and RMF Distributed Data Server (GPMSERVE) to generate exceptions when system workload and resource utilization exceeds specified thresholds. The following section describes the configuration steps for RMF data source integration into IBM Tivoli Business Systems Manager.

11.8.1 ConceptFigure 11-25 on page 382 depicts the event processing data flow for RMF monitoring events for IBM Tivoli Business Systems Manager architectures.


Figure 11-25 Event flow and component descriptions for TBSM/RMF integration

The RMF Monitor III address space (RMFGAT) collects short-term data about systems performance. The GPMSERVE manages RMF Monitor III data and returns this data to an external requestor on demand.

The collector task from the object pump connects to the GPMSERVE to send and receive RMF information. The reporter task takes output from the collector, checks whether the threshold has been exceeded, and formats events to be sent to the object server.

These tables contain the RMF profile information in IBM Tivoli Business Systems Manager:

RMFProfile List of available RMF profiles. Initially this table contains three RMF profiles: Eliminate, Default, and Stress.

RMFProfileDef RMF monitoring metrics and threshold definition for each available RMF profile. No metric is defined for Eliminate. Stress profile has all the metrics defined, while Default has most of the important metrics.

RMFProfileObjReln Correlates a TBSM object (identified by class ID and instance ID) with an RMF profile (identified by the profile ID).

11.8.2 Integration setupThe following tasks must be performed to set up the integration. This section assumes that the RMF Distributed Data Server (GPMSERVE) is already running in your environment.

1. Configure Source/390 object pump parameters. The following default values apply to the RMF parameters and may work for your environment without any additional modification:

– RMF_SERVER_IP Specifies the IP address of the RMF DDS server address space (GPMSERVE procedure). This is the IP address of the

RMF Monitor IIIRMFGAT

Distributed Data ServerGPMSERVE

TBSM Object Pump

monitoring task

reporter taskcollector task


system on which the RMF DDS server resides. No value defaults to the IP address of the local MVS system.

– RMF_SERVER_PORT Specifies the port number on which RMF responds. This value corresponds to the value of the DM_PORT parameter found in SYS1.PARMLIB(GPMSRV00). No value defaults to 8802.

– RMF_SERVER_TIMEOUT= Specifies the time in seconds that the Source/390 object pump waits before assuming that the DDS server is unavailable. No value defaults to 5.

– RMF_SERVER_INTERVAL= Corresponds to the MINTIME option for RMF Monitor III, which can be found in SYS1.PARMLIB(ERBRMFxx).

The RMF specific parameters are included in hlq.SGTMSAMP(PARMPUMP) as illustrated in Example 11-14.

Example 11-14 RMF-related parameters in object pump

* To activate the RMF DDserver (RMF III) interface * uncomment the following line(s) * RMF_SERVER_IP=9.12.6.22 IP address of RMF DDServer RMF_SERVER_PORT=8802 port of DDServer (default) RMF_SERVER_TIMEOUT=5 Timeout value (default) RMF_SERVER_INTERVAL=100 RMF Interval (default)

2. Perform the following steps on the workstation to enable and customize RMF:

a. Create a copy of Sample_RMF_Profiles.sqi from the TivoliManager\sql directory and edit as shown in Example 11-15 to associate the existing default profile with an operating system. Press Ctrl+Shift+PF12 from the physical tree view to display the 10-digit object ID just to the right of the resource. The first six digits are the object ID that you use to identify the operating system in your copy of the Sample_RMF_Profiles.sqi file. We called it SC69_RMFProfile.sqi.

Example 11-15 SC69_RMFProfile.sqi

include (BusinessObjects.sqi)

-- Associate OSid 1 with the ‘Default’ ProfileBEGIN_RMF_PROFILE(Default)

RMF_OBJECT_RELATION(OS,1)END_RMF_PROFILE()--GO


b. Compile your copy of the Sample_RMF_Profiles.sqi file with the following command syntax:

clsql SC69_RMFProfile.sqi

c. Run the compiled file to the database using the following command:

isql -S ibmtiv5 -Usa -PXXXX -n -iSC69_RMFProfile.sql

d. Restart the propagation agent dispatcher service on the database server.

e. Upload the RMF settings to the Source/390 object pump. Do this by right-clicking the operating system object and selecting Source/390 -> Send RMF registration(s) as shown in Figure 11-26.

Figure 11-26 Invoking RMF registration

This will initiate RMF exceptions to be sent to IBM Tivoli Business Systems Manager.


11.9 System Managed Storage (SMS)This section describes the configuration steps for SMS data source integration into IBM Tivoli Business Systems Manager.

11.9.1 ConceptThe conceptual flow is shown in Figure 11-27.

Figure 11-27 SMS information flow

Disk devices and their resources are collected regularly by a set of batch jobs. The results are transferred using the MVS IP listener and loaded to the IBM Tivoli Business Systems Manager database by a set of jobs that are scheduled by the SQL Server Agent.

11.9.2 Integration setupSeveral things must be set up for DFSMS resources:

� “Configuring the z/OS components” on page 385

� “Configuring the TBSM server” on page 386

Configuring the z/OS componentsPerform the following in the z/OS:

� Configure the JCLs members in hlq.SGTMSAMP shown in Table 11-1 on page 386 and run in the designated order to collect and transmit the SMS-managed resource data to the IBM Tivoli Business Systems Manager database. These jobs may be scheduled to run daily.

SQL Server Agent jobs

SMS Disk Device DiscoverySMS Disk Volume and Storage Group Discovery

SMS Data Set DiscoverySMS Catalog Entry Discovery

GTMDCLBDGTMUCBBDGTMCATBDGTMVTCBD

TBSM MVS IP Listener


Table 11-1 TBSM batch jobs for SMS

� Ensure that the RMF is active and is collecting SMF type 74 records to an SMF buffer. It is recommended to have a buffer of 8M for SMF record 74 collection.

Configuring the TBSM serverThis section describes the steps required on the IBM Tivoli Business Systems Manager server environment to enable DFSMS integration.

1. Enable and schedule the following SQL server jobs on the database server:

– SMS Disk Device Discovery Load

– SMS Disk Device Discovery Process

– SMS Disk Volume and Storage Group Discovery Load

– SMS Disk Volume and Storage Group Discovery Process

– SMS Data Set Discovery Load

– SMS Data Set Discovery Process

– SMS Catalog Entry Discovery Load

– SMS Catalog Entry Discovery Process

2. Enable monitoring. To assign the default threshold profiles for space usage exceptions, device performance exceptions, and cache performance exceptions, you must perform the following steps.

a. Create a copy of smssampleintervalprofiles.sqi called smsintervalprofiles.sqi in the TivoliManager/sql directory.

b. Compile your copy of the smsintervalprofiles.sqi file with this command syntax:

clsql smsintervalprofiles.sqi

c. Apply the compiled file to the database using this command syntax:

isql -S ibmtiv5 -U sa -P XXXX -i smsintervalprofiles.sql

Optionally, you may customize the threshold profiles.

Member name Resources Recommended parameter

GTMDCLBD Storage Group,Disk Volume * (all volumes)

GTMUCBBD Disk Device ALL

GTMCATBD Catalog entry ALL

GTMVTCBD data set ALLVTOCS


3. Register the SMS resources for interval monitoring by right-clicking the operating system object and selecting Source/390 -> SMS -> Register Intervals as shown in Figure 11-28.

Figure 11-28 Register monitoring interval for SMS resources


4. Storage resources such as disk devices can be viewed by right-clicking the operating system object and selecting Open -> Disk Devices. A sample view is shown in Figure 11-29. Other information can be retrieved from Open -> Catalog and Open -> Catalog Entries.

Figure 11-29 Disk configuration

11.10 DFSMS Hierarchical Storage Manager This section describes the configuration steps for DFSMShsm data source integration into IBM Tivoli Business Systems Manager. We did not install the HSM Monitor/Tuner interface in our scenario.

11.10.1 ConceptThe HSM messages are trapped from the system console. This happens when a definition for HSM object exists under the Operating System object.


11.10.2 Integration setupThe DFSMShsm environment does not require discovery because the resource structure is fixed. The only step to perform it is to insert a Hierarchical Storage Manager resource under the operating system resource as shown in Figure 11-30.

Figure 11-30 Creating an HSM object


You then specify the name of the new object. We use DFSMSHSM, as shown in Figure 11-31.

Figure 11-31 HSM creation


This results in a DFSMSHSM resource with nine child resources, as shown in Figure 11-32.

Figure 11-32 DFSMShsm topology view

DFSMShsm messages are predefined and uploaded to the Source/390 object pump when the address space is initialized. No customization is required.

11.11 WebSphere HTTP Server for OS/390This section describes the configuration steps for HTTP server data source integration into IBM Tivoli Business Systems Manager.

11.11.1 Integration setupSeveral stepsmust be performed for this integration:

� Modify hlq.SGTMSAMP(GTMWSBD) to send the HTTPD configuration file (httpd.conf) to the MVS IP listener. This will create an HTTP Server Template resource on the console for each existing configuration file. Subsequent HTTP Server events are related to the appropriate HTTP Server Template.


This job uses the OGET command to retrieve a file from UNIX System Services, so the user ID that runs this job must have a USS permission.

� Configure, enable and schedule the following SQL server jobs on the database server: HTTP Discovery Load and HTTP Discovery Process.

11.11.2 Object discoveryObject discovery is initiated when an HTTP server process is started. The messages are captured out of the system console. Figure 11-33 illustrates a discovered WebSphere Server Template resource and an HTTP Server resource created by a startup event.

Figure 11-33 HTTP Server objects


Part 4 Advanced configuration

This part deals with additional configurations that you can perform to your system. The chapters are:

� Chapter 12, “Automatic Business System View creation” on page 395

� Chapter 13, “Setting up roles and security” on page 421

� Chapter 14, “Maintenance and tuning issues” on page 437

� Chapter 15, “Automatic problem ticketing” on page 465

� Chapter 16, “High availability and failover” on page 513

� Chapter 17, “Historical reporting with TEDW” on page 527

Part 4


Chapter 12. Automatic Business System View creation

This chapter deals with the automatic creation of Business System Views and some consideration on alternate methods. The content of this chapter should be used in conjunction with the planning information in 5.7, “Business System requirements” on page 139.

The topics covered in this chapter are:

� 12.1, “Automatic Business System View” on page 396 gives the concepts of automatic Business System View creation

� 12.2, “ABS usage example” on page 403 shows how to use the automatic business system creation

� 12.3, “Distributed LOB rules to ABS migration” on page 414 describes some migration consideration for LOB rules to the ABS

12


12.1 Automatic Business System ViewThe Business System View (BSV) creation performed by dragging and dropping resources from the All Resources View hierarchy into the Business System hierarchy works well for only a small number of resources. When the resources to be inserted are in the order of hundreds, the drag-and-drop method becomes time-consuming and error-prone.

This section discusses IBM Tivoli Business Systems Manager’s new feature, Automatic Business System, that enables the automatic creation of Business System Views.

12.1.1 Automatic Business Systems designThe Automatic Business System (ABS) enables the creation of a BSV without using the drag-and-drop method from the console. Instead, a BSV is created automatically based on a set of criteria defined in the configuration file. This configuration file is discussed in 12.1.2, “Automatic Business Systems configuration file” on page 397.

The process is configured using a command line utility from IBM Tivoli Business Systems Manager database server. Eeveral tasks in SQL Server Agent must be enabled and scheduled regularly to facilitate the ABS process.

The ABS processing schematic is shown in Figure 12-1.

Figure 12-1 ABS processing

absConfig.ksh

ABS Creation ProcessABS Discovery Process

Config file

Update ObjPathCache

alobListPatternalobListCriteriaAlob

dynamic_object_create_path_detaildynamic_object_create_path

evQueueObject

Object creation or update triggerstI_EV<cid>_CtU_EV<cid>_CtU_EV<cid>_A

ObjPathCache alobQueueCreateLOBev_auto_create_object_parm

ABS Table Purge


The command absConfig.ksh configures the Automatic Business System View creation. It takes as input the configuration file and loads the necessary entries in the database for all the ABS configuration criteria.

These configuration values are stored in these tables:

alobListPattern List of the pattern-matching attributes

alobListCriteriaAlob List of the criteria for a BSV creation

dynamic_object_create_path_detail Correlation between BSV path and the criteria

dynamic_object_create_path List of paths needed to create the BSV

When the configuration is completed, the database starts to monitor the system for creation or update of resources. Whenever a new resource is inserted or an attribute of the monitored resources changes, the following takes place:

1. A trigger captures the modification, and the new or changed attribute data is queued in the table evQueueObject.

2. The UpdateObjPathCache job running as scheduled (15 minutes by default) updates the resource relationships in the table ObjPathCache.

3. The ABS Discovery Process job, scheduled every minute, checks the evQueueObject table and, if the criteria provided in the last configuration file have been met, populates the tables alobQueueCreateLob and ev_auto_create_object_param with the new data. This job process only the events with a ctime lower than or equal to the start time of the last successful completion of the UpdatePathCache job. Events created after this time will be queued until the next successful running of the UpdateObjPathCache job.

4. The ABS Creation Process job, scheduled every minute, processes the data stored in the tables populated by the ABS Discovery Process job and creates or updates the BSV.

5. The ABS Table Purge job, scheduled to run occasionally, removes data older than 30 days from the tables used by the automated BSV processing system.

12.1.2 Automatic Business Systems configuration fileThe ABS configuration file contains the information used by the ABS discovery process to determine whether to modify the BSV structure for the created or updated object. The information identifies all the resources that are eligible to

Attention: Loading a new configuration file completely replaces the old configuration, but it keeps the existing Business System Views. These BSVs may not be current and you may want to recreate all the BSVs.

Chapter 12. Automatic Business System View creation 397

become part of Business System Views. The uniqueness of the configuration file permits a fast inspection, modification, or reuse of the data.

The configuration file consists of five sections:

PatternList The list of all the operands that can satisfy the pattern.

Pattern The list of all the patterns with their attributes and the logical conditions or operations that the attributes must satisfy

CriteriaToPattern The list of the criteria used for the patterns and the relationship between patterns within the same criteria

Path The list of all the BSVs that could be created and their hierarchical order

CriteriaToPath The list of all BSVs that should be created when the particular criteria is met

Every section is structured in table format with two or more columns. Each section header line is followed by a field header line. As an illustration, we show a very simple configuration file for a BSV with DB2 subsystem (D2SS) and IMS subsystem (IMSS) resources in Example 12-1.

Example 12-1 Sample configuration file

PatternListListName OperandPL_1 DB%PL_1 D2%

PatternPattern Class Attribute When Operator Operand1 Operand21 D2SS name Current LIKE LIST PL_1 %2 IMSS name Current LIKE IMS% %3 IMSS Path Current LIKE %SC66% %

CriteriaToPatternCriteria Pattern PatternRelated1001 1 11002 2 21002 3 2

PathPath Level NamePP_0_0 1 Remote BankingPP_0_0 2PP_0_1 1 Remote BankingPP_0_1 2


CriteriaToPathCriteria Path Level Pattern Variable Value1001 PP_0_0 2 1 name <1:name>1002 PP_0_1 2 3 name <3:name>

To interpret this configuration file, we start with the Path definition. Assign a name for each path definition, its level, and its name. Use a different path name for each type of object that you want to put in the same place. This sample puts DB2 subsystem and IMS subsystem objects under a BSV folder Remote Banking. The columns for the Path section are:

Path A string representing the BSV that will be created but is not seen outside the database.

Level The number of levels from the Business System Container.

Name The name of the static business system folder. This does not represent a physical object. Leave this field blank if this level in the Path represents a dynamically created object.

As we know that we want to put the DB2 subsystem and IMS subsystem under Remote Banking, we have to associate each of them to a criteria. Typically for a criteria, we use a large number. We assign them 1001 for DB2 subsystem objects and 1002 for IMS subsystem objects.

For each criteria, we define a pattern or patterns that can be applied to an object to test whether it matches the criteria. These patterns are defined in the Pattern section and some information is located in the Pattern List section.

Let’s evaluate what we want to do:

� For the DB2 subsystem (cid = D2SS), we want all DB2 subsystems that match either DB* or D2*. The first line in Example 12-1 on page 398 for Pattern section reads:

1 D2SS name Current LIKE LIST PL_1 %

It defines a pattern for object D2SS (DB2 subsystem) that can match to several patterns (or conditions). These pattern lists are defined in the Pattern List section. PL_1 is the pattern list identifier that contains a match to DB% and D2%. (As this uses SQL, % is a wildcard.)

� The IMS subsystem that we want is different, as its name begins with IMS* and it must be located under the SC66 operating system. Therefore it must match two patterns as shown in Example 12-1 on page 398:

2 IMSS name Current LIKE IMS% %3 IMSS Path Current LIKE %SC66% %


Pattern 2 identifies that the name field must start with IMS, and pattern 3 designates that the path must contain SC66.

PatternList definitions are:

ListName Provides the name for a pattern list. The name matches the Operand1 column in the Pattern section when the operator used is a LIKE LIST or a NOT LIKE LIST.

Operand A valid SQL pattern.

Pattern definitions are:

Pattern A unique integer identifier used in the CriteriaToPattern section to identify the pattern for each criteria.

Class The four-letter code representing the internal IBM Tivoli Business Systems Manager class name on which the pattern test will be attempted.

Attribute The attribute of the Class that identifies the aspect of the object class on which the pattern test will be performed.

When The version of the attribute value on which the test will be performed. Can be current or previous.

Operator The operator type used to test the pattern. These are the operands:

LIKE, NOT LIKE,=,<>,>,<,>=,<=,LIKE LIST, and NOT LIKE LIST use only operand1.

BETWEEN, NOT BETWEEN, and EGREP use both the operand1 and operand2.

Operand1 The first argument for the operator. For BETWEEN and NOT BETWEEN, it is the first or lower argument in the range. For IS, it is either NULL or NOT NULL. For LIKE LIST and NOT LIKE LIST, it is the ListName in the PatternList section. For EGREP, it is the first argument.

Operand2 The second argument for the operator, used for BETWEEN, NOT BETWEEN, and EGREP. All other operators should use a “%” character as a placeholder.

Now we can match the patterns with the criteria that we defined in the CriteriaToPattern section. Pattern 1 is associated with criteria 1001 and patterns 2 and 3 are associated with criteria 1002. Definitions for CriteriaToPattern are:

Criteria A unique integer that identifies a group of patterns that should be evaluated together.


Pattern An integer pointing to an existing pattern in the Pattern section.

PatternRelated An integer pointing to the pattern that will be ANDed with this pattern, either for nested business system view or for multiple pattern matching for a criteria.

Now that we have defined the paths and criterias, we must start matching them, first by associating them in the CriteriaToPath section. This is where we associate path PP_0_0 on level 2 to criteria 1001, and path PP_0_1 at level 2 to criteria 1002. There are options for performing variable substitutions for the business system view object attribute from the associated pattern and attribute, such as using the description field as the name, and so on. The definitions are:

Criteria A pointer to a criteria described in the CriteriaToPattern section.

Path A string equal to a path value in the Path section.

Level A pointer to the Level field in the Path section indicating the hierarchy level, from the BSV container, where the BSV will be dynamically created.

Pattern This value combined with the criteria pointer identifies the resource that, meeting the specified pattern number, will be dynamically added to the business system view at this level.

Variable A string indicating the attribute that will be substituted.

Value A string of the form <Pattern:Attribute>. The string will be evaluated and the result assigned to the Variable field. This string allows for replacement values based on the pattern that satisfies the criteria.

For example, <1:name> will resolve to the object that satisfied pattern 1’s name.

The string also can be a combination such as <2:IPAddress>@<1:name> and it will resolve to the object that satisfied pattern 2’s IP address and pattern 1’s name.

The pattern referenced as a replacement value does not have to be the same pattern referenced in the Pattern column of this row. It has just has to be a pattern that satisfies the criteria.


12.1.3 Defining the Automatic Business SystemTo facilitate the creation of the ABS configuration file, some activities have to be performed. This is the main workflow:

1. Get the requirements for the business system views.

2. Design the hierarchical structures:

Determine the BSV structure by designing it external to IBM Tivoli Business Systems Manager, pointing out its hierarchy and which resources are static placeholder folders and which are logical representations of resources.

3. Determine how to identify the physical objects that will be placed in the business system, looking at the available attributes that make them unique such as Name, Description, IP Address, IP Hostname, Manufacturer, and so on.

To determine the list of valid attributes, use the absAllowedClassAttribute command. For example, to get the attribute for an OS class to a file called OS_attr.txt, use the command:

absAllowedClassAttribute.ksh -cOS -oOS_attr.txt

To get the attribute for all classes use the command:

absAllowedClassAttribute.ksh -oclassattr.txt

4. Examine which values or aspects of the attributes can uniquely identify the resources to be placed in the BSV or if these values are common to other resources. Use the following SQL operators to describe the condition that can identify the resources:

– LIKE, NOT LIKE

– =, <>, >, <, >=, <=

– BETWEEN, NOT BETWEEN

– IS NULL, IS NOT NULL

5. Examine whether the resources required for theBusiness System adhere to a naming convention technique or write a list of all the resources that can be grouped responding to certain criteria.

Once these activities are completed, the configuration file can be filled in easily with all the data gathered. The next section shows another example of creating an ABS configuration file.


12.2 ABS usage exampleIn this section, we show an example of building an ABS configuration file for the scenario to make a business system view hierarchy as shown in Figure 12-2.

Figure 12-2 Sample business system view

The Operating Systems business system view has to contain all of the production operating systems that in our naming convention begin with SC and M. The DB2 Subsystems BSV has to contain all the production DB2 subsystems with the name not starting with DB.

Let’s create the configuration file.

12.2.1 Manual creation of the business system viewThe OS resources can be grouped into a list we call OPER_SYS and assigned with the operands S% and M% that match the double naming convention we have established. The DB2 resources do not have to be grouped into a list because only the naming convention DB% has to be matched so a line in the ListName column would be useless. The PatternList section is in Example 12-2.

Example 12-2 PatternList section

Pattern List ListName Operand OPER_SYS S%OPER_SYS M%

The resources we want to filter are the OS class and the D2SS class. The attribute of the class on which we want to perform the test is Name. The operators LIKE LIST and NOT LIKE are performed on the resource’s class attribute to identify the resources we are interested in. The Pattern section is in Example 12-3 on page 404.

ITSO Resources

Operating Systems

DB2 Subsystems

Dynamic OSesStart with SC* or M*

Dynamic D2SSNot start with DB


Example 12-3 Pattern section

PatternPattern Class Attribute When Operator Operand1 Operand21 OS name Current LIKE LIST OPER_SYS %2 DB2 name Current NOT LIKE DB% %

The preceding patterns do not have to be evaluated together. The OS and DB2 resources do not have any common relationships. We have to write different groups of criteria for the two patterns. The CriteriaToPattern section is in Example 12-4.

Example 12-4 CriteriaToPattern section

CriteriaToPatternCriteria Pattern PatternRelated1001 1 11002 2 2

The business system view hierarchy we want to create is formalized in the Path section as shown in Example 12-5.

Example 12-5 Path section

PathPath Level NamePROD_OS 1 ITSO RESOURCESPROD_OS 2 Production OSPROD_OS 3PROD_DB2 1 ITSO RESOURCESPROD_DB2 2 Production DB2PROD_DB2 3

We want create the resources in the BSV with their name and a new description. The section CriteriaToPath is shown in Example 12-6.

Example 12-6 CriteriaToPath section

CriteriaToPathCriteria Path Level Pattern Variable Value1001 PROD_OS 3 1 name <1:name>1001 PROD_OS 3 1 Desc Production_OS1002 PROD_DB2 3 2 name <2:name>1002 PROD_DB2 3 2 Desc Production_DB2


CriteriaToPath is the last section of our configuration file. For example, if the whole configuration file is called BSVcurrent.txt we load it in the datatabase using the command:

sh absconfig.ksh -Sibmtiv5 -Usa -PXXXX -iBSVcurrent.txt

The data is processed and inserted in the database. The tables filled with the ABS data are alobFilePatterList, alobFilePattern, alobFileCriteriaToPattern, alobFilePath, and alobFileCriteriaToPath. Figure 12-3 shows those tables and their entries resulting from our example.

Figure 12-3 Database tables with the loaded ABS configuration


The ABS engine is now ready to add the BSVs dynamically when a new resource is discovered or an attribute of the monitored resources is updated or changes. The resources already present in the All Resources View have to be processed to make them appear in the BSVs. The command absTest.ksh is used to test the configuration and to discover the Business Systems by using the command discovery and queuing options. For a detailed description of the absTest.ksh syntax see the IBM Tivoli Business Systems Manager: Administrator’s Guide, GC32-0799 on page 461. The BSVs discovered by the absTest.ksh command are queued into the alobQueueCreateLob and ev_auto_create_object_param tables. They can be created by running the ABS Create Process job manually or executing the SQL EXECUTE alobProcessQueueCreateLob from the Query Analyzer window. The result of our example is shown in Figure 12-4.

Figure 12-4 ITSO RESOURCES business system view


12.2.2 BSV creation toolAs you may have noticed, the effort to create the business system view definition for a simple BSV structure is cumbersome. We developed a Java-based tool in our lab to create the BSV structure using a graphical interface, and we used it to produce some of our definitions. This quick-and-dirty tool has some limitations:

� It does not cover all possibilities and combinations that can be derived by editing the configuration file manually.

� It does not support mapping of attributes in the CriteriaToPath section; it simply puts the mapping of the name into itself in that section. This is mostly adequate for the majority of cases.

� It does not have extensive error-checking for the operand against the operator.

You can get the tool from the additional material that accompanies this book as described in Appendix D, “Additional material” on page 577.

To use the tool, extract the class and attribute definition from the IBM Tivoli Business Systems Manager database using:

absAllowedClassAttribute.ksh -oclassattr.txt


Put the classattr.txt file into the same directory as the Java classes and invoke java ABSMain .\classattr.txt to open the initial window as shown in Figure 12-5.

Figure 12-5 ABSMain window


Now we will try to implement the ITSO RESOURCES business system view as in the previous section. These are the steps:

1. Click Add BSV to create a new node under ROOT. You can now edit the Name field using ITSO Resources as the name. Press ENTER. The display will be similar to Figure 12-6.

Figure 12-6 First BSV ITSO Resources


2. Select the ITSO Resources node and click Add BSV to add the second level business system view folder and call it Operating System. Again, we select the ITSO Resources node and click Add BSV to add the DB2 Subsystem business system view folder. The result is shown in Figure 12-7.

Figure 12-7 BSV tree for the example


3. Now select the Operating Systems node and click Add Filter. This will define a new node that represents a dynamically added resource for defining patterns. Here we called the filter Production OS, as shown in Figure 12-8.

Figure 12-8 Adding Production OS filter


4. For this filter, select the Condition tab. Specify the Class name, and the attribute and condition that you want to apply. For multiple conditions, click Add to add an additional condition page. This additional condition page can apply only to the same object class. The condition for the Production OS is shown in Figure 12-9.

Figure 12-9 Defining condition for production OS

In this example, the list of conditions applies to the LIKE LIST operator and are separated by a semi-colon. Press ENTER whenever you finish entering any string in a text field area to ensure that Java receives this field.


5. From the DB2 Subsystems node, click Add Filter and call it Production DB2. Specify the condition in the Condition tab as shown in Figure 12-10.

Figure 12-10 Condition for Production DB2

6. Now we can generate the configuration file using File -> Generate. Specify the path that you want the configuration file to run, and click Generate File.

The result is shown in Example 12-7.

Example 12-7 Scenario1.txt

PatternListListName OperandPL_1 SC%PL_1 M%

PatternPattern Class Attribute When Operator Operand1 Operand21 OS name Current LIKE LIST PL_1 %2 D2SS name Current NOT LIKE DB% %



PathPath Level NamePP_0_0 1 ITSO ResourcesPP_0_1 1 ITSO ResourcesPP_0_0 2 Operating SystemsPP_0_0 3PP_0_1 2 DB2 SubsystemsPP_0_1 3

CriteriaToPathCriteria Path Level Pattern Variable Value1001 PP_0_0 3 1 name <1:name>1002 PP_0_1 3 2 name <2:name>

This is similar to the pattern that we hand-built except for some of the internal names and numbers.

12.3 Distributed LOB rules to ABS migration This section discusses the migration of the existing distributed line of business rules to the new Automatic Business System Views process. The discussion consists of:

� 12.3.1, “Migration description” on page 414

� 12.3.2, “Migration example” on page 415

12.3.1 Migration description The IBM Tivoli Business Systems Manager base installation does not provide an automatic migration from the distributed Line of Business (LOB) rules to the new ABS process. The rules have to be migrated manually.

The commands addLOB.sh, addpvToLOB.sh and addpvToLOBInst.sh add rules into the database that specify the Business System Views that have to be created dynamically and the filtering criteria to use for resources that are received mainly from TEC. These commands were available in the IBM Tivoli Business Systems Manager version 1.5 and are still supported in Version 2.1 for backward compatibility.

The migration process consists of extracting the existing distributed rules from the database, rearranging them to be compatible with the new Automatic Business System format, loading them into the database using the ABS configuration file, and disabling the processing of the distributed rules.


12.3.2 Migration exampleThe Distributed Network and TEC GenericBSVs in Figure 12-11 have been created dynamically and populated with distributed resources using the commands addLOB.sh and addpvToLOB.sh.

Figure 12-11 Distributed Line of Business

Figure 12-12 shows the contents of the GEM_InstFiltering table. The memExpr column lists the input we chose for filtering the events. The memPattern column lists the regular expression pattern used by the filtering utility to match the input.

Figure 12-12 GEM_InstFiltering table

Only those instances of the G02K and G02E class that come with an host name starting with the string “ibmtiv” are filtered and added automatically into the Distributed Network BSV. The resources of the class G02J are added to the TEC Generic BSV only if their host name does not contain the ibmtiv string. This last condition is stated by the value zero in the memTest column. The migration script


cannot automatically convert certain values of the GEM_InstFiltering columns. Table 12-1 shows the values not supported by the migration script.

Table 12-1 Distributed rules not supported by the migration script

The preceding values represent distributed rules that must be added manually into the ABS engine.

The migration process we followed consists of these steps:

1. Convert the distributed rules to the Automatic Business System format using the migrateToAbs.ksh script.

2. Manually add the distributed rules that are not supported to the output file generated by the preceeding step.

3. Load the modified output file into the database with the absConfig.ksh script.

4. Disable the distributed rules, setting the enable_gem_auto_lob parameter to no in the GEM_Options table.

The migrateToAbs.ksh command syntax is explained in detail in the IBM Tivoli Business Systems Manager: Administrator’s Guide, GC32-0799. This script calls

GEM_InstFiltering column Value

memTest when = 0

memOptions

memExpr %HB_PRIMARY%%HB_SECONDARY% or more then one symbol

exclusive when <> 0

priority when <> 0

Note: The GEM_InstFiltering table is preloaded with all the filtering definitions for all the default IBM Tivoli Business Systems Manager class IDs from G000 to G02C. The migration process takes in all the data stored in that table, so the migration output file would contain a filtering criteria for each class represented in the table.

In our example we have deleted all the rows of the GEM_InstFiltering table other than those representing the filtering criteria that we inserted with the addpvToLOB.sh command. Now our output file contains just the criteria for the classes we are interested in putting into our BSV. This selection could be also done within the output file itself to eliminate each section’s unneeded criteria.


the gemsp_migrateToAlob stored procedure, which converts the distributed rules and stores the data in the GEM_Pattern, GEM_CriteriaToPattern, GEM_Path, and GEM_CriteriaToPath tables. The script also produces an output file in the same format as the ABS configuration file.

We use the sh migrateToAbs.ksh -Sibmtiv5 -Usa -PXXXX -o migrateToAbs.txt command to generate the migrateToAbs.txt configuration file. The output file generated by the migration script is shown in Example 12-8.

Example 12-8 Output file migrateToAbs.txt

PatternListListName Operand

PatternPattern Class Attribute When Operator Operand1 Operand21 G02E MgedSystemName Current EGREP i ibmtiv*2 G02K MgedSystemName Current EGREP i ibmtiv*


PathPath Level NameDistributed NetworkLOBC 1 Distributed NetworkDistributed NetworkLOBC 2

CriteriaToPathCriteria Path Level Pattern Variable Value1 Distributed NetworkLOBC 2 1 name <1:name>2 Distributed NetworkLOBC 2 2 name <2:name>

The migration tool also produces a log file containing the patterns that could not be migrated. Example 12-9 shows the contents of the log file in our example.

Example 12-9 Log file migrateToAbs.txt.log

gemsp_migrateToAlob: @start_pattern_id=[1], @start_criteria_id=[1], @rm_dup_patterns=[1]Non-Migratable Patterns - do them manually !! cid LOBKey memOptions memPattern memExpr memTest enabled exclusive priority ---- ---------------------------------- ---------- ---------- ------------- -------- ------- --------- -------- G02J TEC GenericDistributed NetworkLOBC SQL_LIKE ibmtiv* %HB_HOSTNAME% 0 1 0 0


These patterns have to be added to the output file manually. Example 12-10 shows the output file migrateToAbs.txt after editing.

Example 12-10 Output file after the manual adding of the rule not processed

PatternListListName Operand

PatternPattern Class Attribute When Operator Operand1 Operand21 G02E MgedSystemName Current EGREP i ibmtiv*2 G02K MgedSystemName Current EGREP i ibmtiv*3 G02J MgedSystemName Current NOT LIKE ibmtiv% %

CriteriaToPatternCriteria Pattern PatternRelated1 1 12 2 23 3 3

PathPath Level NameDistributed NetworkLOBC 1 Distributed NetworkDistributed NetworkLOBC 2TEC Generic 1 Distributed NetworkTEC Generic 2 TEC GenericTEC Generic 3

CriteriaToPathCriteria Path Level Pattern Variable Value1 Distributed NetworkLOBC 2 1 name <1:name>2 Distributed NetworkLOBC 2 2 name <2:name>3 TEC Generic 3 3 name <3:name>

In case the ABS feature has already been configured, the preceeding output file should be combined with the existing ABS configuration file. The consolidated configuration file should then be loaded into the database. We then invoke sh absconfig.ksh -Sibmtiv5 -Usa -Psa_ibmtiv5 -i migrateToAbs.txt to activate the configuration.

The ABS is now configured, and its configuration data is stored in the database.

The automatic LOB for distributed rules are still active. To disable the distributed rules the enable_gem_autolob parameter of the GEM_Options table must be set to no as shown in Figure 12-13 on page 419.


Figure 12-13 Table GEM_Options


Chapter 13. Setting up roles and security

This chapter deals with securing the IBM Tivoli Business Systems Manager environment. The IBM Tivoli Business Systems Manager servers’ security model relies heavily on Windows security features.

The discussion in this chapter is structured as:

� 13.1, “Resource security” on page 422 discusses the Windows security model that we used

� 13.1.3, “Windows user ID and groups” on page 429 discusses password-related issues

� 13.4, “TBSM operators and workspaces” on page 434 illustrates the IBM Tivoli Business Systems Manager operator definition within our domain and the work-spaces definition

13


13.1 Resource security IBM Tivoli Business Systems Manager uses the Windows facility extensively. For this reason, we must use Windows’ built-in security features to enforce controlled access to IBM Tivoli Business Systems Manager resources. The following subsection provides an overview of the resources and security models that we used.

13.1.1 Protecting files and directoriesIn line with the aim to optimize Windows security features, we implemented the NT file system (NTFS) for all servers that provide a more granular security and protection capability compared to the FAT file system.

Windows has the ability to change access permissions to drives, files, and directories and can audit activities on these as well. IBM Tivoli Business Systems Manager codes reside on Windows and use Windows networking shares to communicate. These files and shares on IBM Tivoli Business Systems Manager servers have to be protected.

We modified the permission of files and directories under the TivoliManager path where we installed the IBM Tivoli Business Systems Manager code in our IBM Tivoli Business Systems Manager servers.


To duplicate our example: In Windows Explorer, right-click on the directory and select Properties as shown in Figure 13-1.

Figure 13-1 Changing TivoliManager directory’s property

Chapter 13. Setting up roles and security 423

From the TivoliManager Properties window, click the Sharing tab and select the Do not share this folder radio button, as shown in Figure 13-2.

Figure 13-2 Sharing property for the TivoliManager directory


Modify the security properties from the Security tab of the TivoliManager Properties window, as shown in Figure 13-3 on page 425:

� Click Add to add Administrators and the local SYSTEM account. We added the SYSTEM account with Full Control because all the IBM Tivoli Business Systems Manager services need access. You may want to grant specific access for other administrators.

� Clear the check box for Allow inheritable permissions from parent to propagate to this object. Confirm by clicking Apply.

Figure 13-3 Security property of TivoliManager directory

Click the Advanced button to open the Access Control Settings for Tivoli Manager window, and check Reset permissions on all child objects, as shown in Figure 13-4 on page 426.


Figure 13-4 Advanced security setting

Click OK to return to the Properties window, and click OK to close it.

13.1.2 Protecting the registryThe Windows Registry stores important configuration options that are critical to the operation of IBM Tivoli Business Systems Manager services. The Registry also contains passwords, such as the Microsoft SQL Server system administrator password, for accessing the IBM Tivoli Business Systems Manager database. Protecting the registry is very important, as we want only administrators to be able to change—or even read—this information.


To change permissions on the IBM Tivoli Business Systems Manager registry keys for the IBM Tivoli Business Systems Manager servers listed in the previous section:

1. Open the Registry Editor (REGEDT32.EXE).

2. Highlight the registry key for HKEY_LOCAL_MACHINE - SOFTWARE - Accessible Software, Inc.

3. Open the Security -> Permissions... menu, as shown in Figure 13-5.

Figure 13-5 Protecting TBSM registry key


4. Change the permission option for the IBM Tivoli Business Systems Manager registry key and its subkeys. We removed its inheritable security access and only allowed the Administrators and local SYSTEM accounts to have full control. Figure 13-6 shows the Permissions window.

Figure 13-6 TBSM registry permissions


5. Click the Advanced button to open the Access Control Settings window.

Be sure the Reset permissions is checked to propagate the settings for the existing sub-keys, as shown in Figure 13-7 on page 429.

Figure 13-7 Advanced permissions setting

Click OK to return to the Permissions window, and click OK to close it.

13.1.3 Windows user ID and groupsThe IBM Tivoli Business Systems Manager console is a restricted application. Only authorized users should run it. Users are authenticated on the Console Server to ensure that they are connected to the appropriate IBM Tivoli Business Systems Manager groups. There are four levels of IBM Tivoli Business Systems Manager authentication:

� TBSM_Administrator_Super� TBSM_Administrator� TBSM_Operator� TBSM_Operator_Restricted


13.2 Password protectionPasswords can be viewed as a special access control that can enforce security and, at the same time, introduce a security risk whenever a password is known to unauthorized persons. For security reasons, passwords should be changed at regular intervals. This section deals with the role of passwords related to IBM Tivoli Business Systems Manager and the task of changing passwords without interrupting IBM Tivoli Business Systems Manager availability.

The following subsections discuss several issues related to IBM Tivoli Business Systems Manager passwords:

� Section 13.2.1, “TBSM processes passwords” on page 430 discusses Windows passwords for IBM Tivoli Business Systems Manager services

� Section 13.2.2, “Microsoft SQL Server” on page 432 covers Microsoft SQL Server’s system administrator passwords

� Section 13.2.3, “Reporting system password” on page 433 discusses Reporting system passwords

13.2.1 TBSM processes passwordsMost IBM Tivoli Business Systems Manager processes run on the local system user ID, which does not require a password. However, specific, password-protected user IDs are required for certain processes we discuss here:

� Microsoft SNA server processes� TPSTART.EXE� Task server

The SNABase processSNA client applications access the mainframe Object Server task via the SNA server machine. For this reason, the SNA client requires authority to access the SNA server machine and vice versa. The SNA server and the SNA client services must be started with the same user ID and password. That user ID is defined in the services property for SNAbase.

If we were to change the password for the user ID used to start the SNA client, we would have to change the password for the same user ID on the SNA server. The reverse also is true.


TPSTART considerationTPSTART must be opened from the Startup folder of a Windows user ID. This requires the Event Server to be logged on continuously. An automatic logon mechanism in the Windows registry is stored in the following key:

HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon

Figure 13-8 shows the Winlogon key for the Event Server.

Figure 13-8 Automatic logon for Event Server

The following values must be defined:

DefaultUserName Default user ID for the Windows machine.

DefaultDomainName Default domain for the Windows machine.

DefaultPassword Default password for the Windows machine.

AutoAdminLogon Sets the automatic log on feature using the defaults. This value must be set to 1.

This means that the password of the logged-on user ID is hardcoded into the registry, so when the actual password is changed the registry definition must be modified accordingly.


Task server password considerationThe task server executes z/OS commands using Tivoli NetView for z/OS. IBM Tivoli Business Systems Manager requires individually an authenticated user ID and password for the connection to Tivoli NetView for z/OS. This password is specified dynamically at run time. The command tserver hostcmdoper is no longer used.

13.2.2 Microsoft SQL ServerChanging the system administrator (sa) password for the Microsoft SQL Server database requires updating the sa user password in the registry of each IBM Tivoli Business Systems Manager server. We found the database password in the following registry keys on our IBM Tivoli Business Systems Manager servers:

HKLM\SOFTWARE\Accessible Software, Inc.\Access1\1.0\Settings\DBHKLM\SOFTWARE\Accessible Software, Inc.\Access1\1.0\Settings\Model\ParamsHKLM\SOFTWARE\Accessible Software, Inc.\Access1\1.0\Settings\Model\Params\SetupDefaults

In some servers, additional keys contain the SQL server’s password, including:

� Propagation server

[HKEY_LOCAL_MACHINE\SOFTWARE\Accessible Software, Inc.\Access1\1.0\Propagation Agents\DB]

� Database server and history server

[HKEY_LOCAL_MACHINE\SOFTWARE\Accessible Software, Inc.\Access1\1.0\Components\TSDEventHandler][HKEY_LOCAL_MACHINE\SOFTWARE\Accessible Software, Inc.\Access1\1.0\PADispatcher\DB]

� Health monitor server

[HKEY_LOCAL_MACHINE\SOFTWARE\Accessible Software, Inc.\Access1\1.0\Health Monitor\Profiles\IBMTIV6\DB]


13.2.3 Reporting system passwordThe online reporting system’s user ID authentication mechanism stores the user ID and password in the histUsers table in the WebServer database. This database contains various reporting system functionality attributes, such as menu system and reports. Figure 13-9 on page 433 shows the default content of the histUsers table.

Figure 13-9 Historical database users

You must modify and maybe add rows to this table to confirm your security standard.

13.3 TBSM command securityAs with the IBM Tivoli Business Systems Manager operators, command security can only be implemented with one of twosecurity levels: accessible by the operator or not accessible by the operator. The security column contains a string in the MenuItem table that will be matched with the executing agent. If there is a match, the command will be executed. Figure 13-10 on page 434 shows a sample extract of the MenuItem table.


Figure 13-10 Extract of the MenuItem table

Several security column values make the menu accessible for an administrator but inaccessible for an operator. Additionally, recentfile_view is available for both operator and administrator, while document_print is disabled for both.

For more information about commands and the MenuItem table, see 3.7, “Menu and command” on page 97.

13.4 TBSM operators and workspacesThis section discusses IBM Tivoli Business Systems Manager operators. Operators are restricted users of IBM Tivoli Business Systems Manager with access limited to their own resources (those assigned into their Critical Resource List Business System). When an operator needs specific access to another part of the Business System, a IBM Tivoli Business Systems Manager administrator can create a workspace.

A workspace is a pre-defined set of windows that enable an operator to see and manage beyond the Critical Resource List. An administrator configures a workspace, and can saved it by selecting Save Workspace from the Console menu, which opens a dialog similar to Figure 13-11 on page 435.


Figure 13-11 Saving a workspace

In this dialog, permission can be given to an operator to open the workspace to gain access to additional resources. An administrator can open any workspace from the Console menu to open the dialog shown in Figure 13-12.

Figure 13-12 Opening a workspace


In the Open Workspace dialog, click Edit to modify the workspace access list with the dialog shown in Figure 13-13.

Figure 13-13 Editing a workspace permission

In IBM Tivoli Business Systems Manager, workspace files are stored under the console server (TivoliManager\ConsoleServer\workspaces) and not accessed directly by the operator.


Chapter 14. Maintenance and tuning issues

In this chapter, we describe some regular tasks that must be performed to keep IBM Tivoli Business Systems Manager running. These include the jobs that are run under SQL Server Agent, regular maintenance activities, and performance tuning. The discussion covers the following sections:

� 14.1, “SQL Server Agent jobs” on page 438 discusses the functions of the provided SQL Server Agent jobs.

� 14.2, “Database maintenance” on page 445 shows how to maintain anIBM Tivoli Business Systems Manager database, from both the data point of view and the database point of view.

� 14.3, “Microsoft SQL Server and Windows 2000 tuning” on page 458 gives some tips on avoiding primary performance pitfalls that you should avoid.

14


14.1 SQL Server Agent jobsIBM Tivoli Business Systems Manager comes with several pre-defined jobs in SQL Server Agent database (msdb). Most of these jobs are needed to ensure automatic operation of the IBM Tivoli Business Systems Manager, including object discovery and other automatic actions.

Some of these jobs are enabled by default although they may not be necessary, and other jobs are needed but require some customization before they can be enabled. This section discusses these jobs and their characteristics.

The SQL Server Agent jobs can be grouped into several categories, and the following sections discuss our job setup recommendations for each category.

� 14.1.1, “z/OS-related jobs” on page 438

� 14.1.3, “Database maintenance jobs” on page 440

� 14.1.2, “Distributed resources jobs” on page 440

14.1.1 z/OS-related jobsAll of the z/OS resources jobs help in the discovery and processing of resource data coming from particular z/OS data sources. The data comes from the z/OS either as binary files or text files and is stored in the database through some scripts invoked by the MVSIPListener service.

These jobs should be enabled only if IBM Tivoli Business Systems Manager monitors the particular environment to which they pertain. For example, if the implementation uses CICSPlex/SM to monitor CICS resources, the CICS Discovery Load and CICS Discovery Process jobs must be enabled.

Table 14-1 lists the z/OS resources jobs grouped by the particular component they refer to and our suggested settings.

Table 14-1 z/OS Resources SQL jobs: suggested settings

z/OS resources jobs Suggested settings

CICS Discovery LoadCICS Discovery ProcessCleanup CPSM discovery-related tablesCleanup CICS Startup/Shutdown TasksDelete CICS Transaction MessageENT:1:MVS File Status RequestProcess Pending State Transition

Enable these jobs only if you are monitoring CICS resources with the Tivoli Business Manager CICSPlex/SM Tower interface or CICS files with IBM Tivoli Business Systems Manager interface to OMEGAMON II for CICS


DB2 Discovery LoadDB2 Discovery ProcessCleanup DB2 discovery-related tablesDelete Unused DB2 Data Sharing Groups

Enable these jobs only if you are monitoring DB2 resources with the Tivoli Business Manager DB2 interface

IMS Discovery LoadIMS Discovery ProcessCleanup IMS discovery-related tables

Enable these jobs only if you are monitoring IMS resources with the Tivoli Business Manager IMS Tower interface

CA7 Discovery Load CA7 Discovery ProcessCA7 Cleanup Audit Events

Enable these jobs only if you are monitoring batch schedules from Computer Associates CA-7 Scheduler

Zeke Discovery Load Zeke Discovery ProcessMust End Batch Operations

Enable these jobs only if you are monitoring ASG-Zeke

Automation Discovery Load Automation Discovery Process

Enable these jobs only if you are using SA/390 to perform automation discovery

RODM Discovery LoadRODM Discovery ProcessRODM Network Auto-register

Enable these jobs only if you are monitoring SNA Resources on the z/OS with RODM and the Tivoli Business System Manager to RODM interface

SMS Disk Device Discovery LoadSMS Disk Device Discovery ProcessSMS Disk Volume and Storage Group Discovery LoadSMS Disk Volume and Storage Group Discovery processSMS Catalog Entry Discovery LoadSMS Catalog Entry Discovery ProcessSMS Data Set Discovery LoadSMS Data Set Discovery Process

Enable these jobs only if you are monitoring Systems Managed Storage (SMS)

Cleanup RejectedOPCEventCompleted Schedule PollOPC Check for new daily planDelete old auto-discovered batch jobs

Enable these jobs only if you are monitoring batch schedules from Tivoli Workload Scheduler

XRC Session Names Discovery LoadXRC Session Names Discovery ProcessXRC Session Pairs Discovery LoadXRC Session Pairs Discovery Process

Enable these jobs only if you are monitoring XRC subsystem

Cleanup Control-M Enable these jobs only if you are monitoring batch schedules from CONTROL-M for z/OS scheduler


Chapter 14. Maintenance and tuning issues 439

14.1.2 Distributed resources jobsThe distributed resources jobs shown in Table 14-2 must be enabled only if IBM Tivoli Business Systems Manager is receiving events from distributed data sources through the Agent Listener or the Common Listener services.

Table 14-2 Distributed Resources Jobs

14.1.3 Database maintenance jobsThe database maintenance jobs aim to keep the IBM Tivoli Business Systems Manager database uncluttered by cleaning out-of-date data from the database tables. All of these jobs must be enabled and customized depending on the specific environment, the daily volume of the events, and the hardware on which IBM Tivoli Business Systems Manager runs.Table 14-3 lists the Database Maintenance Jobs, grouped by the action they perform, and our setting suggestions.

Table 14-3 Database Maintenance Jobs suggested settings

ENT:1Weekly MVS Register ObjectsCleanup Discovery Batches

Always enable these jobs if you monitor z/OS component with Source/390


Distributed resources jobs Suggested settings

GEMCleanupTraceTablesGEMOverdueHeratbeatJob

Enable these jobs only if you are monitoring distributed resources through the Tivoli Enterprise Console

CL_ProcessRuleJobCLCleanupJobCLScheduled_SPCallsJob

Enable these jobs only if you are using the Common Listener service

Database maintenance jobs Suggested settings

Delete Old Child EventsDelete Old Closed Notes Delete Old ExceptionsDelete Old MessagesDelete Old ObjectEvent RecordsCleanup UnandledEvent Table

These jobs clean up database tables containing data considered out-of-date and always should be enabled.The jobs are customized to remove events, notes, exceptions, and messages older than 7 to14 days. These default values should be customized to reflect your need of a long-term or short-term event history.


The following database maintenance jobs need some customization in order to work properly:

� Cleanup Old Log Files � Delete Old MVS Upload Output Files � Cleanup Old DB Queue Entries

Cleanup Old Log FilesThe Cleanup Old Log Files job deletes log files with extension *.log, *.txt, or *.msg created by IBM Tivoli Business Systems Manager in the server’s TivoliManager\Logs folder. The job is not enabled by default, and it must be customized to match the IBM Tivoli Business Systems Manager environment. To customize the job, open the job properties from the SQL Enterprise Manager and edit the job step. The default values are shown in Figure 14-1.

Figure 14-1 Cleanup Old Log Files job window

Cleanup Event Viewer TablesCleanup Menuitem CacheCleanup GenerateChildEvent Tables

These jobs remove any old entries from the tables dealing with Event Viewer, objects Menus, and propagation processing. We recommend keeping them always enabled.

Database maintenance jobs Suggested settings


The default entry in the Command window is:

asisp_logcleanup <Database_Server>,<History_Server>, <Application_Server>, <Propagation_Server>, <Event_Handler>, <SNA_Server>, <Days_To_Retain>

The asisp_logcleanup procedure accepts seven parameters. Each parameter has to be filled with the correct value in its respective position order. The possible values and their order are:

<Database_Server> The name of the machine hosting the Database Server

<History_Server> The name of the machine hosting the Historical Server

<Application_Server> The name of the machine hosting the Console Server

<Propagation_Server> The name of the machine hosting the Propagation Server

<Event_Handler> The name of the machine hosting the Event Handler Server

<SNA_Server> The name of the machine hosting the SNA server

Days_to_retain The log files’ maximum age limit as needed.

The procedure deletes log files older than the age specified in the last command only for the machines stated in the command. For example, to delete the log files older than seven days in our distributed implementation, the command window entry shown in Figure 14-1 on page 441 must be changed to

asisp_logcleanup ibmtiv5, ibmtiv6, ibmtiv3, ibmtiv3, ’’, ’’,7

Once enabled the job can be scheduled to run every week. This schedule time should be be changed according to the log file’s age limit as specified in the command.

Delete Old MVS Upload Output Files The Delete Old MVS Upload Output Files job deletes the files IBM Tivoli Business Systems Manager writes in the <TBSM_install_dir>\Logs Database Server directory. Files with an MVS*JCL* pattern are stored every time the system processes data to be sent to the z/OS host systems as objects registration or action traps. The job is not enabled by default but we suggest enabling it if IBM Tivoli Business Systems Manager is monitoring the z/OS environment. The job also has to be customized to work properly. Figure 14-2 on page 443 shows the Edit Job Step window of this job using the default values.


Figure 14-2 Delete Old MVS Upload Output Files window

The default entry in the command window is:

AsicleanDir.exe -D c:/ASIAccess1/Logs -f “MVS*JCL*” -H12 -q

The AsiCleanDir is invoked to delete without prompting all the files with a file name matching the pattern MVS*JCL* that are older than 12 hours. The -D parameter states the directory to clean. The AsiCleanDir command syntax is:

AsiCleanDir.exe [-q] [-D<directory>] [-n<days>] [-H<hours>] [-f<filespec>]

where:

-q <Q>uiet mode, no confirmation-D<directory> directory to clean (default=current working directory)-n<days> number of days to retain (default=0)-H<hours> number of hours to retain (default=0)-f<filespec> pattern for files, such as "*.dat" to be searched (default="*")

The entry in the Edit Job Step window of the job must be customized with the correct directory path

AsicleanDir.exe -D c:/TivoliManager/Logs -f “MVS*JCL*” -H12 -q

where c:/TivoliManager/ is the typical <TBSM_Install_Dir>. Once enabled the job is scheduled by default to run hourly all day.


Cleanup Old DB Queue EntriesThe Cleanup Old DB Queue Entries job deletes rows from several database queues tables. The size of these tables can grow rapidly if the job is not enabled. The number and the age of the rows to delete are set in the stored procedure asisp_clean_old_queue_entries. Default values are 10,000 entries older than one day. The queue tables that are cleaned up are shown in Table 14-4.

Table 14-4 Queues tables cleaned up by the Cleanup Old DB Queue job

To customize the job with values different from the defaults, you must update the job step using the SQL Enterprise Manager as shown in Figure 14-3 on page 445.

ProcessedAutoTicketEvent ProcessedAutoTicketFilteredEvent

ProcessedBatchRule

ProcessedEvent ProcessedHeartBeatMsg ProcessedMVSUploadRule

ProcessedNotification ProcessedNotification8 ProcessedNotificationJ

ProcessedPerfMonMsg ProcessedRuleCommand ProcessedScmMsg

ProcessedStagedEvent ProcessedTECExportEvent PendingAutoTicketEvent

PendingAutoTicketFilteredEvent PendingBatchRule PendingEvent

PendingHeartBeatMsg PendingMVSUploadRule PendingNotification

PendingNotification8 PendingNotificationJ PendingPerfMonMsg

PendingRuleCommand PendingScmMsg PendingStagedEvent

PendingTECExportEvent


Figure 14-3 Cleanup Old DB Queues window

For example, if you want the job to delete from the tables 20,000 rows that are older than one day, the entry in the command window should be changed to read

asisp_clean_old_queue_entries @max_days=1, @max_select=20000

If enabled, the job is scheduled by default to run once a day.

14.2 Database maintenanceFor the IBM Tivoli Business Systems Manager database to perform well and to enable recovery, some database maintenance must be performed. This should be done as an addition to the IBM Tivoli Business Systems Manager data maintenance tasks described in 14.1.3, “Database maintenance jobs” on page 440.

14.2.1 Database statistic and checkIBM Tivoli Business Systems Manager provides several SQL jobs that can perform important maintenance tasks such as database optimizations and database integrity check. These jobs are:

DBCC CHECKDB(Object) Performs the CHECKDB command against the IBM Tivoli Business Systems Manager Object


database, checking its object allocation and structural integrity.

Update ObjectEvents stats Launches the stored procedure sp_updateallstats against the IBM Tivoli Business Systems Manager ObjectEvents database, updating all user-defined tables within it.

Update Object Stats Launches three stored procedures (sp_updateallprocs, sp_updateallviews, and sp_updateallstats) against the IBM Tivoli Business Systems Manager Object database, updating all the table schemas, indexes, views, triggers, and stored procedures.

These jobs can be enabled and scheduled to run during off-peak usage time to avoid performance degradation on the database. The Command field in the Edit Job Step window of the Update ObjectEvents stats job has to be modified as shown in Figure 14-4.

Figure 14-4 Update ObjectEvents stats job wIndow


Also, the Command field in the Edit Job Step window of the Update ObjectEvents stats job has to be modified as shown in Figure 14-5.

Figure 14-5 Update Object Stats job wIndow


14.2.2 Database Maintenance PlanThe creation of a Database Maintenance Plan is a good way to perform maintenance functions against all the IBM Tivoli Business Systems Manager databases. To create a new Database Maintenance Plan:

1. From the SQL Server Enterprise Manager, expand the Management folderand right-click on the Database Maintenance Plan object. Choose New Maintenance Plan as shown in Figure 14-6.

Figure 14-6 Database Maintenance Plan creation


2. When the Database Maintenance Planner Wizard starts and the Welcome screen appears as shown in Figure 14-7, click Next.

Figure 14-7 Database Maintenance Plan Wizard: Welcome


3. Select the databases for which the plan will be activated. You also can create multiple plans specifying different groups of databases according to your maintenance model requirement. The database selection dialog is shown in Figure 14-8. Click Next to continue.

Figure 14-8 Database Maintenance Plan Wizard: Select Databases


4. Specify the data reorganization and statistic update information as shown in Figure 14-9. We use the settings from the IBM Tivoli Business Systems Manager: Administrator’s Guide, GC32-0799 directions. Click Next to continue.

Figure 14-9 Database Maintenance Plan Wizard: Data Optimization settings


5. Customize the Database Integrity Check panel as shown in Figure 14-10. Schedule the plan to run once a week in a database’s off-peak usage time. Click Next to continue.

Figure 14-10 Database Maintenance Plan Wizard: Database Integrity Check


6. Customize the Specify the Database Backup Plan dialog as shown in Figure 14-11. You can choose either Disk or Tape, and specify the backup frequency. Click Next to continue.

Figure 14-11 Database Maintenance Plan Wizard: Backup settings


7. Our backup destination is Disk as shown in Figure 14-12. Click Next to continue.

Figure 14-12 Database Maintenance Plan Wizard: Backup Disk Directory settings


8. Disable the transaction log backup on the Transaction Log Backup dialog as shown in Figure 14-13. Click on Next to continue.

Figure 14-13 Database Maintenance Plan Wizard: Transaction Log Backup settings


9. In the Reports to Generate dialog, specify the path for generating maintenance reports, as shown in Figure 14-14. Click Next to continue.

Figure 14-14 Database Maintenance Plan Wizard: Reports to Generate


10.The number of rows to store in the maintenance plan is specified in Figure 14-15. Click Next to conitnue.

Figure 14-15 Database Maintenance Plan Wizard: Maintenance Plan History


11.Figure 14-16 shows the summary window for the plan. Provide the name for your plan and click Finish to save and activate the plan.

Figure 14-16 Database Maintenance Plan Wizard summary

14.3 Microsoft SQL Server and Windows 2000 tuningThis section provides some customization tips to boost SQL server performance and tune Windows 2000 to work optimally with IBM Tivoli Business Systems Manager. The discussion covers:

� 14.3.1, “Windows 2000 Advanced Server tuning” on page 458

� 14.3.2, “Microsoft SQL Server 2000 tuning” on page 462

14.3.1 Windows 2000 Advanced Server tuning Windows 2000 offers tuning tips that can maximize Microsoft SQL Server performance. Because SQL server runs as a service on the operating system, setting our IBM Tivoli Business Systems Manager servers to give background services higher priority helps SQL servers perform better. To change this setting, run the System applet from Start -> Settings -> Control Panel, select the Advanced tab, and click Performance Options as shown in Figure 14-17 on page 459.


Figure 14-17 Windows 2000 System Properties

Check the Background services option in the Performance Options window as shown in Figure 14-18.

Figure 14-18 Windows2000 Performance Options


Another tuning customization available in Windows 2000 maximizes the data throughput for network applications. Right-click the My Network Places icon and select Properties. Open the Properties page of the active Local Area Network device, as shown in Figure 14-19.

Figure 14-19 Windows 2000 Local Area Connection Properties


In the Sharing tab, choose the option Maximize data throughput for network applications, as shown in Figure 14-20.

Figure 14-20 Windows 2000 File and Printers Sharing Properties


14.3.2 Microsoft SQL Server 2000 tuningMicrosoft SQL Server can be configured for optimal memory utilization. We found that the best configuration is for allowing Windows 2000 to use dynamic memory allocation, setting the /3GB switch in the boot.ini file. In this way the SQL server can use up to 3GB of memory. To reserve physical memory for your SQL server and allow dynamic memory allocation, open the SQL Server Properties dialog from the SQL Server Enterprise Manager and choose the Memory tab as shown in Figure 14-21.

Figure 14-21 SQL Server Properties Memory window


Another way to increase SQL server performance is to use multiple processors. Choose the Processor tab as shown in Figure 14-22 and check the boxes for Boost SQL Server Priority on Windows NT and Use all Available Processors. Do not check Use Windows NT fibers.

Figure 14-22 SQL Server Properties Processor window


Chapter 15. Automatic problem ticketing

In this chapter, we discuss the automatic problem ticketing feature of IBM Tivoli Business Systems Manager and its implementation using Tivoli Information Management for z/OS. CurrentlyTivoli Information Management for z/OS provides the automatic problem ticketing feature for IBM Tivoli Business Systems Manager. The discussion here covers:

� 15.1, “Automatic problem ticketing” on page 466 discusses the concept of automatic problem ticketing

� 15.2, “Defining the auto ticketing rule” on page 467 shows some examples that define the auto ticketing rule

� 15.3, “Tivoli Information Management for z/OS integration overview” on page 469 demonstrates a sample implementation with Tivoli Information Management for z/OS

� 15.4, “Installation and configuration” on page 471 describes the installation and configuration of the Tivoli Information Management for z/OS integration

� 15.5, “Using the problem ticket interface” on page 499 shows some sample usage of our Tivoli Information Management for z/OS implementation

15


15.1 Automatic problem ticketingIBM Tivoli Business Systems Manager, as the central manager that coordinates and displays business system status, needs an interface to a problem management facility for problem tickets (also called trouble tickets). IBM Tivoli Business Systems Manager implements this facility several ways:

� Access to problem record creation, query, update, and closure from the IBM Tivoli Business Systems Manager console

� Access to change record creation, query, update, and closure from IBM Tivoli Business Systems Manager console

� Automatic creation and updating of problem tickets based on incoming events

� Closure of records from the problem system, applied back to IBM Tivoli Business Systems Manager object status

These facilities are implemented by a set of defined user exits by IBM Tivoli Business Systems Manager. The process is described in Figure 15-1.

Figure 15-1 Problem and change management interface

The sequence is:

1. An event or message arrives, and IBM Tivoli Business Systems Manager processes it through the auto ticketing filter. When it qualifies through the filter, it invokes the user exit processing routine.

SystemConfiguration

table

TBSM User Exitprocessing routing

{XXXXXX}.in file{XXXXXX}.out file

Auto Ticketingfilter

Event or message

User Action fromConsole GUI

1

2

Problem orChange Exit

4

5

6

7

3


2. The user exit processing routine queries the SystemConfiguration table for information about the exit routines and other settings. It can be invoked from a qualifying event or from an operator action through the IBM Tivoli Business Systems Manager console.

3. The user exit processing routine creates an input request file, which is a text file that the problem or change processor should understand. The file resides in the TivoliManager\Data directory.

4. Based on the exit information in the SystemConfiguration table, the appropriate exit is invoked. Exits can be invoked directly (as an executable .exe file) or interpreted (such as Shell scripts or REXX programs).

5. The user exit processor reads the input file and accesses the problem or change subsystem.

6. The user exit processor formats the output from the problem or change subsystem and creates the output file structure in the TivoliManager\Data directory.

7. The output file is read by the user exit processing routine for return to IBM Tivoli Business Systems Manager or the operator.

The following section discusses a sample implementation of this integration using Tivoli Information Management for z/OS.

15.2 Defining the auto ticketing ruleThis section discusses the automatic problem ticketing overview. The auto ticketing definition is located in the AT_Rule table whose content is maintained using the script ATRuleUtility.ksh. The syntax of this command is:

ATRuleUtility –U<username> -S<server> -P<password> -A<action> -F<file>

The parameters are:

-S<server> Database server name.

-U<user> User name for the database login.

-P<password> Password for the database login.

-A<action> Action to perform, which can be:

add Uses contents of <input file> to add new rules.

drop Uses contents of <input file> to drop rules.

dump Prints out current rule set.

-F<input file> Specifies an input file containing new entries.

-O<output file> Specifies an output file to create for dump action.

Chapter 15. Automatic problem ticketing 467

-T<dump type> Specifies what data to dump by dump action, which can be A(Alert States) or R(Auto Ticketing Rules) or P(Priorities), or S(States).

We created a sample rule definition to generate a problem ticket for each alert in the DB2 Instance Manager object. The rule definition is provided in Example 15-1.

Example 15-1 Rule definition

RULE_BEGIN name=Rule DB2 Instance description=This rule will create a problem ticket for DB2 SubSystem obj_path_pattern=G02K obj_name_pattern= event_cid_pattern=EXCP event_name_pattern= event_detail_pattern= event_state= event_alertstate=3 event_priority= note_type=O note_expiration=14 note_owner=Budi Darmawan note_subject=DB2 Instance problem note_body=This note was created by the Auto Ticketing feature.RULE_END

Additionally you can drop a rule in the AT_Rule table using the RULE_DROP control statement, specifying the name and rule_id.

Example 15-2 shows the creation of the rule in Example 15-1 into the AT_Rule table.

Example 15-2 Running ATRuleUtility.ksh

C:\AT>sh ATRuleUtility.ksh -S ibmtiv5 -U sa -P XXXX -A add -T R -F ATRule.txt

AT_AddRule: @cid = ENT @id = 1 @name = Rule 1 @description = This rule will create a problem ticket. @obj_path_pattern = G02K @obj_name_pattern = @event_cid_patttern = EXCP@event_name_pattern = @event_detail_pattern = @event_state = 0 @event_alertstate = 3 @event_priority = 0 @note_type = O @note_owner = Budi Darmawan...(0 rows affected)(1 row affected)AT_AddRule: Rule was added to AT_Rule Table


15.3 Tivoli Information Management for z/OS integration overview

Information about the integration between IBM Tivoli Business Systems Manager and Tivoli Information Management for z/OS is provided at:


From this page’s Product Specific Support Page pull-down menu, select IBM Tivoli Business Systems Manager and, if necessary, click Go. From the Self Help group, select Solutions. In the search result select the article called “Program User Exits Guide and Code Samples.” This site requires a registration user ID and password.

The process described here requires the following software versions:

� Tivoli NetView for OS/390 Version 1.3 or later

� Tivoli Service Desk for OS/390 version 1.2 or Tivoli Information Management for z/OS Version 7.1

It also need the resolution of APAR OW55908/OW55907 (PTF UW95111/UW95112) to be applied.

Tivoli Information Management for z/OS functions enable creation, update, and queries for problem tickets. An open ticket icon is displayed on an object when a problem ticket has been created for an event. These Tivoli Information Management for z/OS functions also allow for closure of a problem ticket. When this occurs, the open ticket icon is removed and the IBM Tivoli Business Systems Manager database is updated to reflect the closure. However, it is understood that a problem ticket can and will be closed from within the Tivoli Information Management for z/OS application.

Figure 15-2 on page 470 illustrates the data flow that occurs from the operation in the IBM Tivoli Business Systems Manager console as you open, close, query, or update a problem ticket that is maintained by Tivoli Information Management for z/OS.

Important: The sample integration shown here is not intended for production use, but can be used as a basis for configuring your own problem systems with IBM Tivoli Business Systems Manager.




Figure 15-2 Data flow: TBSM operation

This is the process:

1. When a Tivoli Information Management for z/OS user exit processor is invoked by IBM Tivoli Business Systems Manager, it reads the necessary input request block from the *.in file and constructs a command to be sent. The command is stored in a *.txt file. It invokes tgmtask.exe to send commands through the task server to NetView.

2. The task server, connected by a NETCONV session to Tivoli NetView, launches the command on the authority of a NetView operator.

3. The problem or change exit command uses the Tivoli Information Management for z/OS’s API to access Tivoli Information Management for z/OS from NetView. It then constructs a reply that is read back by the exit processing system.

4. The API call accesses Tivoli Information Management for z/OS and passes back through the same mechanism to the workstation.

5. Upon closure of a problem ticket with an IBM Tivoli Business Systems Manager s-word S15A0 defined, Tivoli Information Management for z/OS invokes a BLGTBSMU user exit to send a message to the MVS Console.

6. The message is sent by the Source/390 processes to indicate that the problem record is closed from Tivoli Information Management for z/OS. This will close the Note record in IBM Tivoli Business Systems Manager.

7. The message is forwarded into the MVS Listener and to the TSD Event Handler process, which updates the Note object to indicate that it is closed.

z\OS system

Tivoli InfoManTivoli NetView

for z\OS

MVS Console Source/390 system

API

TBSM Servers

Tivoli BSM TaskServer

NETCONV

TSD390RPin.rexTSD390RPout.rex

tgmtask.exe

MVS ListenerSNA

orIP

TSD Event Handler TBSMDatabase

user exit


15.4 Installation and configurationIn this section, we discuss the installation and configuration process to enable the sample exit to Tivoli Information Management for z/OS. The required component is supplied in the Web document discussed in 15.3, “Tivoli Information Management for z/OS integration overview” on page 469. The installable component resides in a file called InfoMan-TSD390.zip.

The installation and configuration overview steps are:

1. Update the SystemConfiguration table in the IBM Tivoli Business Systems Manager database to enable the automatic problem management system.

2. Activate the TSD390 process.

3. Extract the input and output processor for Tivoli Information Management for z/OS from the InfoMan-TSD390.zip file to the TivoliManager\bin directory and customize them.

4. Prepare the Tivoli BSM Task Server and the tgmtask utility to communicate with IBM Tivoli NetView for z/OS, and prepare IBM Tivoli NetView for z/OS to enable communication with the Tivoli BSM Task Server and enable the program exits.

5. Prepare Tivoli Information Management for z/OS for updates in panels and programs to accomodate the integration features.

More detail on each of these actions is provided in the following sections.

15.4.1 Enable problem managementTo enable problem management, you can use and customize the sample template file in TivoliManager\sql directory called Problemintegrationdefaults.sql. A set of parameters related to problem management is listed in Table 15-1.

Table 15-1 Problem management parameter

Group Property name Usage and defaultREQUEST_PROBLEM

REQUEST_PROCESSOR_NAME Program name for problem request

REQUEST_PROCESSOR_LANGUAGE Program processor (for non EXE programs)

REQUEST_CHANGE

REQUEST_PROCESSOR_NAME Program name for change request


REQUEST_AUTOTICKET

REQUEST_PROCESSOR_NAME Program name for Autoticketing



The values we customized in problemintegrationdefaults.sql for our lab were:

REQUEST_PROCESSOR_NAME TSD390RPin.rex for problem, change, and autoticket

REQUEST_PROCESSOR_LANGUAGE REXX.exefor problem, change, and autoticket

AUTO_CLOSE_DEFAULT YES

DEBUG_MODE ON while testing, to see the interim files

TICKET_CREATE_DEFAULT YES

TIMEOUT_VALUE 120 depending on the communication latency with NetView

CLOSED_TICKET_STATUS_CODE CLOSED

ORIGIN_* AUTO_CREATE

PROBLEM_SYSTEM_NETVIEW_USED YES

API_INTEGRATION_OPTIONS

AUTO_CLOSE_DEFAULT Closes the problem ticket when the associated note is closed. Default is NO.

DEBUG_MODE Deletes the input and output control files. Default is OFF.

DISPLAY_PROBLEM_CLOSURE Activates the problem closure data and text field. Default is NO.

TICKET_CREATE_DEFAULT Displays problem ticket creation dialog after creating an ownership. Default is NO.

TIMEOUT_VALUE Timeout duration for user exit processing. Default is 45 (seconds).

CLOSED_TICKET_STATUS_CODE Status code of a closed problem ticket. Default is CLOSED.

ORIGIN_SYSTEM Origin, hierarchy for Problem invocation. Also known as SCIM (system, component, item, module), it can be LOOK_UP (to TSD_SCIM table) or AUTO_CREATE with the following hierarchy: <TBSM> - CID - object ID- object name

ORIGIN_COMPONENT

ORIGIN_ITEM

ORIGIN_MODULE

PROBLEM_SYSTEM_NETVIEW_USED Displays NetView userID prompt. Default is NO.CHANGE_SYSTEM_NETVIEW_USED

AUTO_SELECT_TICKET Provide preselected value for open problem status. Default is blank, which means no pre-selected status.

APPEND_TEXTLOG_TIMESTAMPS Puts the timestamp on the text log. Default is YES.

Group Property name Usage and default


The content of the sql command file based on those values is shown in Example 15-3.

Example 15-3 Initialize SystemConfiguration table

Insert Into SystemConfiguration Values ("REQUEST_PROBLEM","REQUEST_PROCESSOR_NAME","TSD390RPin.REX","CHAR")Insert Into SystemConfiguration Values ("REQUEST_CHANGE","REQUEST_PROCESSOR_NAME","TSD390RPin.REX","CHAR")Insert Into SystemConfiguration Values ("REQUEST_AUTOTICKET","REQUEST_PROCESSOR_NAME","TSD390RPin.REX","CHAR")Insert Into SystemConfiguration Values ("REQUEST_PROBLEM","REQUEST_PROCESSOR_LANGUAGE","REXX.EXE","CHAR") Insert Into SystemConfiguration Values ("REQUEST_CHANGE","REQUEST_PROCESSOR_LANGUAGE","REXX.EXE","CHAR") Insert Into SystemConfiguration Values ("REQUEST_AUTOTICKET","REQUEST_PROCESSOR_LANGUAGE","REXX.EXE","CHAR") Insert Into SystemConfiguration Values ("API_INTEGRATION_OPTIONS","DEBUG_MODE","ON","CHAR") Insert Into SystemConfiguration Values("API_INTEGRATION_OPTIONS","AUTO_CLOSE_DEFAULT","YES","CHAR")Insert Into SystemConfiguration Values("API_INTEGRATION_OPTIONS","TICKET_CREATE_DEFAULT","YES","CHAR")Insert Into SystemConfiguration Values("API_INTEGRATION_OPTIONS","ORIGIN_SYSTEM","AUTO_CREATE","CHAR")Insert Into SystemConfiguration Values("API_INTEGRATION_OPTIONS","ORIGIN_COMPONENT","AUTO_CREATE","CHAR")Insert Into SystemConfiguration Values("API_INTEGRATION_OPTIONS","ORIGIN_ITEM","AUTO_CREATE","CHAR")Insert Into SystemConfiguration Values("API_INTEGRATION_OPTIONS","ORIGIN_MODULE","AUTO_CREATE","CHAR")Insert Into SystemConfiguration Values('API_INTEGRATION_OPTIONS','TIMEOUT_VALUE',120,'INTEGER') Insert Into SystemConfiguration Values ("API_INTEGRATION_OPTIONS","PROBLEM_SYSTEM_NETVIEW_USED","YES","CHAR")

Update MetaMenuItemVersion set verno = verno + 1 Select * from SystemConfiguration order by groupname, propertyname

Be sure that the TBSM Tivoli Software Distribution Event Handler service on the database server is activated and started. This has to be started before Source/390’s Object Registration process. Otherwise you must manually register the object: Right-click the OS object and select Source/390 -> Register Objects.


15.4.2 Extract and customize the input-output processorFor IBM Tivoli Business Systems Manager, the input processor is called TSD390RPV21in.rex and the output processor is called TSD390RPout.rex. We extract these files to the TivoliManager\data folder and rename the TSD390RPV21in.rex to TSD390RPin.rex.

TSD390RPin.rexFrom the TSD390RPin.rex:

� Customize the TGMTASK parameters as shown in Example 15-4.

Example 15-4 TGMTask parameters

/* configure tgmtask parameters */

tgmtaskip = 'ibmtiv5.itsc.austin.ibm.com' nvapplid = 'SC69N'

� Configure the OS/390 command processors. The parameter that we have is shown in Example 15-5.

Example 15-5 Command processor name

/* configure OS390 Request Processor Names */problemrp= 'GTMSDRP'changerp= 'GTMCGRP'autoticketrp= 'GTMATRP'

� (Optional) Modify the enumeration values for TSD390. We do not perform any changes to the enumeration in our project.

TSD390TPout.rexWe are using Microsoft Windows NT Resource Kit with Regina REXX for Win32, so no modification is necessary. For Windows 2000 Resource Kit, you have to use IBM Object REXX, so you must add a change to the logic, as shown highlighted in Example 15-6.

Example 15-6 Modification for Windows 2000 Resource kit

Do While Lines() > 0 /* get all input lines */ Line = Linein() /* Special code * pidy = pos(" ", line, 1) if (pidy>0) then do pidx = pos('>', line, 1) line = substr(line, 1, pidy-1) || substr(line, pidy+1, pidx-pidy) end


* Special code end */ If substr(line,2,20) = 'REQUEST_RETURN_CODE=' then

15.4.3 Setting up the task server and Tivoli NetView for z/OSThe Tivoli NetView for z/OS command facility is used to receive a command and message from IBM Tivoli Business Systems Manager. It invokes the appropriate TSD390 REXX API programs that process the message with the TSD390 database and returns the results to IBM Tivoli Business Systems Manager.

We verified that we can invoke the tgmtask utility as shown in Example 15-7, using the DISPPI command.

Example 15-7 Executing DISPPI command

C:\>tgmtask -d 390 -h 3c041 -n sc69n -u vbudi -k ******* -v DISPPITGMTaskClient::TGMTaskClient hostTPConnection::open host=TGMTaskClient::runCommand commandString=TPConnection::send sent 148 bytesTPConnection::recv received 4 bytesTPConnection::recv received 1120 bytesTGMTaskClient::handleReplyDISPPIDWO948I RECEIVER RECEIVER BUFFER QUEUED TOTAL STORAGE RCVRDWO949I IDENTITY STATUS LIMIT BUFFERS BUFFERS ALLOCATED ASIDDWO950I -------- -------- ---------- ---------- ---------- ---------- ----DWO951I NETVALRT ACTIVE 1000 0 3 0 005FDWO951I ISTMTRCV ACTIVE 500 0 43 0 001ADWO951I DSIMCAT ACTIVE 25 0 0 0 005FDWO951I SC69NSCO ACTIVE 1000 0 0 0 005FDWO951I SC69NHTM ACTIVE 1000 0 0 0 005FDWO951I NETVRCV ACTIVE 500 0 114 0 005FDWO951I DSIQTSK ACTIVE 100 0 0 0 005FDWO951I NETVAOP ACTIVE 1000 0 1635 0 0071DWO951I IHSATEC ACTIVE 5000 0 166 0 006DDWO968I END OF DISPLAYTGMTaskClient::~TGMTaskClientTPConnection::close closing open connectionCommand execution completed.

Now, we need to load the request processor REXX program from the InfoMan-TSD390.zip to a data set allocated in DSICLD of the NetView program. (The program to be uploaded depends on the version of the Tivoli Information Management for z/OS installed.) We load all the GTM??RP12.TXT files to the user REXX library allocated to NetView and remove all the “12” suffixes as NetView only allows eight-character names.


Allocating TBSM interface parameter data setThe request processor REXX program uses a parameter data set that must be pre-allocated. Use the GTMSDPRM member from the SGTMSAMP target library to create the parameter data set. The expected return code from the job is zero.

Example 15-8 Modified SGTMSAMP

//GTMSDPRM JOB ,VBUDI,USER=VBUDI,NOTIFY=VBUDI,// CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)//*********************************************************************//ALLOC PROC A='*', ** PRINT SYSOUT DEFAULT// DSP=CATLG, ** DATASET DISPOSITION// PRDSN=NETVUSER.SC69N.PARMLIB,// PRVOL=TIVO02, ** VOLSER FOR PARMLIB DATASET// PRUNIT=3390 ** UNIT TYPE FOR PARMLIB DATASET//*********************************************************************//PSTEP1 EXEC PGM=IEFBR14//*//* TBSM SD390 PARMLIB DATASET//*//SYSPRINT DD SYSOUT=&A//* @P2C1//PARMLIB DD DISP=(,&DSP),// SPACE=(6160,(250,50)),// DCB=(RECFM=FB,LRECL=80,BLKSIZE=0),// UNIT=&PRUNIT,VOL=SER=&PRVOL,// DSN=&PRDSN//PSTEP2 EXEC PGM=IEBGENER//SYSPRINT DD SYSOUT=&A//SYSUT2 DD DSN=&PRDSN,DISP=(OLD,CATLG,CATLG)//SYSIN DD DUMMY//ALLOC PEND//STEP1 EXEC ALLOC//PSTEP2.SYSUT1 DD *MASTUID=VBUDI <= UID WITH ADMIN OR MASTER READ AUTHORITYMASTPSWD=MASTER <= PASSWORD OR PRIVILEGE CLASS FOR MASTUID */SESS=BLGSES69 <= SESSION IDDB=5 <= UPDATE DATABASE IDUIDREC=TBSM <= RECORD ID OR TABLE NAME FOR TBSM UID'S OR 'ALL'SRCHMAX=0100 <= MAX NBR RECS TO BE RETURNED FROM QUERY REQUEST/* @P4C1

Important: You may need to tailor the request processor depending on how much customization you have performed in the Tivoli Information Management for z/OS system and how your problem management process is set up.


In our environment, we changed the following parameters:

� MASTUID: primary user ID to be used in Tivoli Information Management for z/OS

� SESS: session parameter that will be used in Tivoli Information Management for z/OS

� SRCHMAX: maximum number of search matches to be returned

� DASD: volume serial where the temporary data set will be created upon execution of the interface

We run Tivoli NetView for z/OS Version 1.5, which can take a global variable using CNMSTYLE definition:

COMMON.TBSMTSDDSN=NETVUSER.SC69N.PARMLIB

You can also issue GLOBALV command to set it.

15.4.4 Application customization

The following customization must be performed in Tivoli Information Management for z/OS:

� Creating the user record

� Enabling the immediate notification service

� Modifying BLG1A111, problem record save panel

Required actions after applying the APARAfter APAR OW55908 is applied, the following must be performed:

� Reload the IBM Read Panel data set for additional panels from IBM Tivoli Business Systems Manager. The new panel names are: BLGTBSMU, BLG6BSME, and BLG6BSMO. Be sure these are not duplicated in your environment. Use the sample BLGLRPNL member of the SBLMSAMP.

� Add the additional dictionary supplied in BLMVDICT. Be sure you have saved all additional s-words and p-words that you added to the dictionary data set beforehand. Use the sample BLGLDICT member of the SBLMSAMP.

� Ensure that the new PIDT and PIPT tables that are needed for the REXX API interface are loaded in the correct Report Format Table (RFT) data set as indicated by the Tivoli Information Management for z/OS session number.

Important: These functions must be performed after APAR OW55908/OW55907 has been applied. The APAR provides additional functionality for IBM Tivoli Business Systems Manager integration.


These are the new panels for IBM Tivoli Business Systems Manager:

BLGTBSMU The GTMTBSMU member is a Terminal Simulator Program (TSP) that formats and issues a message to the console and captured by the IBM Tivoli Business Systems Manager AOP facility. The message is similar to:+TSD390CLS - <PROBID=00000000> SET TO CLOSEDThe Problem Closed message is transferred to the IBM Tivoli Business Systems Manager TSD390 closure process.

BLG6BSME Assisted entry panel for IBM Tivoli Business Systems Manager event ID, as shown in Figure 15-3.

Figure 15-3 TBSM event ID assisted entry panel

Environment Dialog Record PMF SRC Debug Window Options Help ------------------------------------------------------------------- MORE: + ===> BLM8CU51 ASSISTED ENTRY UPDATE EXTERNALS +--------------------------------+---------------------------------+ | BLG6BSME TBSM EVENT ID TBSME/ | | | | USE...This value is generated from a TBSM ticket create request | | | | NOTE: This value is used to identify a specific event that is | | associated with a TBSM Object Class. | | | | | | Examples: 4528.............Reply........4528 | | | | | | REPLY AS ILLUSTRATED | +--------------------------------+---------------------------------+


BLG6BSMO Assisted entry panel for IBM Tivoli Business Systems Manager class ID, as shown in Figure 15-4 on page 479.

Figure 15-4 IBM Tivoli Business Systems Manager class ID assisted entry panel

The resulting additional s-word can be seen from the Panel Modification Facility (PMF). You can display the PMF menu by entering the stored response chain (SRC) ;INIT,3,2,9 command. Display the s-word using the 2,1,find 15A0 command. The result is shown in Figure 15-5 on page 480.

Environment Dialog Record PMF SRC Debug Window Options Help ------------------------------------------------------------------- MORE: + ===> BLM8CU51 ASSISTED ENTRY UPDATE EXTERNALS +--------------------------------+---------------------------------+ | BLG6BSMO TBSM OBJECT CLASS NAME TBSMO/ | | | | USE.....This value is generated from TBSM create ticket request | | | | NOTE: This value is used to identify a record created from TBSM | | that is associated with a specific TBSM Object. | | | | | | Examples: cics.............Reply........CICS | | | | | | REPLY AS ILLUSTRATED | +--------------------------------+---------------------------------+


Figure 15-5 Tivoli Information Management for z/OS s-word display

Similarly, the p-word related to TBSM can be shown from the PMF using the SRC 2,3,FIND TBSM. Figure 15-6 shows the result.

Figure 15-6 Tivoli Information Management for z/OS p-word display

At this point, you should back up your VSAM dictionary using the BLGUT5F utility and back up your panel data set using BLGUT6F utility. For more information about using BLGUT5F and BLGUT6F, refer to Tivoli Information Management for z/OS Program Administration Guide and Reference, SC31-8753.

Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +- ===> BLG23502I The specified target string was found. BLM1TDS1 DICTIONARY DISPLAY STRUCTURED WORDS WORD STRUCTURED WORD PGM GENERAL INDEX WORD ACRONYM USED COMMENT 159F RESERVED NO RESERVED. 15A0 XTBSMS15A0 TBSM=TBSM_NOTI YES TBSM Integration 15A1 XTBSMS15A1 TBSM=TBSM_OBJE YES TBSM Integration 15A2 XTBSMS15A2 TBSM=TBSM_EVEN YES TBSM Integration 15A3 RESERVED NO RESERVED. 15A4 RESERVED NO RESERVED.

Type DOWN UP LEFT or RIGHT to scroll the panel or type END to exit.

Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +- ===> BLG23502I The specified target string was found. BLM1TDP1 DICTIONARY DISPLAY PREFIX WORDS P-WORD PREFIX P-WORD PGM GENERAL INDEX VALIDATION USED COMMENT 06C3 NO RESERVED 06C4 TBSMO/ CCV9 YES TBSM Integration 06C5 TBSME/ CCV63 YES TBSM Integration 06C6 NO RESERVED 06C7 NO RESERVED


Creating a user recordThe USERS TO NOTIFY record specifies a profile of which users should receive a notification message when the immediate notification facility is invoked. To create this record from Tivoli Information Management for z/OS, run the SRC ;INIT,3,1,5,2,1.

Enter the assignee names and user IDs or privilege classes of all individuals or groups who should receive immediate notification messages, as shown in Figure 15-7.

Figure 15-7 Users to notify

Save the record by pressing PF3. The operation is completed when this message appears BLG03058I Record USERS was stored successfully.

Immediate notification facilityThe Tivoli Information Management for z/OS immediate notification facility must be enabled. It enables a TSO user to receive notification of changes in a record. For more information about this customization, refer to Enabling Immediate Notification in the Tivoli Information Management for z/OS Program Administration Guide and Reference, SC31-8753.

If this facility is not enabled, follow these steps:

1. From PMF, open the BLGTSPPU panel. Run the SRC 1,1,BLGTSPPU,,4 to open the TSP’s summary screen as shown in Figure 15-8 on page 482.

Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: + ===> BLG0B901 USERS TO NOTIFY 1 OF 3 Enter assignee and ID/class data; cursor placement or input line entry allowed. Assignee Name ID/Class Assignee Name ID/Class 1. ITSOAustin_____ 2. TIVO04__ 31. _______________ 32. ________ 3. _______________ 4. ________ 33. _______________ 34. ________ 5. _______________ 6. ________ 35. _______________ 36. ________ 7. _______________ 8. ________ 37. _______________ 38. ________ 9. _______________ 10. ________ 39. _______________ 40. ________ 11. _______________ 12. ________ 41. _______________ 42. ________ 13. _______________ 14. ________ 43. _______________ 44. ________


Figure 15-8 Deleting of the BRANCH control line

2. Delete the BRANCH statement from the TSP, by issuing the D command in the prefix area as shown in Figure 15-8.

3. Find the line that contains the DEFAULT user ID. Change the default user ID in BLGTSPPU as shown in Figure 15-9 on page 483.

Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +- ===> BLM1TSU9 CONTROL LINE SUMMARY LINE 1 OF 115 CONTROL FUNCTION LABEL LITERAL GET APPLY LINE NAME NAME DATA VAR NOT '' COMMON '' LABEL BLGTSPPU NOTIFY THE APPROPRIATE PERSON '' USEREXIT BLGTSAPI TEST FOR API ENVIRONMENT NO NO '' TESTFIELD LEAVETSP 0 NO NO d' BRANCH MESSAGE '' USEREXIT EXIT IF ESCALATION CAUSED FILE. NO NO '' TESTFIELD ALLISOK 0 NO NO '' LABEL LEAVETSP LEAVE TSP AND RETURN TO CALLER '' RETURN '' LABEL ALLISOK RECORD WAS REALLY UPDATED. Line Cmds: D=Delete U=Update Type DOWN, UP, LEFT, or RIGHT to scroll the panel, or type END to exit.


You must change DEFAULT to the MVS user ID of the program administrator who is responsible for notification management, as discussed in “Creating a user record” on page 481. Use the U line command and then change the data field.

Figure 15-9 Change DEFAULT to MVS user ID

4. Save the panel by entering the SRC END,END,END. The modified BLGTSPPU panel is now in the write panel data set. If this data set is not concatenated in your read panel data set, use PMF to copy this panel to the read panel data set.

Modifying the BLG1A111 panelThe BLG1A111 control panel contains logic to be performed when saving a problem record. Modify it for IBM Tivoli Business Systems Manager by adding a specific IBM Tivoli Business Systems Manager–related s-word to a saved problem record for a non-closed record.

Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +- ===> BLM1TSU9 CONTROL LINE SUMMARY LINE 11 OF 114 CONTROL FUNCTION LABEL LITERAL GET APPLY LINE NAME NAME DATA VAR NOT '' LABEL @@@@@@@@ CHANGE 'DEFAULT' TO THE ID @@@@@ '' LABEL @@@@@@@ OF YOUR PROBLEM ADMINISTRATOR @@ '' LABEL @@@@@@ IN LINE 17. SPACE FILL IF @@@@@ '' LABEL @@@@@ NEEDED. LEAVE POSITIONS @@@@@@@ '' LABEL @@@@ 1-8 BLANK. POSITION 17 @@@@@@@@ '' LABEL @@@ MUST CONTAIN A '.' @@@@@@@@@@@@@ '' MOVEVAR TIVO04 . '' USEREXIT CALL BLGESPUV TO SAVE 'DEFAULT' YES NO '' LABEL INIT. # OF RECORDS TO CANCEL '' SETFIELD NO Line Cmds: D=Delete U=Update Type DOWN, UP, LEFT, or RIGHT to scroll the panel, or type END to exit.


The modification of BLG1A111 adds five new control lines that perform as a checking block (as indicated by the Begin multiple test and End multiple test fields in the BLM8CU64 dialog).

1. A TEST control line tests whether s-word 15A1 exists in this record. If it does, then skip the remaining tests.

2. A second TEST control line tests whether s-word 15A0 exists in this record. If it does, then skip the remaining tests.

3. A third TEST control line tests whether the status field is CLOSED, as indicated by the p-word 0272 STAC/CLOSED. If the status is CLOSED, skip the remaining tests.

4. For a record without the s-words 15A0 or 15A1 and without CLOSED status, run an ADD for s-word 15A0 to the record.

5. Invoke the BLGTBSMU TSP.

Note that in Tivoli Information Management for z/OS, modifying a control line involves updating three items:

Control flow processing Defines the processing code and its behavior.

Data collection Defines the argument for this processing.

Test data processing Defines the logical relation for the data used.


Modify the BLG1A111 panel using the following instructions, and verify that all entries match. Once all changes have been applied, you may need to copy the modified version of the BLG1A111 panel to your read panel data set:

1. From PMF, open the abstract of BLG1A111 control panel using the following SRC 1,1,BLG1A111,,1. The abstract of BLG1A111 is shown in Figure 15-10.

Figure 15-10 Control panel update

Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: + ===> control BLM8CU61 CONTROL PANEL UPDATE EXTERNALS +----------------------------------------------------------------------------+ | BLG1A111 PROBLEM RECORD FILE PROCESSING | | This control panel does the following: | | 1. Calls a TSP to send notification for new or updated records. | | 2. Adds enter date, time, and class if this is a new record. | | 3. Calls a program exit to process freeform text dates. | | 4. Adds date, time, and user last modified. | | 5. Adds escalation level of 1 if not already there. | | 6. Calls a program exit to establish record ownership. | | 7. Issues a file request if the record has been updated. | +----------------------------------------------------------------------------+ Modify textual data within the box. To modify control data, type CONTROL on the command line. When you finish, type END to save or CANCEL to discard any changes.


2. Issue the control command to go to the FUNCTION LINE SUMMARY screen for BLG1A111 as shown in Figure 15-11.

Figure 15-11 Function line summary

In the FUNCTION LINE SUMMARY panel, insert five new lines after the first line (the FLOW 002A line as highlighted). This automatically opens an individual window for each of the five new lines.

Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +- ===> BLM1TSCU FUNCTION LINE SUMMARY LINE 1 OF 17 FUNC FUNC S-WORD PREFIX MULT APPLY AUTH TRUE FALSE MESSAGE PROGRAM TYPE CODE INDEX INDEX B E NOT CODE TARGET TARGET PANEL EXIT/TSP '' **** **** **** **** * * * **** ******** ******** ******** ******** I5 FLOW 002A 0000 0561 N N N 0000 BLG1ACAN '' TEST 0000 0000 0340 Y N N 0000 '' FLOW 001B 0000 0000 N Y N 0000 BLGTSPPE '' TEST 0000 0000 0340 Y N Y 0000 '' FLOW 001B 0000 0000 N Y N 0000 BLGTSPPU '' TEST 0000 0000 0340 Y N N 0000 '' ADD 0000 0C34 00D8 N N N 0000 '' ADD 0000 0C61 028B N N N 0000 Line Cmds: A=After C=Copy D=Delete I=Insert M=Move R=Repeat U=Update Type DOWN, UP, LEFT, or RIGHT to scroll the panel, or type END to exit.


Edit each line by selecting the options 1, 2, and 3 consecutively:

a. The first line checks for the existence of s-word 15A1.

• Figure 15-12 on page 487 shows control flow processing output for this procedure.

Figure 15-12 First line option 1: Control flow processing

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU6A CONTROL FLOW PROCESSING PANEL: BLG1A111 Enter control flow information; cursor placement or input line entry allowed. 1. Control line type.....<R> TEST 2. Function code index...... 0000 Function acronym... __________________ 3. Dialog end............... NO_ 4. Override dialog target... NO_ 5. True target panel........ ________ 6. False target panel....... ________ 7. Authorization code....... 0000 8. Program exit/TSP name.... ________ 9. Message panel............ ________ When you finish type END to save or CANCEL to discard any changes.


• Figure 15-13 shows data collection processing for this procedure.

Figure 15-13 First line oOption 2: Data collection processing

• Figure 15-14 shows test data processing output for this procedure.

Figure 15-14 First line option 3: Test data processing

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU6B DATA COLLECTION PROCESSING PANEL: BLG1A111 Enter 'add word' control data; cursor placement or input line entry allowed. 1. Structured word index.... 15A1 Structured word.... XTBSMS15A1 2. Prefix index............. 0000 Word acronym....... TBSM=TBSM_OBJECT 3. Journal reply............ NO_ Prefix word........ ______ 4. Journal sequence......... ORDER Validation......... _________________ 5. Cognize response......... NO_ 6. Cognize only p-word...... NO_ 7. Replace previous reply... NO_ 8. Data is a date........... NO_ 9. Cognize in mixed case?... NO_ When you finish type END to save or CANCEL to discard any changes.

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU64 TEST DATA PROCESSING UPDATE PANEL: BLG1A111 Enter 'test word' control data; cursor placement or input line entry allowed. 1. Begin multiple test...... YES Structured word.. XTBSMS15A1 2. End multiple test........ NO_ Word acronym..... TBSM=TBSM_OBJECT 3. Structured word index.... 15A1 Prefix word...... ______ 4. Prefix word index........ 0000 Validation....... ________________ 5. Apply not logic.......... NO_ 6. Case-sensitive compare?.. NO_ When you finish type END to save or CANCEL to discard any changes.


b. The second line checks for the existence of the s-word 15A0 existence.

• Figure 15-15 on page 489 shows control flow processing output for this procedure.

Figure 15-15 Second line option 1: Control flow processing

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU6A CONTROL FLOW PROCESSING PANEL: BLG1A111 Enter control flow information; cursor placement or input line entry allowed. 1. Control line type.....<R> TEST 2. Function code index...... 0000 Function acronym... CODE - UNASSIGNED 3. Dialog end............... NO_ 4. Override dialog target... NO_ 5. True target panel........ ________ 6. False target panel....... ________ 7. Authorization code....... 0000 8. Program exit/TSP name.... ________ 9. Message panel............ ________ When you finish type END to save or CANCEL to discard any changes.


• Figure 15-16 shows data collection processing output for this procedure.

Figure 15-16 Second line option 2: Data collection processing

• Test data processing, shown in Figure 15-17, requires no changes.

Figure 15-17 Second line option 3: Test data processing

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU6B DATA COLLECTION PROCESSING PANEL: BLG1A111 Enter 'add word' control data; cursor placement or input line entry allowed. 1. Structured word index.... 15A0 Structured word.... XTBSMS15A0 2. Prefix index............. 0000 Word acronym....... TBSM=TBSM_NOTIFIED 3. Journal reply............ NO_ Prefix word........ ______ 4. Journal sequence......... ORDER Validation......... _________________ 5. Cognize response......... NO_ 6. Cognize only p-word...... NO_ 7. Replace previous reply... NO_ 8. Data is a date........... NO_ 9. Cognize in mixed case?... NO_ When you finish type END to save or CANCEL to discard any changes.

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU64 TEST DATA PROCESSING UPDATE PANEL: BLG1A111 Enter 'test word' control data; cursor placement or input line entry allowed. 1. Begin multiple test...... NO_ Structured word.. XTBSMS15A0 2. End multiple test........ NO_ Word acronym..... TBSM=TBSM_NOTIFI 3. Structured word index.... 15A0 Prefix word...... ______ 4. Prefix word index........ 0000 Validation....... ________________ 5. Apply not logic.......... NO_ 6. Case-sensitive compare?.. NO_ When you finish type END to save or CANCEL to discard any changes.


c. The third line checks for the existence of p-word 0272, STAC/CLOSED. If your installation uses a different p-word to indicate a problem closure condition, then change this control line accordingly.

• Control flow processing is shown in Figure 15-18 on page 491.

Figure 15-18 Third line option 1: Control flow processing

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU6A CONTROL FLOW PROCESSING PANEL: BLG1A111 Enter control flow information; cursor placement or input line entry allowed. 1. Control line type.....<R> TEST 2. Function code index...... 0000 Function acronym... __________________ 3. Dialog end............... NO_ 4. Override dialog target... NO_ 5. True target panel........ ________ 6. False target panel....... ________ 7. Authorization code....... 0000 8. Program exit/TSP name.... ________ 9. Message panel............ ________ When you finish type END to save or CANCEL to discard any changes.


• Data collection processing is shown in Figure 15-19.

Figure 15-19 Third line option 2: Data collection processing

• Test data processing is shown in Figure 15-20.

Figure 15-20 Third line option 3: Test data processing

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU6B DATA COLLECTION PROCESSING PANEL: BLG1A111 Enter 'add word' control data; cursor placement or input line entry allowed. 1. Structured word index.... 0000 Structured word.... __________ 2. Prefix index............. 0272 Word acronym....... CODE - UNASSIGNE 3. Journal reply............ NO_ Prefix word........ STAC/ 4. Journal sequence......... ORDER Validation......... <CLOSED> 5. Cognize response......... NO_ 6. Cognize only p-word...... NO_ 7. Replace previous reply... NO_ 8. Data is a date........... NO_ 9. Cognize in mixed case?... NO_ When you finish type END to save or CANCEL to discard any changes.

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU64 TEST DATA PROCESSING UPDATE PANEL: BLG1A111 Enter 'test word' control data; cursor placement or input line entry allowed. 1. Begin multiple test...... NO_ Structured word.. __________ 2. End multiple test........ NO_ Word acronym..... CODE - UNASSIGNE 3. Structured word index.... 0000 Prefix word...... STAC/ 4. Prefix word index........ 0272 Validation....... <CLOSED> 5. Apply not logic.......... YES 6. Case-sensitive compare?.. NO_ When you finish type END to save or CANCEL to discard any changes.


d. The fourth line adds s-word 15A0.

• Control flow processing is shown in Figure 15-21.

Figure 15-21 Fourth line option 1: Control flow processing

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU6A CONTROL FLOW PROCESSING PANEL: BLG1A111 Enter control flow information; cursor placement or input line entry allowed. 1. Control line type.....<R> ADD_ 2. Function code index...... 0000 Function acronym... CODE - UNASSIGNED 3. Dialog end............... NO_ 4. Override dialog target... NO_ 5. True target panel........ ________ 6. False target panel....... ________ 7. Authorization code....... 0000 8. Program exit/TSP name.... ________ 9. Message panel............ ________ When you finish type END to save or CANCEL to discard any changes.


• Data collection processing is shown in Figure 15-22.

Figure 15-22 Fourth line option 2: Data collection processing

• Test data processing, shown in Figure 15-23, requires no changes.

Figure 15-23 Fourth line option 3: Test data processing

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU6B DATA COLLECTION PROCESSING PANEL: BLG1A111 Enter 'add word' control data; cursor placement or input line entry allowed. 1. Structured word index.... 15A0 Structured word.... XTBSMS15A0 2. Prefix index............. 0000 Word acronym....... TBSM=TBSM_NOTIFIED 3. Journal reply............ NO_ Prefix word........ ______ 4. Journal sequence......... ORDER Validation......... _________________ 5. Cognize response......... NO_ 6. Cognize only p-word...... NO_ 7. Replace previous reply... NO_ 8. Data is a date........... NO_ 9. Cognize in mixed case?... NO_ When you finish type END to save or CANCEL to discard any changes.

Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: + ===> BLM8CU64 TEST DATA PROCESSING UPDATE PANEL: BLG1A111 Enter 'test word' control data; cursor placement or input line entry allowed. 1. Begin multiple test...... NO_ Structured word.. XTBSMS15A0 2. End multiple test........ NO_ Word acronym..... TBSM=TBSM_OBJECT 3. Structured word index.... 15A0 Prefix word...... ______ 4. Prefix word index........ 0000 Validation....... ________________ 5. Apply not logic.......... NO_ 6. Case-sensitive compare?.. NO_ When you finish, type END to save or CANCEL to discard any changes.


e. The fifth line invokes BLGTBSMU.

• Control flow processing for this procedure is shown in Figure 15-24.

Figure 15-24 Fifth line option 1: Control flow processing

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU6A CONTROL FLOW PROCESSING PANEL: BLG1A111 Enter control flow information; cursor placement or input line entry allowed. 1. Control line type.....<R> FLOW 2. Function code index...... 001B Function acronym... CODE-FILE TSP 3. Dialog end............... NO_ 4. Override dialog target... NO_ 5. True target panel........ ________ 6. False target panel....... ________ 7. Authorization code....... 0000 8. Program exit/TSP name.... BLGTBSMU 9. Message panel............ ________ When you finish type END to save or CANCEL to discard any changes.


• Data collection processing for this procedure is shown in Figure 15-25.

Figure 15-25 Fifth line option 2: Data collection processing

• Test data processing for this procedure is shown in Figure 15-26.

Figure 15-26 Fifth line option 3:Test data processing

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU6B DATA COLLECTION PROCESSING PANEL: BLG1A111 Enter 'add word' control data; cursor placement or input line entry allowed. 1. Structured word index.... 0000 Structured word.... __________ 2. Prefix index............. 0000 Word acronym....... CODE - UNASSIGNED 3. Journal reply............ NO_ Prefix word........ ______ 4. Journal sequence......... ORDER Validation......... _________________ 5. Cognize response......... NO_ 6. Cognize only p-word...... NO_ 7. Replace previous reply... NO_ 8. Data is a date........... NO_ 9. Cognize in mixed case?... NO_ When you finish type END to save or CANCEL to discard any changes.

Environment Dialog Record Window Options Help ------------------------------------------------------------------------------ BLM8CU64 TEST DATA PROCESSING UPDATE PANEL: BLG1A111 Enter 'test word' control data; cursor placement or input line entry allowed. 1. Begin multiple test...... NO_ Structured word.. __________ 2. End multiple test........ YES Word acronym..... CODE - UNASSIGNED 3. Structured word index.... 0000 Prefix word...... ______ 4. Prefix word index........ 0000 Validation....... ________________ 5. Apply not logic.......... NO_ 6. Case-sensitive compare?.. NO_ When you finish type END to save or CANCEL to discard any changes.


3. Save the panel by entering the SRC END,END,END. The modified BLG1A111 panel is now in the write panel data set. If this data set is not concatenated in your read panel data set, copy this panel to the read panel data set using PMF.

Copying modified panels to the Read Panel data setMost installations of Tivoli Information Management for z/OS will have a multiple Read Panel data set concatenated in front of the IBM-supplied panels and a separate data set used for the write panel data set. In this condition, the panels written by the PMF are not available immediately. You have to copy them using PMF.

1. From PMF, select option 7 panel list to see the available panel data set, similar to Figure 15-27. In our example, we copy the panels from the WPANELS into RPANEL1.

Figure 15-27 Panel list

Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +- ===> BLM1TPDS CURRENT ALLOCATION DATA SETS LOGICAL TYPE DATA SET NAME NAME 1. WPANELS WRITE TIVOLI.BLM.SC69.WPANELS 2. RPANEL0 READ TIVOLI.BLM.SC69.IBMPNLS 3. RPANEL1 READ TIVOLI.BLM.SC69.RPANEL1


2. Select option 1 to list the panels in the WPANELS data set. We have two modified panels, BLGTSPPU and BLG1A111, so the display appears as in Figure 15-28.

Figure 15-28 List of modified panels

3. Use the line command C beside both panels to copy them. Set the target as RPANEL1 and Copy all panels option to YES as shown in Figure 15-29.

Figure 15-29 Panel Copy specification

4. Press ENTER and exit the PMF.

Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +- ===> BLM1TPAL PANEL LIST DISPLAY PANEL 1 OF 2 TIVOLI.BLM.SC69.WPANELS ST PANEL ST PANEL ST PANEL ST PANEL NAME NAME NAME NAME 1. BLGTSPPU 2. BLG1A111

Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: + ===> BLM8CC10 PANEL COPY SPECIFICATION PANEL: BLGTSPPU Enter 'TO' data set below; cursor placement or input line entry allowed. 1. To panel name...................... ________ 2. To data set definition label....<R> RPANEL1_ 3. Replace panel...................... ___ 4. Copy all panels.................... YES To start the COPY function press Enter without field modifications.


15.5 Using the problem ticket interfaceThis section walks you through the implementation of the problem management user exit.

15.5.1 Manual problem ticket operation1. To respond to an event on a DB2 subsystem object D7Q2, we manually

create a problem ticket by right-clicking on the object and selecting Problem tickets -> Create as shown in Figure 15-2.

Table 15-2 Create a problem ticket


2. The Create Problem Ticket dialog is presented as shown in Figure 15-30. In that figure, the various options such as Problem type, Assignee group, Status code, and Severity are retrieved through the problem exit.

Figure 15-30 Problem ticket creation dialog


3. When we created the problem ticket by clicking OK, a series of authentication dialogs appears for accessing the problem ticket subsystem and authentication to access NetView. One of these dialogs is shown in Figure 15-31.

Figure 15-31 Authentication dialog

4. When all information has been entered correctly, NetView invokes the GTMSDRP program to create the problem ticket, as shown in Figure 15-32.

Figure 15-32 Problem ticket created


5. In the console, an icon appears beside the object as shown in Figure 15-33.

Figure 15-33 Problem ticket icon


6. The Tivoli Information Management for z/OS dialog confirms that the problem ticket has been created, as shown in Figure 15-34. We use the command se RNID/00000008 to access the problem ticket and open it with the U line command.

Figure 15-34 Tivoli Information Management for z/OS with the problem ticket

BLG0BU00 PROBLEM SUMMARY PROBLEM: 00000008 Reported by............ VBUDI Problem status.......... OPEN Assignee name.......... CEDRIC Current phase........... ________ Tracked by............. _______________ Current priority........ 01 Network name........... LOB Owning priv. class...... ________ System name............ TBSM Entry priv. class....... MASTER Program name........... D7Q2 Date entered............ 12/12/2002 Device name............ ________ Time entered............ 17:02 Key item affected...... 76 Date last altered....... 12/12/2002 Description............ SUBSYSTEM D7Q2 IS DOWN

Select one of the following type END to save your changes or type CANCEL to discard your changes. 1. Reporter data. 6. Supplemental data. 2. Status data. 7. Synopsis data. 3. Close data. 8. Freeform text. 4. Symptom data. 9. File record.


7. You also can query the problem from the IBM Tivoli Business Systems Manager console by right-clicking the problem ticket and selecting Problem Ticket -> Find as shown in Figure 15-35.

Figure 15-35 Searching for a problem ticket


8. This searches all non-closed tickets for that object. Figure 15-36 shows the result of our search.

Figure 15-36 Problem ticket list


9. Select the ticket from the result list and right-click to open its Properties dialog to update the problem ticket as shown in Figure 15-37.

Figure 15-37 Problem ticket window


10.You can add a description and change any of the fields. In this example, we closed the problem ticket and clicked OK. After filling in the authentication dialogs, we received the confirmation message shown in Figure 15-38.

Figure 15-38 Problem ticket updated

11.With the state CLOSED, the icon beside the object is gone.


15.5.2 Closing a problem ticketRepeat the steps from 15.5.1, “Manual problem ticket operation” on page 499 to create a problem ticket with the specifications shown in Figure 15-39.

Figure 15-39 Creating new problem ticket

In our case, this produces a confirmation that the problem ticket number is 00000009.


Now we go to the mainframe and close the ticket. From the Tivoli Information Management for z/OS main menu, we search with the command SE RNID/00000009 as shown in Figure 15-40.

Figure 15-40 Searching Tivoli Information Management for ticket no 00000009

The search result is shown in Figure 15-41.

Figure 15-41 Search result for ticket no 00000009

BLG0EN20 --- PRIMARY OPTIONS MENU --- APPLICATION: MANAGEMENT OPTIONS: 1. OVERVIEW.......Display general information and product enhancements. 2. PROFILE........Display or alter invocation or session defaults. 3. APPLICATION....Change application list available applications. 4. CLASS..........Change current class list available classes. 5. ENTRY..........Create a record. 6. INQUIRY........Search for records. 7. UTILITY........Copy display print delete and update records. 8. GLOSSARY.......Display a list of searchable words in the database. 9. PMF............Modify or create panels.

Select an option enter a command or type QUIT to exit.

Service Desk for OS/390 Version 1 Release 2 5648-142 (C) Copyright Tivoli Systems Inc. an IBM Company 1997 1999. ===> SE RNID/00000009

BLG1TSRL SEARCH RESULTS LIST LINE 1 OF 1 DATABASE: 5 RECORD ID DESCRIPTION ABSTRACT U 1. 00000009 D7Q2 STILL DOWN *** BOTTOM OF DATA *** Line Cmds: C=Copy D=Delete P=Print S=Select U=Update Type DOWN or UP to scroll the panel or type END to exit the panel. ===>


We update the record by using the line command U and update the closed data by selecting option 3 from the problem data display in Figure 15-42.

Figure 15-42 Closing problem

BLG0BU00 PROBLEM SUMMARY PROBLEM: 00000009 Reported by............ VBUDI Problem status.......... OPEN Assignee name.......... ALESSIO Current phase........... ________ Tracked by............. _______________ Current priority........ 01 Network name........... LOB Owning priv. class...... ________ System name............ TBSM Entry priv. class....... MASTER Program name........... D7Q2 Date entered............ 12/12/2002 Device name............ ________ Time entered............ 17:06 Key item affected...... 76 Date last altered....... 12/12/2002 Description............ D7Q2 STILL DOWN Select one of the following type END to save your changes or type CANCEL to discard your changes. 1. Reporter data. 6. Supplemental data. 2. Status data. 7. Synopsis data. 3. Close data. 8. Freeform text. 4. Symptom data. 9. File record. ===> 3


The closure screen is shown in Figure 15-43. We fill all the required fields, change the status to CLOSED, and type END,9 to file the record. This action initiates the BLGTBSMU and sends this message to the console:

+TSD390CLS - <PROBID=00000009> SET TO CLOSED

Figure 15-43 Closing problem dialog

The message will be used by IBM Tivoli Business Systems Manager to close the note object related to this problem record.

This process also should clear all the icons that indicate a problem record for this object. If not, set the flags column in the object class table to 0.

BLG0B300 PROBLEM CLOSE ENTRY PROBLEM: 00000009 Enter problem closing data; cursor placement or input line entry allowed. 1. Resolved by.....<R> VBUDI__________ 10. Problem status.....<R> CLOSED_ 2. Resolver dept...... ___________ 11. Cause code.........<R> SW______ 3. Resolver phone..... _____________ 12. Program name.......... D7Q2____ 4. Resolver class..... ________ 13. Device name........... ________ 5. Date closed.....<R> 12/12/2002 14. Original prob. number. ________ 6. Time closed........ _____ 15. Cause change number... ________ 7. Total time......... ________ 16. Fix change number..... ________ 8. Duplicate count.... ___ 17. Date rep. notified.... __________ 9. Outage............. ________ 18. Rerun time............ ________ 19. Vendor PD time........ ________ When you finish type END to save or CANCEL to discard any changes.


Chapter 16. High availability and failover

IBM Tivoli Business Systems Manager collects critical events, processes these events according to business needs and manages resources to give a consistent and up-to-date logical business view of the status and health of the enterprise. There is a business need to have IBM Tivoli Business Systems Manager remain operational 24 hours a day and 7 days a week. To deliver near non-stop operation, we must ensure high availability of all of the components employed in IBM Tivoli Business Systems Manager deployment. This is achieved by implementing failover. The discussion consists of:

� 16.1, “Failover concept and terminology” on page 514 discusses the concepts and terms that are necessary for the discussion about failover

� 16.2, “Implementation of failover” on page 515 shows the implementation of failover

� 16.3, “Performing failover” on page 521 describes the way failover and reverse failover are performed

� 16.4, “Limitations and discussion” on page 523 discusses some limitations of failover

� 16.5, “Troubleshooting tips” on page 525 lists some checkpoints if something goes wrong

16


16.1 Failover concept and terminologyThe SQL database is the single most important component of IBM Tivoli Business Systems Manager. The basic principle of failover is to secure this database and all the supporting services that run IBM Tivoli Business Systems Manager by enabling processes and procedures to switch from the primary set of IBM Tivoli Business Systems Manager Windows servers to a secondary set in a controlled manner.

The failover process can be invoked for any of the following reasons:

� IBM Tivoli Business Systems Manager Windows server hardware problem

� IBM Tivoli Business Systems Manager SQL database failure

� Disaster recovery, such as catastrophic site failure

� Scheduled change of operations site

� Scheduled maintenance outages

To understand more about failover for IBM Tivoli Business Systems Manager, the following terms must be defined:

Primary Site The set of IBM Tivoli Business Systems Manager Windows servers that is usually active at the operations site or data center. This designation is static and is made when failover is configured.

Secondary Site The set of IBM Tivoli Business Systems Manager Windows servers that is usually inactive at the fallback or another data center. This designation is static and is made when failover is configured.

Source Site The set of IBM Tivoli Business Systems Manager Windows servers that are actively processing events.

Target Site The set of IBM Tivoli Business Systems Manager Windows servers that are currently inactive.

Failover The process of moving active IBM Tivoli Business Systems Manager processing from the primary site to the secondary site.

Reverse Failover The process of moving active IBM Tivoli Business Systems Manager processing from the secondary site to the primary site.

Log Shipping The process of backing up, copying, and loading the IBM Tivoli Business Systems Manager database transaction logs from the source site to the target site.


Failover Scripts a set of Korn shell scripts to perform failover configuration, transaction Log Shipping initialization, and failover execution.

The following sections discuss the implementation and considerations for this failover process.

16.2 Implementation of failoverThis section discusses the implementation of the failover process. The discussion is divided into:

� 16.2.1, “Prerequisites” on page 515

� 16.2.2, “Installation and customization of failover” on page 516

16.2.1 PrerequisitesPrerequisites for the failover setup are:

� The primary set and secondary set of Windows servers must have the same level of software and fixes/patches installed.

– Same version and patch level of IBM Tivoli Business Systems Manager programs, including any eFixes

– Same version and patch level of all IBM Tivoli Business Systems Manager prerequisite application software and utility programs

– Same version and patch level of Microsoft Windows server operating system

– Same version and patch level of Microsoft SQL Server

� Reliable network connectivity between the primary site and the secondary site. The connectivity check is performed from the database server for both sides to all the hosts by using the following commands:

– ping– SCLIST <hostname>– SC \\<hostname> Query NETLOGON– DIR \\<hostname>\C$– rkill /view \\<hostname>

Important: The source and target site designations switch after every invocation of failover! However, the failover and reverse failover definitions are static. They do not refer to source and target designations.

Chapter 16. High availability and failover 515

� If the primary site and the secondary site are in different NT domains, a full bi-directional trust must be established between these two domains.

� The database services (MSSQLServer and SQLServerAgent) must be logged in with a user account that has full file-system privileges.

� The user account that is used to execute the failover scripts must have administrative level privileges to all of the primary and secondary sets of IBM Tivoli Business Systems Manager servers.

� The server that is running the SQL server for transaction log backup files must have plenty of free disk drive space (up to 30 GB).

16.2.2 Installation and customization of failoverThe implementation consists of these tasks:

� “Setting up the domain trust” on page 516

� “Other Windows settings” on page 516

� “Implementing the failover code” on page 517

� “Editing the failover control file” on page 518

� “Activating failover” on page 520

Setting up the domain trustIf the primary site and secondary site have different NT domains, these additional tasks must be performed for setting the domain trust:

1. Create and verify a Windows user account for the database service in both of these domains. For example:

– TBSMDomain1\TBSMSQL and

– TBSMDomain2\TBSMSQL

2. Add both of these user accounts to the local Administrators group on all servers of both failover sets, or add these user accounts to the Domain Administrators group for both domains.

3. Log on to all the servers of both failover sets with these two user accounts to create their appropriate local profiles.

Other Windows settingsSynchronize the time on all the primary site and secondary site servers with the net time /set \\<servername> command, unless you have a time server. We recommend synchronizing with the live database server’s time.


Implementing the failover codeThe failover code must be installed on:

� The two database servers on the primary and secondary sites

� The history servers, if they are set up with the BCP approach

From the IBM Tivoli Business Systems Manager directory TivoliManager\sql, run the sh ApplyUpgrade -U<sa> -P<passw> -S<server> Failover.upg command where:

<sa> is the SQL server user ID

<passw> is the password for the <sa> user ID

<server> is the name of one of the four database servers where this is run

The following items are created by the upgrade:

� New tables:

backup_movement_plans backup_movement_plan_history tbsm_server_role

� New stored procedures:

asisp_create_backup_movement_plan asisp_recover_databases asisp_create_directory asisp_split_file_path asisp_get_restore_move asisp_enabledisable_job asisp_disable_logship_jobs asisp_create_backup_restore_purge asisp_create_logship_trans_backup asisp_create_logship_backups asisp_restore_logship_backups asisp_create_copy_load_jobs asisp_create_syn_eventcachetime

� Changes in the schema messages

� Stored procedure sp_add_db_to_backup_movement_plan

� Log Shipping stored procedures

log_ship_status log_ship_entity_log log_ship_history_purge log_ship_alert


Editing the failover control fileFirst, generate a failover configuration file template. This file template is generated using the sh fo_config -G > C:/<configfile> command. In our lab, we run the command from IBMTIV5. The generated file template is shown in Example 16-1.

Example 16-1 Template failover configuration file

# *** Please modify hostname IBMTIV5 to match your TBSM environment. *** # This is the failover configuration file read by fo_config script. # For further information, issue the 'sh fo_config -h' in a command prompt.## -----SERVER ROLE ----- -----HOSTNAME------ROLE_SQLServer_Primary | IBMTIV5ROLE_HistServer_Primary | IBMTIV5ROLE_ConsoleServer_Primary | IBMTIV5ROLE_AppServer15_Primary | IBMTIV5ROLE_PaServer_Primary | IBMTIV5ROLE_SnaServer_Primary | IBMTIV5ROLE_EhServer_Primary | IBMTIV5ROLE_SsServer_Primary | IBMTIV5ROLE_UpLoadRuleServer_Primary | IBMTIV5ROLE_WebServer_Primary | IBMTIV5ROLE_HmServer_Primary | IBMTIV5ROLE_AgentListener_Primary | IBMTIV5ROLE_CommonListener_Primary | IBMTIV5ROLE_TECListener_Primary | IBMTIV5ROLE_TSDMonitor_Primary | IBMTIV5ROLE_TGMTaskServer_Primary | IBMTIV5#ROLE_SQLServer_Secondary | IBMTIV5ROLE_HistServer_Secondary | IBMTIV5ROLE_ConsoleServer_Secondary | IBMTIV5ROLE_AppServer15_Secondary | IBMTIV5ROLE_PaServer_Secondary | IBMTIV5ROLE_SnaServer_Secondary | IBMTIV5ROLE_EhServer_Secondary | IBMTIV5ROLE_SsServer_Secondary | IBMTIV5ROLE_UpLoadRuleServer_Secondary | IBMTIV5ROLE_WebServer_Secondary | IBMTIV5ROLE_HmServer_Secondary | IBMTIV5ROLE_AgentListener_Secondary | IBMTIV5ROLE_CommonListener_Secondary | IBMTIV5ROLE_TECListener_Secondary | IBMTIV5ROLE_TSDMonitor_Secondary | IBMTIV5ROLE_TGMTaskServer_Secondary | IBMTIV5


You must edit the configuration file to supply your host names. Example 16-2 shows our resulting configuration file, based on our lab configuration described in 1.5, “Lab environment” on page 22. We removed the definitions for SNA Server and Application Server.

Example 16-2 Edited configuration file TI7043fo.cfg

# *** Please modify hostname IBMTIV5 to match your TBSM environment. *** # This is the failover configuration file read by fo_config script. # For further information, issue the 'sh fo_config -h' in a command prompt.## -----SERVER ROLE ----- -----HOSTNAME------ROLE_SQLServer_Primary | IBMTIV5ROLE_HistServer_Primary | IBMTIV6ROLE_ConsoleServer_Primary | IBMTIV3ROLE_AppServer15_Primary |ROLE_PaServer_Primary | IBMTIV3ROLE_SnaServer_Primary |ROLE_EhServer_Primary | IBMTIV3ROLE_SsServer_Primary | IBMTIV3ROLE_UpLoadRuleServer_Primary | IBMTIV3ROLE_WebServer_Primary | IBMTIV6ROLE_HmServer_Primary | IBMTIV6ROLE_AgentListener_Primary | IBMTIV5ROLE_CommonListener_Primary | IBMTIV3ROLE_TECListener_Primary | IBMTIV5ROLE_TSDMonitor_Primary | IBMTIV5ROLE_TGMTaskServer_Primary | IBMTIV5#ROLE_SQLServer_Secondary | TBSMSQL1ROLE_HistServer_Secondary | TBSMHIST1ROLE_ConsoleServer_Secondary | TBSMCON1ROLE_AppServer15_Secondary |ROLE_PaServer_Secondary | TBSMCON1ROLE_SnaServer_Secondary |ROLE_EhServer_Secondary | TBSMCON1ROLE_SsServer_Secondary | TBSMCON1ROLE_UpLoadRuleServer_Secondary | TBSMCON1ROLE_WebServer_Secondary | TBSMHIST1ROLE_HmServer_Secondary | TBSMHIST1ROLE_AgentListener_Secondary | TBSMSQL1ROLE_CommonListener_Secondary | TBSMCON1ROLE_TECListener_Secondary | TBSMSQL1ROLE_TSDMonitor_Secondary | TBSMSQL1ROLE_TGMTaskServer_Secondary | TBSMSQL1


Activating failoverFailover is activated by loading the configuration file. We run the sh fo_config -f ./TI7043fo.cfg command to load the configuration. It will be stored in the tbsm_server_role table.

Once the configuration has been loaded on all the servers, we must initialize Log Shipping by running the fo_logship command. We run sh fo_logship -T where the -T parameter sets the Trace mode for this initialization run.

After this initialization run completes, check the output created by this process in the file named fo_logship.cmd.<pid>.log in the TivoliManager\Logs\ directory. The <pid> is a numeric variable created by the process. An excerpt on the beginning of the log is shown in Example 16-3.

Example 16-3 Log Shipping log file

<date><time> T Log writing to C:/TivoliManager/Logs/fo_Failover.cmd.<pid>.log!<date><time> I Start Executing Command file C:/TivoliManager/Logs/fo_Failover.cmd.1668. . .<date><time> I ISSUING SQL cmd=osql …<date><time> Successfully executed SQL command…. . .<date><time> I Completed Executing Command file C:/TivoliManager/Logs/fo_Failover.cmd.<pid> successfully<date><time> I See Log file C:/TivoliManager/Logs/fo_Failover.cmd.<pid>.log for details

Log Shipping must be checked and verified on all four Microsoft SQL Server database engines. The steps to verify them are:

1. Verify that all the Log Shipping database jobs are copied and loaded successfully without error. These job names start with TBSM Log Shipping. You have to run the stored procedure exec msdb..log_ship_status from the SQL Query Analyzer window.

2. Run the TBSM Log Shipping Out of Synch Check job to verify that databases between the sites are in sync.

If you get this far, the failover process installation is complete. However, you also must complete the setup on the mainframes before you can activate failover.

16.2.3 Setup for z/OSUse one of these failover setups on the mainframe systems, OS/390 and z/OS, depending on the connectivity type between the TBSM windows servers and the mainframe systems.


SNA-based connectivityWe do not use SNA-based connectivity in our lab, so these steps are from the IBM Tivoli Business Systems Manager: Installation and Configuration Guide, GC32-0800:

1. Each of the two SNA servers must have a unique Local APPC LU defined in the Tivoli Business Systems Manager parmlib, which is read during the Source/390 object server initialization.

2. One member of the Source/390 object server points to the address of the primary SNA server, and the other points to the address of the secondary SNA server.

3. In VTAM, configure the logical primary SNA server and the secondary SNA server to have the same independent LU name. This requires the generation of unique PU Type 2 (Connection Names) definitions for each of the SNA servers. The Local APPC LUs should be defined as the same name for each of the PU definitions.

TCP/IP-based connectivityTwo optional TCP/IP parameters in the Source/390 object server parmlib member, TCP/IP_ADDRESS_BACKUP and TCP/IP_NAME_BACKUP, are used for a backup connection that communicates with the alternative ASIMVSIPOSListenerSvc service in the event the primary connection fails. Only one of these parameters is needed.

The following steps must be set up on all instances of the Source/390 systems connected to the IBM Tivoli Business Systems Manager servers:

1. Use either TCP/IP_ADDRESS_BACKUP or TCP/IP_NAME_BACKUP for the TCP/IP address or the host name of the server where ASIMVSIPOSListenerSvc runs at the secondary site. This is usually the event handler server.

2. Add the respective TCP/IP address or the host name of the server where the sender service at the secondary site runs to the VALIDCLIENT parameter. Add another VALIDCLIENT parameter, in addition to the existing one, with the TCP/IP address or the host name of the server where the Sender Service at the secondary site runs. This authorizes the server to send data to the Source/390 object server.

16.3 Performing failoverOnce the failover process has been installed and initialized on the Tivoli Business Systems Manager servers and setup has been completed on mainframe systems, failover can be used.


16.3.1 Enabling failoverFailover is accomplished by running the sh fo_failover.ksh -T command on the target SQL server. This generates a command file in the directory where this script runs. The name of this file is fo_failover.cmd.<pid> where <pid> is the numeric variable generated by the script. It is recommended that you verify this generated failover command file and make and save any changes as necessary.

If the Source/390 connection is SNA-based, you must perform the following tasks before activating the failover:

� Inactivate the primary SNA server PU on mainframe systems with the command V NET,INACT,ID=puname,F.

� Stop the Source/390 object server started task. The object pump will continue to collect events and place them into the dataspace until communication to the target site SNA server is re-established.

There are no specific tasks to perform on mainframe systems if there is TCP/IP-based connectivity between the IBM Tivoli Business Systems Manager servers and Source/390 systems.

Now run the command sh fo_cmd_execute.ksh -T -f fo_failover.cmd.<pid> to execute the failover commands. Check the failover log, fo_Failover.cmd.<pid>.log in the logs directory for errors.

For SNA-based connectivity to Source/390 systems, you must delete the VTAM ALSLIST association to the primary SNA server with the commandF vtamname,ALSLIST,id=luname,OLDALS=puname,action=DELETE then restart the Source/390 object server and point it to the parmlib member that contains the target SNA server.

Bulk discovery download jobs that use the GTMAOPE0 utility must be configured to reflect the new IP address of the new activated server that runs the ASIMVSIPListener service. Set up one job as the primary job using the production ASIMVSIPListenerSvc service pointing to the primary site. Set up another job as the secondary or backup job that uses the failover ASIMVSIPListenerSvc service on the secondary site.

All of the common listener-based data sources must be redirected to point to the newly active server running the ASICommonListener service. This can be done with the fo_commonlistener.ksh script if it has been customized.

16.3.2 Enabling reverse failoverReverse failover is normal failover in reverse, except that it runs from the secondary site to the primary site. This normally means that the source is the


secondary site and the target is the primary site. The following steps are necessary for the reversing process:

1. First of all, Log Shipping must be reversed to go from the active secondary site to the primary site. It is important to note that the actual reverse failover process can be delayed for maintenance or testing purposes. However, Log Shipping must be run at all times. Invoke Log Shipping using the command sh fo_logship -R -T. The -R parameter indicates that this is a reverse-direction Log Shipping.

2. Verify that Log Shipping has been successfully deployed by checking the Log Shipping log in fo_logship.cmd.<pid>.log in the TivoliManager\Logs\ directory. The <pid> is a numeric variable created by the process.

3. Log Shipping must be checked and verified on all four database servers by running the stored procedure msdb..log_ship_status and running the TBSM Log Shipping Out of Synch Check job.

4. When ready to start the reverse failover, run the sh fo_failover.ksh -R -T script on the target (primary site) SQL server. This generates the failover command file named fo_failover.cmd.<pid> in the directory where this script runs.

5. Perform a similar setup for the SNA connection as described in 16.3.1, “Enabling failover” on page 522. Then you can run the fo_cmd_execute.ksh to execute the reverse failover command file, then reset the SNA connection again. Check the failover log for errors in fo_Failover.cmd.<pid>.log where <pid> is a variable.

6. Restore the bulk discovery download jobs (those that use the GTMAOPE0 utility) to point to the primary site.

7. All the common listener-based data sources must be re-directed to point back to the primary site.

16.4 Limitations and discussionLog Shipping is based on the Microsoft Log Shipping function of SQL Server. The Log Shipping process works by creating transaction log backups of all Tivoli Business Systems Manager databases on the primary site, copying the backups over to the secondary site, and loading the backups at every pre-defined time interval. (The default is 5 minutes.) Full backups of the primary databases are created as a snapshot or reference point to begin the process.

The following considerations apply to failover processing:

� Failover is not automatic. It is invoked manually after it is properly configured.

� Tivoli Business Systems Manager Failover is a warm standby solution. It is not truly redundant.


� Data feeds and processing occur only on the active source site.

� Failover does not address data feed (data source) redundancy.

� Failover is not intended as a tool to address the following issues:

– Software bugs– Software distribution of patches/upgrades– Synchronization of files/binaries between the two sites

� The failover scripts do not automatically redirect the user consoles. Users must be notified by the Tivoli Business Systems Manager administrator to log in to the newly activated site.

� It is necessary to run the history server re-synchronization script, fo_resynch_histserver.ksh, to synchronize the BCP History process on the newly active site after a successful failover. This prevents unusually high overhead on the SQL server during reporting system usage.

� All clocks for Tivoli Business Systems Manager servers participating in failover must be synchronized.

� Interfaces to problem/change systems using the Tivoli Business Systems Manager Problem/Change API must be designed to accommodate switching between the two Tivoli Business Systems Manager sites.

� Data feeds using the Common Listener service must have a custom script created to redirect the feeds back and forth between the two Tivoli Business Systems Manager sites. The content of the fo_commonlistener.ksh script must be created onsite at the time of failover installation to account for customer-specific environments. Customers who choose not to use this functionality are responsible for manually redirecting the data feeds in whatever manner desired at the time of failover. The data feeds in IBM Tivoli Business Systems Manager that are affected are:

– Distributed Monitor 4.x and higher

– NetView Distributed

– TNG

– PATROL

– NetIQ

– TWS

– OS/390 Bulk Discovery Data Feeds (OPC, IMS, DB2, CPSM, and RODM) must be reconfigured manually using the GTMAOPE0 utility to point to the newly activated site. It is recommended that you include the reconfiguration steps in a JCL that can be run at the time of failover. Refer to the IBM Tivoli Business Systems Manager: Installation and Configuration Guide, GC32-0800 for the necessary steps.


16.5 Troubleshooting tipsAlthough this is not intended to be the comprehensive troubleshooting guide to failover, it includes some quick checks to help you to isolate problem areas:

� Be sure all fixes, patches, and eFixes have been applied to both the source and target sites.

� Be sure the IBM Tivoli Business Systems Manager configuration is the same on the target site as on the sourcesite.

� Be sure that there is enough free disk space on the SQL server disk drive where the \logshipbackup directory is.

� Be sure that all IBM Tivoli Business Systems Manager services and processes are stopped on the target site.

� Be sure that any Query Analyzer session opened for the target site is pointing only to the msdb or master databases.

� Run select * from sysprocesses in SQL Query Analyzer pointing to the target site master database to check for any unwanted, still-active processes that will prevent Log Shipping from running successfully.

� Check the failover log fo_failover.cmd.<pid>.log).

� Check the Log Shipping log fo_logship.cmd.<pid>).

� Run the SQL stored procedure msdb..log_ship_entity_log for details of Log Shipping jobs.

� For more-detailed information about any failing Log Shipping SQL job, try executing the job step from a SQL Query Analyzer session.

� Run sh fo_chk_connectivity.ksh to verify connectivity between source and target sites and command functionality.


Chapter 17. Historical reporting with TEDW

The Tivoli Enterprise Data Warehouse (TEDW) is an infrastructure used to collect and manage data from various Tivoli and non-Tivoli system management applications. This chapter goes into detail about how IBM Tivoli Business Systems Manager leverages the Tivoli Enterprise Data Warehouse and how to implement integration. We cover:

� 17.1, “Tivoli Enterprise Data Warehouse overview” on page 528 describes the concept of Tivoli Enterprise Data Warehouse

� 17.2, “Installation and configuration for data warehouse” on page 533 shows how to install and configure an IBM Tivoli Business Systems Manager component for Data Warehouse

� 17.3, “Activating collection” on page 538 shows how the collection process can be performed using the DB2 Warehouse Control

17


17.1 Tivoli Enterprise Data Warehouse overviewCustomers can benefit from using Tivoli Enterprise Data Warehouse in various ways:

� Tivoli Enterprise Data Warehouse collects historical data from many applications into one central location.

Tivoli Enterprise Data Warehouse collects the underlying data about customers’ network devices and connections, desktop computers and servers, applications and software, and the problems and activities that are part of managing the infrastructure. This enables customers to construct an end-to-end view of their enterprise and view the components independent of specific applications used to monitor and control resources.

� Tivoli Enterprise Data Warehouse adds value to raw data.

Tivoli Enterprise Data Warehouse performs data aggregation in hourly levels in the central data repository and can be restricted to other levels, such as daily and weekly, for data reporting in the data marts. The data also is cleaned and consolidated in order to enable the data model of the central repository to share common dimensions. For example, Tivoli Enterprise Data Warehouse ensures that time, host name, and IP address are the same dimensions across all the applications.

� Tivoli Enterprise Data Warehouse enables the correlation of information from many Tivoli applications.

Tivoli Enterprise Data Warehouse can be used to derive added value by correlating data from many Tivoli applications. It enables reports to be written that correlate cross-application data.

� Tivoli Enterprise Data Warehouse uses open, proven interfaces for extracting, storing, and sharing data.

Tivoli Enterprise Data Warehouse can extract data from any application (Tivoli and non-Tivoli) and store it in a common central database. Tivoli Enterprise Data Warehouse also provides transparent access for third-party Business Intelligence (BI) solutions (CWM standard), such as IBM DB2 OLAP, Crystal Decisions, Cognos, BusinessObjects, Brio Technology, and Microsoft OLAP Server. CWM stands for Common Warehouse Metadata, an industry standard specification for metadata interchange defined by the Object Management Group (http://www.omg.org). Tivoli Enterprise Data Warehouse provides a Web-based reporting front end, called the Reporting Interface, but the open architecture provided by the Tivoli Enterprise Data Warehouse allows other BI front ends to be used to access the data in the central warehouse. The value here is flexibility. Customers are not limited to any one reporting application, so can use the application of their choice.


http://www.omg.org

� Tivoli Enterprise Data Warehouse provides a robust security mechanism.

Tivoli Enterprise Data Warehouse provides a robust security mechanism by enabling data marts to be built with data from subsets of managed resources. By providing database-level authorization to access those data marts, Tivoli Enterprise Data Warehouse can address most of the security requirements related to limiting access to specific data to those customers or business units with a need to know.

� Tivoli Enterprise Data Warehouse provides a scalable architecture.

As Tivoli Enterprise Data Warehouse depends on the proven and industry standard RDBMS technology, it provides a scalable architecture for storing and retrieving data.

17.1.1 Tivoli Enterprise Data Warehouse concepts and componentsIn this section, we describe the key concepts and the various components of Tivoli Enterprise Data Warehouse in the logical order that the measurement data flows: from the monitors collecting raw data to the final detailed report.

Figure 17-1 depicts a typical Tivoli Enterprise Data Warehouse configuration.

Figure 17-1 A typical Tivoli Enterprise Data Warehouse environment

It is common for enterprises to deploy various distributed performance and availability monitoring applications that collect some sort of measurement data

Source Applications

Source Appls ETLs

TEDW EnvironmentITMDatabase

TECDatabase

ITMDatabase

ITMDatabase

Third-PartyDatabase

Business Intelligence and Reporting Tools

Cognos

IBM

Crystal Reports

Business Objects

BRIO

TEDW Central Data

Warehouse

TEDW Control

(Metadata)

Target ETLs

TEDW Control Center

Data Mart

Data Mart

Data Mart

Data MartData Mart

TEDW Reporting Interface

ITM

Third Party

ITMfBI

ITMfWeb

TEC

Chapter 17. Historical reporting with TEDW 529

and provide some type of threshold management, central event management, and other basic monitoring functions. These applications are referred to as source applications.

The first step in obtaining management data is to enable the source applications. This means providing all tools and customizations necessary to import the source operational data into the Tivoli Enterprise Data Warehouse central data warehouse. All components needed for that task are collected in a warehouse package for each source application. In this chapter, IBM Tivoli Business Systems Manager is the source application providing management information.

One important feature of the warehouse package is the extract, transform, and load data programs, or, simply, ETL programs. In general, ETL programs process data in three steps. First, they extract the data from a source application database called data source. Then the data is validated, transformed, aggregated, and/or cleansed so that it fits the format and needs of the data target. Finally, the data is loaded into the target database.

Tivoli Enterprise Data Warehouse has two types of ETLs: central data warehouse ETL and data mart ETL.

� The central data warehouse ETL pulls the data from the source applications and loads it into the central data warehouse, as shown in Figure 17-1 on page 529. The central data warehouse ETL is also referred to as source ETL or ETL1.

� The data mart ETL, as shown in Figure 17-1 on page 529, extracts a subset of historical data from the central data warehouse, which contains data tailored to and optimized for a specific reporting or analysis task. This subset of data is used to populate data marts. The data mart ETL is also known as target ETL or ETL2.

As a generic concept, a data warehouse is a structured extensible database environment designed for the analysis of consistent data. The data that is inserted in a data warehouse is logically and physically transformed from multiple source applications, updated, and maintained for a long time period, and summarized for quick analysis. The Tivoli Enterprise Data Warehouse central data warehouse (CDW) is the database that contains all enterprise-wide historical data (with hour as the lowest granularity). This data store is optimized for the efficient storage of large amounts of data and has a documented format that makes the data accessible to many analysis solutions. The database is organized in a very flexible way, which lets you store data from new applications without adding or changing tables.

The Tivoli Enterprise Data Warehouse server is an IBM DB2 Universal Database Enterprise Edition server that hosts the Tivoli Enterprise Data Warehouse Central Data Warehouse databases. These databases are populated with


operational data from Tivoli and/or other third-party applications for historical analyses.

A data mart is a subset of the historical data that satisfies the needs of a specific department, team, or customer. A data mart is optimized for interactive reporting and data analysis. The format of a data mart is specific to the reporting or analysis tool you plan to use. Each application that provides a data mart ETL creates its data marts in the appropriate format.

Tivoli Enterprise Data Warehouse provides a Report Interface (RI) that creates static two-dimensional reports of your data using the data marts. The RI is a role-based Web interface that can be accessed with a simple Web browser without any additional software installed on the client. You can also use other tools to perform OLAP analysis, business intelligence reporting, or data mining.

The Tivoli Enterprise Data Warehouse control center is the IBM DB2 Universal Database Enterprise Edition server containing the Tivoli Enterprise Data Warehouse control database that manages your Tivoli Enterprise Data Warehouse environment. From the Tivoli Enterprise Data Warehouse control center, you can see all source application databases in your environment. The default internal name for the Tivoli Enterprise Data Warehouse Control database is TWH_MD. The Tivoli Enterprise Data Warehouse Control Center also manages the communication between the various components, such as the Tivoli Enterprise Data Warehouse Central Data Warehouse, the data marts, and the Report Interfaces. The Tivoli Enterprise Data Warehouse Control Center uses the DB2 Data Warehouse Center utility to define, maintain, schedule, and monitor the ETL processes

The Tivoli Enterprise Data Warehouse stores cleansed historical data from all Tivoli and third-party application databases in the Tivoli Enterprise Data Warehouse Central Data Warehouse database. The Tivoli Enterprise Data Warehouse CDW database is named TWH_CDW. Once the data has been inserted into the TWH_CDW database, it is available for either the Tivoli Enterprise Data Warehouse ETLs to load to the Tivoli Enterprise Data Warehouse Data Mart database (the Tivoli Enterprise Data Warehouse Data Mart database is named TWH_MART) or to any other application-specific ETL to process the data and load the application-specific Data Mart database.

All Tivoli Enterprise Data Warehouse ETL programs follow a naming convention using a three-letter, application-specific product code known as measurement source code. Some examples of these measurement source codes can be found later in this chapter.


17.1.2 IBM Tivoli Business Systems Manager integrationThe structure of the IBM Tivoli Business Systems Manager reporting component is shown in Figure 17-2.

Figure 17-2 IBM Tivoli Business Systems Manager warehouse component

As shown, warehouse processing goes through the following steps:

1. IBM Tivoli Business Systems Manager business systems object receives its status information based on the events from various sources and propagation processing. This information is stored in an IBM Tivoli Business Systems Manager Microsoft SQL Server database called Object.

2. IBM Tivoli Business Systems Manager ETL loads the data into the Central Data Warehouse. The source ETL has a measurement code of GTM.

3. From this central data warehouse, data can be extracted into a data mart. Typically it is stored in a database called TWH_MART. IBM Tivoli Business Systems Manager does not provide this function.

More information about the IBM Tivoli Business Systems Manager integration with Tivoli Enterprise Data Warehouse is provided as a PDF file in the IBM Tivoli Business Systems Manager CD in etl\gtm\pkg\v210\doc\TBSM_for_TEDW.pdf.

Now, we can start installing the components.

W indows 2000DB2 EE ServerTEDW Server

TBSM ETL (GTM)

TW H_MD

2

3TW H_CDW TW H_MARTObjectDatabase

TBSM SQL Database Server

TEDW Server

1


17.2 Installation and configuration for data warehouseIn this section, we describe the necessary steps to configure the data-gathering process in your environment. The basic steps are:

1. Have the environment with the IBM Tivoli Business Systems Manager installed and working properly. Set up the Business System View objects as discussed in Chapter 12, “Automatic Business System View creation” on page 395.

2. Have the Tivoli Enterprise Data Warehouse server or servers installed properly with the necessary patches as specified in 17.2.1, “Warehouse integration pre-installation steps” on page 533.

3. Install and configure the IBM Tivoli Business Systems Manager Warehouse component as in 17.2.2, “Setting up the source ETL” on page 534.

4. Define the ODBC data source for the Microsoft SQL Server used by IBM Tivoli Business Systems Manager, and run the ETL process. This step is discussed in 17.3, “Activating collection” on page 538.

5. Evaluate the result.

Before going into the details of each step, we present the environment used in our lab. This can be used as a starting point for setting up the data-gathering process. We assume that no preexisting components will be used and describe the steps of a brand new installation. We install most of the data warehouse components in a single machine; however, for a production environment, you may want to have the following separate machines:

� Tivoli Enterprise Data Warehouse Server machine hosting the Central Warehouse and the Warehouse data mart databases; this should have the largest disk capacity and the fastest processor.

� Tivoli Enterprise Data Warehouse Control Center machine hosting the Warehouse metadata database and handling all ETL scheduling.

� Tivoli Enterprise Data Warehouse Reporting Interface machine allowing end users to obtain reports from data stored in the IBM Tivoli Monitoring data marts.

17.2.1 Warehouse integration pre-installation stepsIt is assumed that your Tivoli Enterprise Data Warehouse Environment Version 1.1 is already installed and up and running. Details for that can be found in Introduction to Tivoli Enterprise Data Warehouse, SG24-6607.


Prior to the installation of the Warehouse packs programs, the following tasks must be completed:

� Upgrade IBM DB2 Universal Database Enterprise Edition Version 7.2 to at least FixPack 6 level on your Tivoli Enterprise Data Warehouse environment. FixPack6 for IBM DB2 Universal Database Enterprise Edition can be downloaded from the official IBM DB2 technical support Web site at:

http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v7fphist.d2w/report

� Apply the following fixes for the Tivoli Enterprise Data Warehouse:

– 1.1-TDW-0002– 1.1-TDW-0005E– 1.1-TDW-FP01a

These can be downloaded from the IBM Tivoli Software support Web site, under the Tivoli Enterprise Data Warehouse category, at:

http://www.ibm.com/software/sysmgmt/products/support/

The documentation that accompanies the FixPacks shows the installation steps in great detail.

17.2.2 Setting up the source ETLThis section describes the installation procedures needed to install and configure the source ETL, which is provided on the IBM Tivoli Business Systems Manager Version 2.1 Distributed CD. IBM Tivoli Business Systems Manager warehouse ETL extracts data regarding business systems objects from the Microsoft SQL Server Object database and loads it into the Tivoli Enterprise Data Warehouse CDW database (TWH_CDW), therefore acting as a source ETL. The measurement source code for the IBM Tivoli Business Systems Manager ETL is GTM.

Installation can be performed using the Tivoli Enterprise Data Warehouse CLI or the GUI installation program. Here we describe the process using the GUI method. The following steps should be performed in the Tivoli Enterprise Data Warehouse Control Center server.

Important: Introduction to Tivoli Enterprise Data Warehouse, SG24-6607, mentions that the Windows Services “Warehouse Server” and “Warehouse Logger” must be reconfigured to run as the db2admin user. If you have not made this change, you will see failures when trying import data into the TWH_CDW database. Be sure that you have reconfigured these services and restarted them.


http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v7fphist.d2w/report

http://www.ibm.com/software/sysmgmt/products/support/

You need both the Tivoli Enterprise Data Warehouse installation media and the IBM Tivoli Business Systems Manager Version 2.1 Distributed CD.

1. Run setup.exe from the Tivoli Enterprise Data Warehouse CD-ROM and click OK to start the installation.

2. When the InstallShield Wizard dialog window for Tivoli Enterprise Data Warehouse Installation appears, click Next.

3. The dialog window for the type of installation appears as shown in Figure 17-3. Select Application installation only and the directory name where the Tivoli Enterprise Data Warehouse components are installed. (We used C:\TWH.) Click Next to continue.

Figure 17-3 Installation type

4. The host name window appears. Verify that this is the correct host name for the Tivoli Enterprise Data Warehouse Control Center server. Click Next.

5. The local system DB2 configuration window appears. The installation process asks for a valid DB2 user ID. Enter the DB2 user ID and password that were created during the DB2 installation on your local system. In our case, we used db2admin. Click Next.

6. The path to the installation media for the application packages window appears, as shown in Figure 17-4 on page 536. Provide the location of the


IBM Tivoli Business Systems Manager ETL program. If necessary, change out the Tivoli Enterprise Data Warehouse CD in the CD-ROM drive with the IBM Tivoli Business Systems Manager Distributed CD. Specify the path to the twh_app_install_list.cfg file (by default, in the CD_drive:\etl\GTM\ directory) in the directory name field. Leave the Now (prevents typing errors) option checked to verify that the source directory is immediately accessible and that it contains the correct files. Click Next.

Figure 17-4 Path to the installation media for the GTM


7. Skip the option to install other application components by clicking Next. The overview of selected features window appears, as shown in Figure 17-5. Click Install to start the installation.

Figure 17-5 IBM Tivoli Business Systems Manager program installation


8. Once the installation is finished, the Installation summary window appears, as shown in Figure 17-6 on page 538. If the installation was not successful, check the TWHApp.log file for errors. This log file is located in <TWH_inst_dir>\apps\GTM\, where <TWH_inst_dir> is the Tivoli Enterprise Data Warehouse installation directory.

Figure 17-6 IBM Tivoli Business Systems Manager ETL Installation summary

9. After the pack installation concludes, you must reboot the Tivoli Enterprise Data Warehouse Control Center server.

17.3 Activating collectionSome configuration settings must be changed for the IBM Tivoli Monitoring Version 5.1.1 Warehouse Pack to function properly. They are described in:

� 17.3.1, “Changes on the TWH_CDW database” on page 539

� 17.3.2, “Creating an ODBC connection to source database” on page 539

� 17.3.3, “Defining authority to the Warehouse Sources and Targets” on page 543

� 17.3.4, “Scheduling the source ETL” on page 548


� 17.3.5, “Changing the source ETL status to Production” on page 551

� 17.3.6, “Running ETLs” on page 552

17.3.1 Changes on the TWH_CDW databaseThe applications-control heap size on the TWH_CDW database must be set to at least 512, as follows:

1. Logged in as your DB2 administrator user ID on your Tivoli Enterprise Data Warehouse Server machine, in our case db2admin, connect to the TWH_CDW database:

db2 connect to TWH_CDW user db2admin using <db2pw>

where <db2pw> is the database administrator password.

2. In order to determine the actual heap size, issue:

db2 get db cfg for TWH_CDW | grep CTL_HEAP

The output should be similar to this:

Max appl. control heap size (4KB) (APP_CTL_HEAP_SZ) = 128

3. If the heap size is less that 512, change it by performing:

db2 update db cfg for TWH_CDW using APP_CTL_HEAP_SZ 512

The output should be similar to this:

DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.DB21026I For most configuration parameters, all applications must disconnect from this database before the changes become effective.

4. You should now restart DB2 by issuing:

db2 disconnect THW_CDWdb2 force application alldb2 terminatedb2stopdb2admin stopdb2admin startdb2start

17.3.2 Creating an ODBC connection to source database The Tivoli Enterprise Data Warehouse Control Center server hosts all the ETLs, and it must have access to the various databases that the SQL scripts deal with. In the case of the IBM Tivoli Business Systems Manager ETL, a connection to the Microsoft SQL Server’s Object database should be defined.


On the Tivoli Enterprise Data Warehouse Control Center server, create a new ODBC System data source using the following procedure:

1. Open the Windows Control Panel and select ODBC. In the ODBC settings dialog, click the System DSN tab as shown in Figure 17-7 on page 540. Click Add.

Figure 17-7 System DSN tab


2. When adding the System DSN, select SQL Server as the data source as shown in Figure 17-8. Click Finish.

Figure 17-8 Selecting the data source for ODBC System DSN

3. Specific dialog for the SQL Server data source is shown in Figure 17-9. Here, the data source name should be GTM_DB as required by the ETL program. You also must specify the SQL server machine. Click Next to continue.

Figure 17-9 SQL Server data source settings


4. In the next window, specify the sa user ID and password for accessing the database. We use the SQL server authentication method as shown in Figure 17-10. Click Next to continue.

Figure 17-10 User authentication for the new data source

5. Make the Object database the default database and uncheck the ANSI options as shown in Figure 17-11. Click Next to continue.

Figure 17-11 Other options


6. Then finalize the data source. You have the option to check the connection by clicking the Test Data Source button. This is shown in Figure 17-12.

Figure 17-12 Completing the data source definition

The new GTM_DB data source is now ready.

17.3.3 Defining authority to the Warehouse Sources and TargetsYou should inform the Tivoli Enterprise Data Warehouse Control Center server of user access information for every source and target database installed by the IBM Tivoli Business Systems Manager ETL. The following steps should be taken:

1. Start the IBM DB2 Control Center utility by selecting Start -> Programs -> IBM DB2 -> Control Center.

2. On the IBM DB2 Control Center utility, start the IBM DB2 Data Warehouse Center utility by selecting Tools -> Data Warehouse Center. The Data Warehouse Center logon window appears.

3. Log on to the IBM DB2 Data Warehouse Center utility using the local DB2 administrator user ID (in our case, db2admin).


4. In the Data Warehouse Center window, expand the Warehouse Sources folder. As shown in Figure 17-13 on page 544, there is only one source database for IBM Tivoli Business Systems Manager , the GTM_OBJECT_Source.

Figure 17-13 IBM Tivoli Monitoring Version 5.1.1 Generic ETL1 Sources


Edit the properties of each displayed entry by right-clicking an entry, selecting Properties, and then selecting the Data Source tab. Fill in the database instance owner user ID information. For our environment, the values are shown in Figure 17-14, using the GTM_OBJECT_Source as an example. Typically the password is sa_<hostname>.

Figure 17-14 GTM_OBJECT_Source user ID information


For the IBM Tivoli Business Systems Manager ETL target database, edit GTM_TWH_CDW_Target, as shown in Figure 17-15.

Figure 17-15 IBM Tivoli Business Systems Manager ETL target


5. Right-click the GTM_TWH_CDW_Target, select Properties, then select the Database tab. Fill in the user ID information as shown in Figure 17-16.

Figure 17-16 GTM_TWH_CDW_Target user ID information


17.3.4 Scheduling the source ETLIn the Processes folder, the IBM Tivoli Business Systems Manager ETL is stored as GTM_c05_LOBState_Process. The conceptual flow is shown in Figure 17-17.

Figure 17-17 GTM_c05_LOBState_Process flow


To run the GTM_c05_LOBState_Process, schedule only the first process step, which is GTM_c05_s010_Load_LOBStage. Follow these steps:

1. On the Tivoli Enterprise Data Warehouse Control Center server, using the Data Warehouse Center window, expand Subject Areas -> GTM_Tivoli_Business_Systems_Manager_v2.1_Subject_Area -> Processes and select GTM_c05_LOBState_Process. Right-click GTM_c05_s010_Load_LOBStage. Choose Schedule, as shown in Figure 17-18.

Figure 17-18 Schedule GTM_c05_s010_Load_LOBStage


2. Select Schedule to open a dialog box, as shown in Figure 17-19.

Figure 17-19 Schedule configuration for GTM_c05_s010_Load_LOBStage

You should schedule the ETL to run daily during off-hours.


17.3.5 Changing the source ETL status to ProductionThe GTM_c05_LOBState_Process consists of process steps with the Development status set as the default. In order for them to run, their status must be changed from Development to Production. On the Tivoli Enterprise Data Warehouse Control Center server, using the Data Warehouse Center window, select the processes for GTM_c05_LOBState_Process and right-click them. Select Mode -> Production, as shown in Figure 17-20.

Figure 17-20 Promoting scheduled processes to Production status


17.3.6 Running ETLsThe ETLs were scheduled to run at a given time in “Scheduling the source ETL” on page 548. If you want to run the ETL manually, follow these steps:

1. From the data warehouse center, select Warehouse -> Work In Progress. This will open the Work in Progress window, as shown in Figure 17-21. The figure shows all scheduled processes, with the IBM Tivoli Business Systems Manager processes highlighted. You may also see some other items with the status of either Successful, Failed, or In progress.

Figure 17-21 Work in Progress window

2. Right-click the process that you want to run and select Run now. The steps within the process will be run sequentially, based on the dependency in the process.

The resulting data from the ETL programs is stored in the TWH_CDW database because IBM Tivoli Business Systems Manager does not provide an ETL2 process.


Part 5 Appendixes

The following additional material is included:

� Appendix A, “Detailed process flow of services” on page 555

� Appendix B, “Sample files and scripts” on page 557

� Appendix C, “IBM Tivoli NetView additional information” on page 565

� Appendix D, “Additional material” on page 577

Part 5


Appendix A. Detailed process flow of services

This appendix shows a diagram of the detailed process flow of IBM Tivoli Business Systems Manager services.

A


Figure A-1 Detailed services diagram

z/OS

Tivoli Framework

Microsoft SQLServer

Staged EventLoader

PropagationAgent Dispatcher

MVS IP Listener

Agent Listener

Common Listener

Remote ExecutionServer

Enqueue ProxyServer

Enqueue ProxyServer

MVS IP OSListener

MVS Sender

MVS EventHandler

Console ServerV2

DatabaseValidater

Event Enablement Task Server

TBSM Adapter(s)

Tivoli NetView

tgmtask.exe

pagent.exe

IBM TivoliMonitoring

Tivoli EnterpriseConsole

Object Server

Object Pump

Data space

Tivoli NetView forzOS

SystemAutomation


IMS

DB2

CICSPlexSystems Manager

CICS

RMF

MVSUpload.que

ROOT-0001.que

AgentListener.que


TBSMConsole


Appendix B. Sample files and scripts

This appendix contains sample files and scripts that are referenced in the book. These are:

� “The gemmfprod.sh script” on page 558 lists the gemmfprod.sh script for creating a mainframe object in IBM Tivoli Business Systems Manager using the agent listener interface

� “High-level load sample” on page 560 is the script for loading high-level objects into the IBM Tivoli Business Systems Manager database

B


The gemmfprod.sh script# TBSM 2.1 project - ITSO Austin # Redbook SG24-6610# Author: Budi Darmawan# Copied from gemgenprod.sh program in TBSM 2.1 distribution#function usage { ASIShellMsg ASIBldScripts 22 "$1" >&2}

server=""userid=""password=""manufacturer=""product=""version=""

while getopts xS:U:P:m:p:v: odo # print "processing: '-$o $OPTARG'" if [ $o = S ] then server=$OPTARG elif [ $o = U ] then userid=$OPTARG elif [ $o = P ] then password=$OPTARG elif [ $o = m ] then manufacturer="$OPTARG" elif [ $o = p ] then product="$OPTARG" elif [ $o = v ] then version="$OPTARG" if [ "X$version" != X ] then typeset -R1 version_c version_c="$version" if [ "X$version_c" = X. ] then version=${version%.} fi fi


elif [ $o = x ] then set -x else usage $0 exit 1 fidone

. gemargs.sh

if [ "X$server" = X -o "X$userid" = X -o "X$password" = X -o "X$manufacturer" = X -o "X$product" = X -o "X$version" = X ]then ASIShellMsg ASIBldScripts 20 "-S, -U, -P, -m, -p," "-v" >&2 usage $0 exit 1fi

shift $OPTIND-1

filebase=$(echo "${product}_${version}_$(date '+%Y''%m''%d_''%H''%M''%S')" | tr -dc '[a-z][A-Z][0-9]._')

cat > ${filebase}.sqi <<EOFinclude(GemObject.sqi)

DROP_CLASS_NO_META_REBUILD({gem_cid})

GM_OBJECT_CLASS({gem_cid}, {gem_cname}, '$product $version', '$product $version (generic events)', GMMF)

GEM_MATCH_TRIPLETS({gem_cid}, $manufacturer, $product, $version, , os390)

BEGIN_LINKS({gem_cid}) TARGET_LINK(PHYC, OS)END_LINKS({gem_cid})EOF

if ! sh bldgemsc.sh -S$server -U$userid -P$password -f${filebase}then ASIShellMsg ASIBldScripts 13 "bldgemsc" "generic product $product $version" >&2 exit 1fi

exit

Appendix B. Sample files and scripts 559

High-level load sample This appendix section provides sample high-level load for IBM Tivoli Business Systems Manager.

ASILoad_Highlevel.kshcreate_stored_proc(){ isql -S$db_server -U$db_user -P$db_password -w5000 -t120 -l120 -n <<- END use Object go set nocount on go print 'Creating procedure asisp_createHighLevelObjs' go if exists (select * from sysobjects where type='P' and name='asisp_createHighLevelObjs') drop procedure asisp_createHighLevelObjs go create procedure asisp_createHighLevelObjs @ent_name ObjName, @comp_name ObjName, @mach_name ObjName, @lpar_name ObjName, @os_name ObjName, @ent_descr varchar(255)='', @comp_descr varchar(255)='', @mach_descr varchar(255)='', @lpar_descr varchar(255)='', @os_descr varchar(255)='' as raiserror('asisp_createHighLevelObjs [%s], [%s], [%s], [%s], [%s]', 0, 1, @ent_name, @comp_name, @mach_name, @lpar_name, @os_name)

-- Standard transaction logic declare @tcount int select @tcount = @@trancount if @tcount = 0 begin tran asisp_createHighLevelObjs else save tran asisp_createHighLevelObjs

declare @ent_id ObjID declare @comp_id ObjID declare @mach_id ObjID declare @lpar_id ObjID declare @os_id ObjID


-- Create ENT select @ent_id=dst_id from ENT_C, link l where src_cid='BUSC' and src_id=1 and dst_cid='ENT' and link_type='PHYC' and l.deleted=0 and dst_id=id and name=@ent_name if @ent_id<>NULL raiserror('asisp_createHighLevelObjs: found existing ENT object [%s], obj_id=%d', 0, 1, @ent_name, @ent_id) else begin raiserror('asisp_createHighLevelObjs: creating ENT object [%s]', 0, 1, @ent_name) exec @ent_id=asisp_createENT @ent_name, BUSC, 1, @Desc=@ent_descr if @ent_id<0 begin raiserror('asisp_createHighLevelObjs: FAILED to create ENT object [%s]', 11, 1, @ent_name) rollback tran asisp_createHighLevelObjs return -30000 end end

-- Create COMP select @comp_id=dst_id from COMPLEX_C, link l where src_cid='ENT' and src_id=@ent_id and dst_cid='COMP' and link_type='PHYC' and l.deleted=0 and dst_id=id and name=@comp_name if @comp_id<>NULL raiserror('asisp_createHighLevelObjs: found existing COMP object [%s], obj_id=%d', 0, 1, @comp_name, @comp_id) else begin raiserror('asisp_createHighLevelObjs: creating COMP object [%s]', 0, 1, @comp_name) exec @comp_id=asisp_createCOMP @comp_name, ENT, @ent_id, @Desc=@comp_descr if @comp_id<0 begin raiserror('asisp_createHighLevelObjs: FAILED to create COMP object [%s]', 11, 1, @comp_name) rollback tran asisp_createHighLevelObjs return -30000 end end

-- Create MACH select @mach_id=dst_id from MACHINE_C, link l where src_cid='COMP' and src_id=@comp_id and dst_cid='MACH' and link_type='PHYC' and l.deleted=0 and dst_id=id and name=@mach_name if @mach_id<>NULL


raiserror('asisp_createHighLevelObjs: found existing MACH object [%s], obj_id=%d', 0, 1, @mach_name, @mach_id) else begin raiserror('asisp_createHighLevelObjs: creating MACH object [%s]', 0, 1, @mach_name) exec @mach_id=asisp_createMACH @mach_name, COMP, @comp_id, @Desc=@mach_descr if @mach_id<0 begin raiserror('asisp_createHighLevelObjs: FAILED to create MACH object [%s]', 11, 1, @mach_name) rollback tran asisp_createHighLevelObjs return -30000 end end

-- Create LPAR select @lpar_id=dst_id from LPAR_C, link l where src_cid='MACH' and src_id=@mach_id and dst_cid='LPAR' and link_type='PHYC' and l.deleted=0 and dst_id=id and name=@lpar_name if @lpar_id<>NULL raiserror('asisp_createHighLevelObjs: found existing LPAR object [%s], obj_id=%d', 0, 1, @lpar_name, @lpar_id) else begin raiserror('asisp_createHighLevelObjs: creating LPAR object [%s]', 0, 1, @lpar_name) exec @lpar_id=asisp_createLPAR @lpar_name, MACH, @mach_id, @Desc=@lpar_descr if @lpar_id<0 begin raiserror('asisp_createHighLevelObjs: FAILED to create LPAR object [%s]', 11, 1, @lpar_name) rollback tran asisp_createHighLevelObjs return -30000 end end

-- Create OS select @os_id=dst_id from OS_C, link l where src_cid='LPAR' and src_id=@lpar_id and dst_cid='OS' and link_type='PHYC' and l.deleted=0 and dst_id=id and name=@os_name if @os_id<>NULL raiserror('asisp_createHighLevelObjs: found existing OS object [%s], obj_id=%d', 0, 1, @os_name, @os_id) else begin


raiserror('asisp_createHighLevelObjs: creating OS object [%s]', 0, 1, @os_name) exec @os_id=asisp_createOS @os_name, LPAR, @lpar_id, @Desc=@os_descr if @os_id<0 begin raiserror('asisp_createHighLevelObjs: FAILED to create OS object [%s]', 11, 1, @os_name) rollback tran asisp_createHighLevelObjs return -30000 end end

-- Finish up transaction if @tcount = 0 commit tran asisp_createHighLevelObjs

return 0 go

END}

generate_sql(){ awk -F"\\" ' BEGIN { i=0; print "use Object" print "go" print "set nocount on" print "go" } NF>5 { ent_name=$1; ent_descr=$2; comp_name=$3; comp_descr=$4; mach_name=$5; mach_descr=$6; lpar_name=$7; lpar_descr=$8; os_name=$9; os_descr=$10;

printf("exec asisp_createHighLevelObjs \047%s\047, \047%s\047, \047%s\047, \047%s\047, \047%s\047, \047%s\047, \047%s\047, \047%s\047, \047%s\047, \047%s\047\n", $1, $3, $5, $7, $9, $2, $4, $6, $8, $10); if ((i++ % 5)==4) print "go" }


END { print "go" print "print \047Done.\047" print "go" } ' "$*"}

main() { # Get Database Server, User, Password from Registry eval `regdmp "HKEY_LOCAL_MACHINE\SOFTWARE\Accessible Software, Inc.\Access1\1.0\Settings\DB" | awk '/Server/ {printf("db_server=%s\n",$3);} /User/ {printf("db_user=%s\n",$3);} /Password/ {printf("db_password=%s\n",$3);}'`

# create the stored procedure used for the insert create_stored_proc

timestamp=`date +"%Y%m%d_%H%M%S"`; isql_input_file="$0"."$timestamp".sql.in isql_output_file="$0"."$timestamp".sql.out

# generate the SQL generate_sql "$*" > "$isql_input_file"

# apply the SQL echo 'Outputting SQL to: '"$isql_output_file"'...' isql -S$db_server -U$db_user -P$db_password -w5000 -t120 -l120 -n -i"$isql_input_file" -o"$isql_output_file"

# output the results cat "$isql_output_file"}

main "$*"

ITSO_Highlevel - Sample high-level load sourceMainframes/ITSO Enterprise/ITSO//SC64Machine//Primary//SC64/Mainframes/ITSO Enterprise/ITSO//SC66Machine//Primary//SC66/Mainframes/ITSO Enterprise/ITSO//SC69Machine//Primary//SC69/Mainframes/ITSO Enterprise/RETAIN-Test//9672-Y56//Primary//MVS1/


Appendix C. IBM Tivoli NetView additional information

This appendix contains additional information related to the IBM Tivoli NetView integration discussed in Chapter 9, “IBM Tivoli NetView integration” on page 279. The contents are:

� “NetView adapter configuration files” on page 566

� “TBSM adapter files” on page 571

� “Launch menu item add and delete script” on page 572

� “NetView Web Server script 3beansalad.js” on page 574

C


NetView adapter configuration filesThis appendix provides complete listings of the configuration files we customized for the IBM Tivoli Business Systems Manager with IBM Tivoli NetView integration. The listings are for reference only. You should always use the configuration files provided by the IBM Tivoli Business Systems Manager adapter distribution.

The nvid.conf fileThis file is located under /usr/OV/conf and contains information about the actual NetView servers that connect to IBM Tivoli Business Systems Manager. The listing is given in Example C-1.

Example: C-1 /usr/OV/conf/nvid.conf

## nvid.conf - NetView management site identification## Keywords in this file configure various identification elements# to interested parties for this network management site.## nvid= specifies a unique name for the site (maximum 15 chars).# networkid= specifies the network identifier obtained from TESM.# primaryURL= specifies the primary URL for access to this installation.# secondaryURL= specifies the secondary URL for access to this installation.# contact= specifies the name of the person responsible for this installation.# description= specifies some descriptive text about this installation.#nvid=TI7043TBSMnetworkid=NV0primaryURL=capecod.itsc.austin.ibm.com.ibm.com:8080secondaryURL=backupnetview.ibm.com:8080contact=Peter Glasmacherdescription=The coolest NetView on earth

The topxlistener.properties fileExample C-2 shows the content of topxlistener.properties, which lists the properties of the IBM Tivoli Business Systems Manager adapter.

Example: C-2 /usr/OV/topxlistener.properties

adapter.type = LocalAdapter

# ADAPTER WORKING DIRECTORY


# This is the directory where the Adapter will write its files# The default vaule is: adapter.working.dir = .# Both absolute and relative paths are allowed (take care of the path# separator '\\' for windows and '/' for unix)# Examples:# (win - absolute) D:\\Adapter\\driver5\\BaseInstrumentation\\WorkingDir# (win - relative) ..\\BaseInstrumentation\\WorkingDir# (unix - absolute) /Adapter/driver5/BaseInstrumentation/WorkingDir# (unix - relative) ../BaseInstrumentation/WorkingDir

adapter.working.dir = ../log

# REGISTER TIMEOUT# Timeout in seconds for the register message (default: 300)

adapter.register.timeout = 300

soap.envelope = <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">\n\t<SOAP-ENV:Body>

# LOGGING MODE PROPERTIES

loggingmode.default = falseloggingmode.filename = BaseClientLogging.log

# TRACE PROPERTIES:# The file for the trace output, the maximum file seze (in kilobytes) and the maximum# number of files used to store trace logs.

trace.filename = BaseClientTrace.log trace.max.file.dim = 10240 trace.max.files.number = 3

# This key is set "true" if the logger is enabled ("on") or "false" if# the logger is disabled ("off").

adapter.trace.enable = true transport.trace.enable = true

# This key can be low, medium or high:# low = errors, exceptions and warnings# medium = low plus info and object creation# high = methods entry/exit

Appendix C. IBM Tivoli NetView additional information 567

adapter.trace.level = medium transport.trace.level = medium

# VALIDATING PROPERTY:# This key is set "true" if the xml validation is enabled ("on")

adapter.xml.validation = false

# transport base properties

transport.class.name = com.tivoli.commonlistener.transport.mqe.client.ClientTransportMQe

#transport.local.ip.address = localhost#transport.request.address = localhost.BASETEST.QM+BASETEST.Q#transport.request.port = 9898#transport.response.address = localhost.BASETEST.QM+BASETEST.Q#transport.response.port = 9898

transport.local.ip.address = capecod.itsc.austin.ibm.comtransport.request.address = capecod.itsc.austin.ibm.com.BASETEST.QM+BASETEST.Qtransport.request.port = 9898transport.response.address = capecod.itsc.austin.ibm.com.BASETEST.QM+BASETEST.Qtransport.response.port = 9898

# MQe transport properties

# queue store: this key can be file or memory or reducedtransport.mqe.local.queue.store = filetransport.mqe.remote.queue.store = file

# If this key is "true" a filler field will be added in the MQe message whose dimension# is less than 1387 bytes of data. If the message body is greater than 1387# bytes, no filler will be added.# Suggestion: use "true" only on Windows NT 4.0 + ServicePack 5transport.mqe.usefiller = false

transport.mqe.fileregistry = com.ibm.mqe.registry.MQeFileSessiontransport.mqe.maxchannels = 1

# Time interval for the triggering thread. (Default = 10) transport.mqe.triggering.interval = 10

# only for client # server transport.server.mqe.address = ServerQM+ServerQ


transport.server.mqe.port = 8082 transport.server.ip.address = ibmtiv3.itsc.austin.ibm.com

# proxy #transport.proxy.mqe.address = localProxyQM+ProxyQ #transport.proxy.mqe.port = 8083 #transport.proxy.ip.address = localhost

The topxtrapgate.confExample C-3 shows the content of topxgate.conf, which provides event filtering before forwarding snmp traps to IBM Tivoli Business Systems Manager.

Example: C-3 /osr/OV/conf/topxgate.conf

## topxtrapgate.conf - Provides snmp trap to TBSM event filtering## Comments start with a pound-sign (#) in the fist column.## Each line consists of an integer trap number followed by a short text# description. Only the first integer per line will be accepted.#50790400 Node Marginal50790401 Segment Normal50790402 Segment Marginal50790403 Network Normal50790404 Network Marginal50790405 Segment Added50790406 Segment Deleted50790407 Network Added50790408 Network Deleted50790416 Manage Network50790417 Unmanage Network50790418 Manage Node50790419 Unmanage Node50790420 Manage Segment50790421 Unmanage Segment50790441 Manage Interface50790442 Unmanage Interface50790450 NT- Acknowledge Event for Client/Server50790451 Unix Unacknowledge Event58720263 SNMP data collection exceeded58720264 SNMP data collection rearmed58785792 Interface Added58785793 Interface Deleted58785794 Node Added58785795 Node Deleted


58785796 HSRP interface added58785797 HSRP interface Deleted58916864 Node Up58916865 Node Down58916866 Interface Up58916867 Interface Down58916868 Segment Critical58916869 Network Critical58916871 SNMP Status Events58916966 Interface USER1 status58916967 User 2 status58916968 Network is now unreachable58916969 Network is reachable again58916970 Router interface is UNREACHABLE58916971 Router is DOWN58916972 Router is Unreachable58916973 Router is UP58916974 Router is Marginal58916975 Service Up58916976 Service Down58916977 Service Marginal58916978 Service Acknowledge58916979 Service Unacknowledge58916982 ISDN backup line active58916983 ISDN backup line dormant58982400 Link Level Address Changed58982401 Mismatch of Link Level Address58982402 Undetermined Link Level Address58982403 Object Identifier Change58982404 System Descr Change58982405 System Name Change58982406 Subnet Mask Change58982407 Forwarding status change58982408 Forwarding to a host


TBSM adapter filesThis section lists the files and locations under AIX produced by the IBM Tivoli Business Systems Manager adapter installation process, as well as the file produced during operation of the adapter.

Files found under /usr/OV/bin:

� tbsmdriver: Executable file used by the bulk upload routine.

� tbsmtopo: Executable file registered to the NetView GUI or netviewd. Responsible for extracting data from the NetView databases, formatting the data as XML records, and sending them to tbsmadatper.

� tbsmbulkupload.ksh: Korn shell script called via the NetView GUI to initiate a bulk upload to IBM Tivoli Business Systems Manager.

� tbsmtrap: Executable file registered to the GUI or netviewd. Listens for traps and NetView events. For topology changes tbsmtrap generates IBM Tivoli Business Systems Manager events and triggers tbsmtopo to build delta or delete uploads to IBM Tivoli Business Systems Manager.

IBM Tivoli Business Systems Manager registration files:

� /usr/OV/lrf/tbsmadapter.lrf: NetView registration file used to register the IBM Tivoli Business Systems Manager adapter to the NetView control process.

� /usr/OV/newconfig/tbsm/tbsmadapter.lrf: Backup of the IBM Tivoli Business Systems Manager adapter registration file.

Files found under /usr/OV/registration/C:

� tbsmtopo.reg: Application registration file used to register tbsmtopo to the NetView GUI. Causes tbsmtopo to be launched upon start of the NetView GUI or netviewd.

� tbsmtrap.reg: Application registration file used to register tbsmtrap to the NetView GUI. Causes tbsmtrap to be launched upon start of the NetView GUI or netviewd.

IBM Tivoli Business Systems Manager adapter class under /usr/OV/jars:

� tbsma.class: The compiled Java code implementing the IBM Tivoli Business Systems Manager adapter.

Files found under /usr/OV/log:

� tbsma.log: Log file that contains logs from the local adapter transport code, tbsmadapter.

� tbsmatopo.log: Logfile for the tbsmtopo process.


� tbsmatrap.log: Logfile for the tbsmtrap process.

� tbsmatrace.trigger: Trace trigger. The creation or existence of this file causes tbsmtopo to produce trace information and write it to /usr/OV/log/tbsmatrace.log

� tbsmatrace.log: Trace file that contains trace information from tbsmtopo.

Launch menu item add and delete scriptThe script listed in Example C-4 can be used and modified to add or delete items in the Launch Submenu. In the ADD section of the script, for each physical resource you want the menu to display you must provide an:

� AddAppLauncherEntry.sh definition for each supported operating system, such as UNIX, WIndows 2000, or WindowsNT

� AddAppLauncherMenuItem.sh for each physical resource you want included in the new submenu

Also, to provide the functions to delete the entries on demand, you must add a:

� DeleteAppLauncherMenuItem.sh entry to delete the corresponding menu item you created

� DeleteAppLauncherEntry.sh for each added operating system line

A script that inserts the standard launch entries for all NetView-related menu items, nvlaunchconfig.sh, can be found on your database sever under \TivoliManager\bin>. All scripts called from nvlaunchconfig.sh also reside under \TivoliManager\bin. They provide a usage message and an explanation of all required parameters when you enter the name of the script without parameters.

Example: C-4 Adding/Deleting launch menu entries

#!/bin/ksh## nvlaunchconfig.sh# # This file can be used to configure TBSM with NetView Distributed Launch menus.# Replace the 3 XXXXX strings below with the appropriate values.# ####################################################################################

# Replace XXXXX with the name of the TBSM database serverSQLSERVER=ibmtiv5# Replace XXXXX with the name of the SQL Server user accountSQLUSER=sa# Replace XXXXX with the password for the SQL Server user account


SQLPWD=sa_ibmtiv5

## Add launch entries#add_entries(){ # # WIndows NT entry # AddAppLauncherEntry.sh -S $SQLSERVER -U$SQLUSER -P$SQLPWD -nNVsumR \

-l"Windows NT" -cSockets -m8899 -x8899 -w5000 -r18 \-g"cmd /c %NVWC_HOME%\bin\nvlaunch.bat port 8899 > nvlaunch.log 2>&1" \-a"serverinfo=%nvserver% scripturl=/netview/scripts/TBSMsummary.js sctargetnode=%name%

tbsm=true"## WIndows 2000 Entry#AddAppLauncherEntry.sh -S $SQLSERVER -U$SQLUSER -P$SQLPWD -nNVsumR \

-l"Windows 2000" -cSockets -m8899 -x8899 -w5000 -r18 \-g"cmd /c %NVWC_HOME%\bin\nvlaunch.bat port 8899 > nvlaunch.log 2>&1" \-a"serverinfo=%nvserver% scripturl=/netview/scripts/TBSMsummary.js sctargetnode=%name%

tbsm=true"## Menu item entry#AddAppLauncherMenuItem.sh -S $SQLSERVER -U$SQLUSER -P$SQLPWD -nNVsumR \

-cROUT -l"NetView Overview" -r"NVsumR,name=%IPHostName%,nvserver=%this.LookupNetviewURLs%"## Delete Launch entriesdelete_entries(){ # # Delete Web Console Entries #

DeleteAppLauncherMenuItem.sh -S $SQLSERVER -U$SQLUSER -P$SQLPWD -nNVsumR -r DeleteAppLauncherEntry.sh -S $SQLSERVER -U$SQLUSER -P$SQLPWD -nNVsumR -l"Windows NT" DeleteAppLauncherEntry.sh -S $SQLSERVER -U$SQLUSER -P$SQLPWD -nNVsumR -l"Windows 2000"

if [ "$1" == "add" ] ; then add_entrieselif [ "$1" == "delete" ] ; then delete_entrieselse echo "Usage: nvlaunchconfig.sh add|delete"fi


NetView Web Server script 3beansalad.jsThe file 3beansalad.js runs under control of the NetView Web Server. It uses a single call to launch the Web console and can be used to display:

� A submapexplorer pane� A diagnostics pane� An object properties pane

We used this file as a base for the TBSM Java console menu extension discussed in 9.7.2, “Extending the TBSM Java console” on page 319. Example C-5 shows the file for reference.

Example: C-5 The 3beansalad.js file

var diag = new Packages.com.tivoli.netview.diagnostics.client.Diagnostics();diag.setProtocol(protocol);diag.setHostName(hostname);diag.setPort(port);diag.performTest("Test", "Ping", targetnode);framefactory.addFrame(diag, "Diagnostics", "anm_wc_win_diagnostics");

var objprop = new Packages.com.tivoli.netview.objectproperties.client.ObjectProperties();objprop.setProtocol(protocol);objprop.setHostName(hostname);objprop.setPort(port);objprop.resetTargetNode(targetnode);framefactory.addFrame(objprop, "Object Properties", "anm_wc_win_objprops");

var mapconn = new Packages.com.tivoli.netview.mapconnector.client.MapConnector(protocol, hostname, port);if (!mapconn.isOkToSkipOpenMapDialog()) { /* * Either: * + MapConnector properties do not allow skipping the dialog * + There is more than one open map * + The open map is not the default map */ var dialog = mapconn.createDialog(null); dialog.setVisible(true); /* * To get here user must have either 1. Selected a map and clicked the Open button, or * 2. Clicked the Cancel button */}/* port will be zero if user clicked Cancel button */var mapport = mapconn.getMapServerPort();var mapname = mapconn.getMapName();if (0 != mapport) {


var subexp = new Packages.com.tivoli.netview.maptree.client.submapexplorer.SubmapExplorer(); subexp.setProtocol(protocol); subexp.setHostName(hostname); subexp.setPort(port); subexp.setMapPort(mapport); subexp.setMapName(mapname); subexp.setTargetNode(targetnode); subexp.activate(); framefactory.addFrame(subexp, "Submap Explorer", "anm_wc_win_subexplorer");}Packages.com.tivoli.netview.client.global.NetView.bringToForeground();


Appendix D. Additional material

This appendix refers to additional material from the redbook that can be downloaded from the Internet.

Locating the Web materialThe Web material associated with this book is available in softcopy on the Internet from the IBM Redbooks Web server. Point your Web browser to:

ftp://www.redbooks.ibm.com/redbooks/SG246610

Alternatively, you can go to the IBM Redbooks Web site at:

http://www.ibm.com/redbooks

Select Additional materials in the navigation bar, and open the directory that corresponds with the redbook form number, SG246610.

Using the Web materialThe additional Web material includes the following files:

ABSJava.zip Zipped Java classes for running the ABS configuration file utility

D






SG246610.readme Readme file for using the ABSJava.zip (similar to this appendix)

System requirements for downloading the Web materialThe following system configuration is recommended:

Hard disk space: 220 kb free spacePrerequisite software: Java Runtime Environment (JRE) v1.3

How to use the Web materialPerform the following steps to use the sample program:

1. Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder. Be sure that java.exe is in the path by running the command java -version. It should show Version 1.3, at least.

2. Run the command absAllowedClassAttribute.ksh -oclassattr.txt from your IBM Tivoli Business Systems Manager database server. Copy the classattr.txt file to the workstation folder you created in step 1.

3. Run the abs.bat file.

For more information about using this tool, refer to 12.2.2, “BSV creation tool” on page 407.


acronyms

ABS Automatic Business System View

ACF Advanced Communication Functions

AIX Advanced Interactive Executive

AMI Application Management Interface

AMS Application Management Specification

ANSI America National Standard Institute

APAR Authorized Program Analysis Report

APF Authorized Programming Facility

API Application Prorgramming Interface

APM Application policy Management

APPC Advanced Program to Program Communication

APPN Advanced Peer-to-peer Networking

ASCII American Standard Code for Information Interchange

BCP Bulk Copy Program

BMP Bitmap

BSM Business Systems Manager

BSV Business System View

CD-ROM Compact Disc - Read-Only Memory

CDW Central Data Warehouse

CICS Customer Information Control Systems

CID Class IDentifier

Abbreviations and

© Copyright IBM Corp. 2003. All rights reserved.

CIM Common Information Management

CLI Command Line Interface

CMIP Common Management Information Protocol

CPSM CICSPlex Systems Manager

CPU Central Processing Unit

CST Central Standard Time

CWM Common Warehouse Model

DASD Direct Access Storage Device

DB2 Database 2

DB2PM Database 2 Performance Monitor

DBCTL Database Control

DBRC Database Recovery Control

DDS Distributed Data Services

DFSMS Data Facility Systems Managed Storage

DNS Domain Name Services

EBCDIC Extended Binary Coded Decimal Information Code

EDI External Data Interface

EIF Event Integration Facility

EMCS Extended Multi Console Service

EOF End-of-file

ETL Extract transform load

FTP File Transfer Program

GB Gigabyte

GEM Tivoli Global Enterprise Manager

GMFHS Graphics Monitoring Facility Host Subsystems

GMT Greenwich Mean Time

579

GUI Graphical User Interface

HLQ High-Level Qualifier

HMS Health Monitoring Server

HSM Hierarchical Storage Manager

HTML Hypertext Markup Language

HTTP Hypertext Transport Protocol

HTTPD HTTP Daemon

IBM International Business Machine Corporation

ICMP Internet Control Message Protocol

IIS Internet Information Server

IMS Information Management System

IMSAO IMS Automated Operator

IPL Initial Program Load

ISO International Standard Organization

ISPF Interactive System Productivity Facility

ITM IBM Tivoli Monitoring

ITSO International Technical Support Organization

JAR Java archive

JCL Job Control Language

JDBC Java Database Connectivity

JES Job Entry Subsystems

JRE Java Runtime Environment

JRIM Java RDBMS Interface Module

JVM Java Virtual Machine

KB Kilobyte

LAN Local Area Network

LOB Line of Business

LPAR Logical Partition

LRECL Logical Record Length

MB Megabyte

MCS Multiple Console Support

MIB Management Information Base

MKS Mortice Kern Software

MPF Message Processing Facility

MRM MAS Resource Monitoring

MSDTC Microsoft Distributed Transaction Coordinator

MVS Multiple Virtual Storage

NTFS NT filesystems

ODBC Open Database Connectivity

OLAP Online analytical processing

OLDS Online log data set

OPC Operation Planning and Control

OSA Open System Adapter

OTMA Open Transaction Manager Access

PDF Portable Document Format

PDS Partitioned Data set

PID Process ID

PMF Panel Management Facility

PPI Program to program interface

PTF Program Temporary Fix

RACF Resource Access Control Facility

RDBMS Relational database management systems

RFC Request for Comment

RFT Report Format Table

RMF Resource Measurement Facility

RODM Resource Object Data Manager

SMF System Measurement Facility

SMP/E Systems Modification Program/Extended

SMS Systems Managed Storage


SNA Systems Network Architecture

SNMP Simple Network Management Protocol

SOAP Simple Object Access Protocol

SQL Structured Query Language

STC Started Task

TBSM IBM Tivoli Business Systems Manager

TCP/IP Transmission Control Protocol/Internet Protocol

TEC IBM Tivoli Enterprise Console

TEDW Tivoli Enterprise Data Warehouse

TMR Tivoli Management Region

TSD Tivoli Service Desk

TSO Time Sharing Option

TSP Terminal Simulator Program

TWS Tivoli Workload Scheduler

URL Universal Resource Locator

USS UNIX System Services

VSAM Virtual Storage Access Method

VTAM Virtual Telecommuncations Access Method

WMI Windows Management Instrumentation

WTO Write to Operator

XCF cross-system coupling facility

XML Extensible Markup Language

XRC Extended Recovery Control

Abbreviations and acronyms 581

Related publications

The publications listed in this section are considered particularly relevant to a more-detailed discussion of the topics covered in this book.

IBM RedbooksFor information about ordering these publications, see “How to get IBM Redbooks” on page 584.

� Tivoli Business Systems Manager A Complete End-to-End Management Solution, SG24-6202

� Tivoli Business Systems Manager An Implementation Case Study, SG24-6032

� Instrumenting Enterprise Applications using Tivoli GEM, SG24-5399

� Introduction to Tivoli Enterprise Data Warehouse, SG24-6607

� IBM Tivoli Monitoring Version 5.1: Advanced Resource Monitoring, SG24-5519

� IBM Tivoli Monitoring for Databases Database Management Made Simple, SG24-6613

� Tivoli NetView 6.01 and Friends, SG24-6019

Other resourcesThese publications are also relevant as further information sources:

� NetView for UNIX,User’s Guide for Beginners, SC31-8891

� NetView for UNIX, Administrators Guide, SC31-8892

� NetView for UNIX, Administrators Reference, SC31-8893

� NetView, Web Console User’s Guide, SC31-8900

� NetView 7.1.3 Release Notes, GI11-0927

� Tivoli Distributed Monitoring Version 3.7 Users Guide, GC31-8382

� Tivoli Information Management for z/OS Program Administration Guide and Reference, SC31-8753


Referenced Web sitesThese Web sites are also relevant as further information sources:

� List DLL vendor web site:

http://www.sysinternals.com

� SOAP XML organization’s template URLs:

http://schemas.xmlsoap.org/soap/envelopehttp://schemas.xmlsoap.org/soap/encoding

� Microsoft SQL Server download site:


� IBM Tivoli product support page:

http://www-3.ibm.com/software/sysmgmt/products/support

� Object Management Group page:

http://www.omg.org

� IBM DB2 support page:

http://www-3.ibm.com/software/data/support/

How to get IBM RedbooksYou can search for, view, download, and order hardcopy Redbooks at:

ibm.com/redbooks

You can also download additional materials, such as code samples or diskette and CD-ROM images, from that site.

IBM Redbooks collectionsRedbooks are also available on CD-ROM. Click Redbooks on CD in the Redbooks Web site’s navigation bar for information about available CD-ROMs, as well as updates and formats.

584 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management584 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management

http://schemas.xmlsoap.org/soap/encoding




http://www.sysinternals.com

http://schemas.xmlsoap.org/soap/envelope


http://www-3.ibm.com/software/sysmgmt/products/support

http://www.omg.org

http://www-3.ibm.com/software/data/support/

Index

Numerics1.1-TDW-0002 5341.1-TDW-0005E 5341.1-TDW-FP01a 5343beansalad.js 322, 574

AABS

configuration file 397ABS Creation Process job 397ABS Discovery Process job 397ABS Table Purge job 397absAllowedClassAttribute 402, 407, 578absconfig.ksh 405, 418ABSMain 408absTest.ksh 406ACC1RCV 58ACC1RECV 59Access1 40Accessible Software, Inc. 40, 427ACF REFRESH 351action type field 60Actions.xml 312Active Server Page, see ASPACTNDEF 365AddAppLauncherEntry.sh 101AddAppLauncherMenuItem.sh 101addLOB.sh 414addpvToLOB.sh 414addpvToLOBInst.sh 414AF/Operator 28Agent Listener 37, 46agent listener logfile 246aggregation 250AIX commands

netstat 298smit 284

alert state 88alert state attribute 88All Resources 116alobListCriteriaAlob table 397alobListPattern table 397AMI 50

© Copyright IBM Corp. 2003. All rights reserved.

AMS 47AMS definition

Application 48Business Component 48Business Mapping 48Business Subsystem 48Business System 48Software Component 48

AMS object types 91AOPEDI 374AOPNOTF 377APF authorized 333APM Heartbeat 49Application Management Instrumentation 50Application Management Interface, see AMIApplication Management Specification 47Application Policy Management 47, 134, 224Application Registration Files 312Application Server 34ApplyUpgrade 517ASIAgentListenerSvc 37AsiCleanDir 443ASICommonListener 38ASIConsoleServerV2 34ASIDBValidater 31–32ASIEnqueueProxyServer 34, 59ASIEventEnablement 33ASIHealthMonitor 37ASILoad_Highlevel.ksh 560ASIMVSEventHandlerSvc 36, 59ASIMVSIPListener

registry setting 65ASIMVSIPListenerSvc 33, 65

ValidClients 66ASIMVSIPOSListener 35ASIMVSIPOSListenerSvc 58ASIMVSIPSenderSvc 37, 59ASIMVSListenerSvc 36, 58ASIMVSSenderSvc 37, 59, 61ASIMVSUploadRuleSvc 36, 59, 61ASIPADispatcher 32ASIPAgent.exe 35ASIRemoteExecutionServer 34ASIRuleSvc database 36, 80

585

asisp_logcleanup 442ASIStagedEventLoader 32ASITaskServer 33ASITSDEventHandlerSvc 33ASP 71AttachDatabases.sql 189Authentication mode 165authority 116AUTOAMI 362auto-discovery 9AUTOLOGN 342Automated Business System, see ABSautomatic logon mechanism 431AUTOTASK 68, 341autotrace 39

Bbackslash character 60baroc 135base services 26BCP 352BCP approach 69bcp command 69BCP transfer 195BLG1A111 477, 483BLGTSPPU 481BMC Mainview 27BMC Patrol 27book content 20Brio Technology 528BSV design 139BSV planning 139BSV structure 139

grouped resources 144inverted hierarchy 143no hierarchy 141original hierarchy 142

Bulk Copy Program, see BCPbulk discovery 51, 62BULK INSERT 67bulk object discovery

high-level load 63business impact management 4business impact views 17business intelligence reporting 531Business Objects 528business system 8Business System Container 85

business system containment link 83Business System View 10–11, 130business systems management 4

CCA TNG 27Candle AF/Operator 28Candle Omegamon II 27cdesc 82CDW 530central data warehouse, see CDWchild 89child event 89child event matrix 89CICS 54CICS® Transaction Server 27CICSPlex resource 369CICSPlex System Manager, see CPSMcid 82CIM 250CL_AutoPlacement table 81, 96, 263CL_LinkRules table 81CL_Options table 81CL_Registration table 81, 95CL_RegistrationList table 82CL_Severities table 82, 97CL_Stage table 82CL_StageBulkData table 82, 96CL_StageDeltaData table 82, 96CL_StageEvData table 82, 96CL_Status table 82, 275clsql 110, 375CMIP 376cname 82CNMSCAT2 339CNMSTYLE 362cno 82Cognos 528command security 433commands

bcp 69clsql 110CreateDiscoveryBatch 67dequeue 34dumpfqueue 34gemeeconfig 37, 225gemgenprod 50gmdmmap 49


isql 79ping 515rkill 515SC 515SCLIST 515tgmtask 33, 68, 102wbkupdb 211winstall 33wlookup 135wlsinst 135wlsinstl 23wruntask 211wtdumprl 233wtdumptr 233

Common Information Model, see CIMcommon listener 38, 51, 95, 134

bulk discovery 51delta discovery 51event information 51transaction ID 273

Common Management Information Protocol, see CMIPCommon Warehouse Metadata 528CommonListener log 271components 26, 152configuration 150configuration file 397Connection Properties 176connectivity 133console server 28, 31, 33–34, 39, 44

installation 190containment hierarchy 84–86context menu 97correlation 250, 528CPSM 361CPSM commands

ACTNDEF 365RTASPEC 363

CreateDiscoveryBatch 64, 67Crystal Decisions 528CWM standard 528

Ddata mart 531data mining 531data space 54data warehouse 530Database 2, see DB2

database engine 152database maintanance jobs 440Database Maintanance Plan 448database server 28

installation 176Database Validater 32dataspace 334DB2 54DB2 Performance Monitor 27, 353DB2_send_to_TBSM.sh 228DBCC CHECKDB 445debug mode 118DefaultData database 198DEFLOGS 335DeleteAppLauncherMenuEntry.sh 102DeleteAppLauncherMenuItem.sh 101dequeue 34detachhistorydatabases.sql 195DFSMS 54DFSMShsm 388DFSYINIT 360DFSYSVI0 360directory alias 70directory structure 39discovery processing 9discovery tasks 229DISPPI 340distributed environment 45distributed resources feeds 26distributed resources jobs 440Distributed systems 134dm.trc 276dmml directory 276document organization 20document_print 434domain trust 516download page 288DSICMD 339DSICTMOD 341DSIOPF 339DSIPARM 339DSISVRT 341DSITBL01 339DSPURX00 360DUIFPMEM 340DUIIGHB 340dumpfqueue 34dynamic_object_create_path table 397dynamic_object_create_path_detail table 397

Index 587

EECC_TBSM_Discovery 228EDI 350EKGNotify method 55enabling Reporting system 198end-to-end view 528Enqueue Proxy Server 34Enterprise Manager 79EQQUX007 373ETL programs 530event 10Event Automation Services 50Event Enablement 33event enablement exits

ihstctec 49ihstetec 49ihstmtec 49ihststec 49ihstttec 50, 227ihstztec 50, 225

event handler server 28event propagation 12Event Server 59event type

child event 89exception 89message 89state 89

event types 10event views 18exception matrix 88EXCMD 339exhaustive discovery 62Extend Daily Plan job 372extended markup language, see XMLextended recovery 54

Ffailover 514failover system 150Failover.upg 517FAT filesystem 422files and directories

permission 422Filtering 11flags 100fo_chk_connectivity 525fo_cmd_execute.ksh 522

fo_commonlistener.ksh 522fo_config 518, 520fo_logship 520format type field 60Future administrators 131

GGEM_DMtoCID table 81GEM_DMtoID 94GEM_IDlookup 94GEM_InstFiltering column 416GEM_InstFiltering table 415–416GEM_LookupCID table 81GEM_Options table 418gemdmmap.sh 49, 236gemeeconfig 37, 225, 246gemgenprod.sh 50, 230GEMIDLookup table 81gemimageimport.sh 232, 236GEMLookupCID 94gemmfprod.sh 50, 558GMFHS 376GPMSERVE 381GTM 532GTM_c05_LOBState_Process 548–549GTM_DB 541GTM_TWH_CDW_Target 547GTM1620I 56GTM1770I 56GTM1780I 56GTM4041I 55GTM5010I 55GTM6BSME 478GTM7406I 55GTM7424I 55GTM7815I 377GTM8205I 55GTM8252I 55GTMAOPE0 33, 64, 337GTMDSPC 334GTMPUMP 336GTMSAM16 379GTMSDPRM 476GTMSRVR 335GTMTBSMU 478GTMWSBD 391


Hhardware configuration 150hardware specifications 132health monitor 74Health Monitor Client 199Health Monitor Server 29, 37, 199heap size 539high level load 62high-level objects 63historical data 528history server 28, 68

BCP approach 69installation 194Linked Server approach 68

HistoryServerSetup.ksh 197histUsers table 433HKEY_LOCAL_MACHINE 40, 427HMS 150HMSQueries.ksh 37, 74, 202host integration server 28host name 528HTTP server 391hyperview 15

IIBM Object REXX 152IBM System Automation for OS/390 27IBM Tivoli Business Systems Manager

base services 26components 26Web console 20

IBM Tivoli Business Systems Manager, see TBSMIBM Tivoli Enterprise Console 7, 26IBM Tivoli Monitoring 7, 24, 27, 51, 249–250IBM Tivoli Monitoring for Databases 226IBM Tivoli NetView 26, 51, 280IBM Tivoli Operations, Planning, and Control 27IBM Tivoli Storage Management Systems 27IBM Tivoli Workload Scheduler 26IBM Tivoli Workload Scheduler for z/OS 27IBMConsole 121IEA630I 56IEAAPFxx 333IHS$CAT2 339, 351IHS$CMD 339IHS$MAT 339, 351IHS$OPF 339, 351IHS$PARM 337

IHSBCMD 354IHSBMAT 354IHSBOPR 354IHSBTBND 355–356IHSCCRUN 370IHSCMAT1 362ihscts 213IHSIAO0J 359IHSIAOE0 359IHSIAOEC 359IHSIAOEE 359IHSIAOML 359IHSICMD 358IHSIMAT 358IHSIMOPR 358IHSSBCPJ 351IHSSDISC 351IHSSINIT 350IHSSMAT 350IHSSOBSX 350IHSSSTRT 350ihstctec 49ihstdmai 213ihstdmon.rls 211ihstetec 49ihstmtec 49ihststec 49ihsttec.sh 218ihstttec 227ihstztec 50, 225ihszfmt 246immediate notification 477implementation 149Implementation team 131Implementation type 132IMS 54IMS Automated Operator 359IMS Control Region 360Information Management System, see IMSinheritance hierarchy 85Input providers 131Install.ksh 292installation 154

console server 190database server 176history server 194propagation server 190Windows 2000 Server 154

interapp.rls 211

Index 589

IP address 528IRXANCHR 337isa_chain table 97, 99isa_chain_table table 81isa_table table 81isql 79isqlw 79ITM discovery tasks 229ITM TEC setup task 229

JJava console 114Java Database Connectivity 152JDBC driver 192JRE 47jre130.image 252

LLandmark TMON 27launch_securityconsole 316line of business 9link_chain table 81link_type table 81Linked Server approach 68LOB class 84LOB Container 85LOB link

business system link 83LOB, see line of businessLOBC link 83log datasets 335log files 43Log Shipping 514log_ship_status 520logging level 44LogHeading 45logical partitions 136LogLevel 44Logs directory 40Logs$ share 40low-level objects 63LPAR 136LU 6.2 session 55

Mmainframe component 53mainframe data sources 349

mainframe resources feeds 27MakeMVSComponent.ksh 344Management Information Base, see MIBmaps 135MAS resource monitoring 367master database 78MasterDBChanges.sql 189MCS console 54, 56MenuItem table 97, 433

Flags 100security values 434

message queue file 59Meta database 80metadata interchange 528method_table table 81Mgmt directory 40MIB 282Microsoft Distributed Transaction Coordinator, see MSDTCMicrosoft Internet Information Server 152Microsoft SQL Server 78

tuning 462Microsoft SQL server

sa password 432Microsoft SQL Server Enterprise Manager 79migrateToAbs.ksh 416MKS Toolkit 152model database 78MONITOR command 56MonitoredQueueTable table 208msdb database 78, 438msdb..log_ship_status 520MSDTC 78MVS 339MVS Display Active 102MVS Event Handler 36MVS IP Listener 33, 379, 438MVS IP OS Listener 35MVS IP Sender 37MVS Listener 36MVS Sender Svc 37MVS Upload Rule Server 36MVSIPListener 352

NNETCONV connection 340NETCONV session 33, 68NetIQ AppManager 27


netstat 298NETVAOP 54, 340NetView

Bulk Upload 296NetView commands

launch_securityconsole 316nvsetup 285nvstat 295, 306ovaddobj 285ovstart 305ovstatus 295, 306ovstop 306

NetView Console 304NetView Diagnostics 304NetView for z/OS commands

DISPPI 340EXCMD 339MVS 339

NetView Object Properties 304NetView Web Console 282

launching 303netviewd 310Network discovery 280networking infrastructure 133Northwind database 78NTFS filesystem 422number of machines 132nvid.conf 293, 566nvlaunchconfig.sh 293nvsetup 285nvstat 295, 306nvwcinstal.exe 288

Oobj_class table 81obj_link_table table 81Object database 532object hierarchy

GEM 91Object Management Group 528object population

download 64object priority 88object properties 117object pump 54

installation 336object registration 60–61object server 54

installation 335ObjectEvents database 32, 80ObjectQueues database 80Objects database 80ObjectSync table 36ODBC 539–540OGET 392OLAP

analysis 531Omegamon II 55OPC_Appl_Definition 375OPC_Class_Definition 375OPCLoad database 80OPCParseDailyPlan.ksh 372open interface 528Open Transaction Manager Access, see OTMAoperating system 152OPERCMDS 338OTMA 360ovaddobj 285ovstart 305ovstatus 295, 306ovstop 306Ownership 10

PPARMSRIP 335password

reporting system 433Passwords 430performance

CPU 458performance and availability portfolio 6performance tuning 458permission 422

directories 422files 422registry 428

PHYC link 83physical containment link 83ping 515PMF 481, 485PPI 339, 350PPI receiver 54pre-discovery 9primary site 514PrimaryData database 198problem management

Index 591

closure 511problem ticket 466, 469

TBSM operation 470program to program interface, see PPIPROGxx 333propagation 11–12Propagation agent 35Propagation Agent Dispatcher 32propagation matrix 88propagation server 28

installation 190properties 117

QQuality Assurance 150queue files 34, 60

SC66.que 59SC66-Upload.que 59

Rraw data 528RDBMS 529RDM_LAUNCHER table 308recentfile_view 434Redbooks Web site

Contact us xxviiirediscovery 9REGEDT32 202REGION size 341Remote Execution 34Report Interface, see RIreporting system 70

directory alias 70Resource Measurement Facility, see RMFresource models 250Resource Monitoring Facility, see RMFResource Object Data Manager, see RODMResource type window 116reverse failover 514RI 531rkill 515RMF 55, 381RMF Distributed Data Server 381RMFGAT 382RMFProfile table 382RMFProfileDef table 382RMFProfileObjReln table 382RODM 55

RODM database 80RODMLoad database 80roles 34, 125, 131, 287, 316root cause analysis 281ROOT object 85RTASPEC 363

Ssa 432

registry keys 432SA390DISCOVERY 353SC 515SchemaMessages.sql 189SchemaTypes.sql 189SCLIST 515secondary site 514security 421security column 433securityconsole.log 317Send to TBSM 265Server.properties 155servers

wintel 150SETPROG 333Simple Network Management Protocol, see SNMPSimple Object Access Protocol 51smit 284SMP/E 332–333SMS 385SNA topology manager, see SNATMSNA/APPN Network object 377SNATM 376SNMP 280, 282SNMP management 280SOAP 51, 96software level 134software prerequisites 152Sort Order 166source ETL 534

running 552scheduling 548status 551

source site 514Source/390 54

data space 54object pump 54object server 54

SQL database 7


SQL Query Analyzer 79, 189SQL Query Profiler 79SQL Server Agent 78

database 438SRC 479SRVANY 37, 202Staged Event Loader 32state 88state attribute 88state changes 11status observer 350status propagation 87

alert state 88attributes 88object priority 88propagation matrix 88state 88

stored procedures 38, 82, 84, 95, 102, 446, 517stored response chain, see SRCSuper Administrator 116system administrator 432System Automation for OS/390 349System Automation/390 54System DSN 540System Managed Storage, see SMSSystem Modification Program Extended, see SMP/Esystems management 5

disciplines 5

Ttable view 16target ETLs

running 552target site 514Task monitor 116Task Server 33TBSM

class 91command support 97Java console 114object registration 60Web console 119

TBSM Adapter 255TBSM commands

absAllowedClassAttribute 402absconfig 405absTest 406addLOB 414

addpvToLOB 414addpvToLOBInst.sh 414ApplyUpgrade 517ASICleanDir 443clsql 375fo_chk_connectivity 525fo_cmd_execute 522fo_commonlistener 522fo_config 518, 520fo_logship 520gemeeconfig 246ihszfmt 246MakeMVSComponent 345migrateToAbs 416parser 47tgmtask 475

TBSM databasesASIRuleSvc 36, 80Meta 80ObjectEvents 32, 80ObjectQueues 80Objects 80OPCLoad 80RODM 80RODMLoad 80WebServer 80

TBSM directory structure 39TBSM log files 43TBSM reporting system 70TBSM servers

console server 28database server 28event server 28health monitor server 29history server 28, 68host integration server 28propagation server 28SNA server 28Web console server 28

TBSM servicesASIEnqueueProxyServer, see ASIEn-queueProxyServerASIMVSListenerSvc, see ASIMVSListenerSvcASIMVSSenderSvc, see ASIMVSSenderSvcASIMVSUploadRuleSvc, see ASIMVSUploa-dRuleSvc

TBSM setemsg event 211TBSM tables

dyn_obj_path 376

Index 593

dyn_obj_path_detail 376GEM_DMtoID 94GEM_EEHostToEnterprise 95GEM_HostnameToLocation 95GEM_IDlookup 94GEM_LocationToRegion 95GEMLookupCID 93isa_chain 97MenuItem 97opc_app_pattern 376

TBSM_for_TEDW.pdf 532TBSM_setemsg_status_event 241tbsma.jre_root 259tbsma.log 309tbsmadapter 305tbsmatopo.log 310tbsmatrace.log 311tbsmatrap.log 310tbsmbulkupload.ksh 297tbsmstatus.rls 211tbsmtopo 306, 309tbsmtrap 306TCP_SERVER_PORT 335TCPIP_ADDRESS_BACKUP 336TCPIP_PORT_BACKUP 336TDS directory 40TEC 209TEC setup tasks 229TEDW 527

configuration 529, 533TEDW Control Center 531tempdb database 78tempinstall 176test servers 150tgmtask 33, 47, 68, 102, 475

commandstgmtask 108

distributed 108tilde character 60Tivoli BSM Database Validater 32Tivoli BSM Enqueue Proxy Server, see ASIEn-queueProxyServerTivoli BSM Event enablement service 213Tivoli BSM MVS Event handler service, see ASIM-VSEventHandlerSvcTivoli BSM MVS IP Listener, see ASIMVSIPListen-erSvcTivoli BSM MVS IP OS Listener, see ASIMVSI-POSListener

Tivoli BSM MVS IP Sender service, see ASIMV-SIPSenderSvcTivoli BSM MVS Listener, see ASIMVSListenerSvcTivoli BSM MVS Sender service, see ASIMVSSend-erSvcTivoli BSM MVS Upload Rule Server, see ASIMV-SUploadRuleSvcTivoli BSM Task Server service 213Tivoli commands

wdmconfig 256, 259wdmdiscovery 251, 262wdmlseng 242, 266wdmmn 258wdmtrceng 269wlseng 242wtdumprl 242wtdumptr 243

Tivoli Distributed Monitoring 7, 27, 47Tivoli Enterprise Console 46, 134Tivoli Enterprise Data Warehouse 7, 530

data mart 530ETL processes 531ETL programs 530source applications 530warehouse packs 530

Tivoli Enterprise Data Warehouse, see TEDWTivoli Framework tasks 108Tivoli Global Enterprise Manager 7Tivoli Management Framework 23, 216Tivoli Management Region, see TMRTivoli NetView for OS/390 27Tivoli NetView for z/OS 33Tivoli Presentation Services 119Tivoli product 5Tivoli software Tivoli systems management 5Tivoli solution

Configuration and Operation 5Performance and Availability 5Security 5Storage Management 5

Tivoli Workload Scheduler 54Tivoli Workload Scheduler for z/OS, see TWS for z/OSTivoli Workload Scheduler V8s 51tmnt_tbsm_eng 256tmnt_tbsm_wrapper 256TMR 33TMW_Clearing 235TMW_HighProcesses 267


tmw2k.log 269Tmw2kProfile 252TOPO link

topology link 83topology display 281topology display services 40topxgate.conf 295, 306topxlistener.conf 294topxlistener.properties 307, 566topxtrapgate.conf 569TPSTART 58, 431trace_tmnt_tbsm_eng1.log 269trace_tmnt_tbsm_wrapper1.log 270transaction program 58transport.server.ip.address 259transport.server.mqe.port 259tree view 14triggers 84trouble ticket 466TSD Event Handler 33TSD/390

application customization 477NetView customization 475

TWH_CDW 531, 539changes 539

TWH_MART 531–532TWH_MD 531TWS for z/OStypes of ETLs

Central Data Warehouse 530

UUNIX System Services 392UpdateObjPathCache 397UQ64483 362USERS record 481

VVTAMOPTS 377

Wwarehouse pack 530WARF 312wbkupdb 211wdmconfig 256, 259wdmdiscovery 251, 262wdmlseng 242, 266

wdmmn 258wdmtrceng 269Web Application Registration Files 312Web console 20, 119

roles 125web console 312Web console server 28WebServer database 80, 433WebSphere® OS/390 27Windows 2000

tuning 458Windows 2000 Server 154Windows Management Instrumentation, see WMIWindows NT

permission 422security 422sharing 424

Windows registry 40Windows Resource Kit 152Winlogon 431winlogon

AutoAdminLogon 431DefaultDomain 431DefaultPassword 431DefaultUserID 431

winstall 33wintel servers 150wlookup 135wlseng 242wlsinst 23, 135WMI 250wruntask 211wtdumprl 233, 242wtdumptr 233, 243

Xxdfparser 47xdfparser directory 40XML messages 51XML tags 269XRC 54

Zz/OS commands

OGET 392SETPROG 333

z/OS jobs 438

Index 595

(1.0” spine)0.875”<

->1.498”460 <

-> 788 pages

Tivoli Business Systems M

anager Version 2.1End-to-End Business Im

pact Managem

ent

®

SG24-6610-00 ISBN 0738427055

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICALINFORMATION BASED ONPRACTICAL EXPERIENCE

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

For more information:ibm.com/redbooks

Tivoli Business Systems Manager Version 2.1End-to-End Business Impact Management

In-depth product structure revealed and explained

Detailed implementation of best practices

Integrated systems management solution

This IBM Redbook gives a broad understanding of the IBM Tivoli Business Systems Manager architecture and internals. The in-depth discussion covers the product’s inner workings and includes log files to illustrate the processing of its various components.

IBM Tivoli Business Systems Manager is designed to display all aspects of the enterprise’s IT system as they affect the users’ business systems. This book enables easy implementation of IBM Tivoli Business Systems Manager in distributed environments. Procedures are illustrated with examples of the installation and configuration process to explain the deployment of IBM Tivoli Business Systems Manager into a customer’s environment.

This book also covers the implementation of IBM Tivoli Business Systems Manager in z/OS with most of its major interfaces. IBM Tivoli Business Systems Manager can monitor all major IBM subsystems in z/OS, including IMS, DB2, CICS, storage, and Web solutions.

A book about concepts and implementation would not be complete without a comprehensive discussion about using, maintaining, and troubleshooting the system. We devote several sections to these topics.

Back cover