Tivoli Business Systems Manager V2.1 End-To-End Business Impact Management Sg246610

Front cover
Tivoli Business Systems Manager Version 2.1

End-to-End Business Impact Management
In-depth product structure revealed and explained Detailed implementation of best practices Integrated systems management solution
Budi Darmawan Alessio DAmico Cedric Foo Peter Glasmacher Stephen Nosbisch Samson Yiu
ibm.com/redbooks
International Technical Support Organization Tivoli Business Systems Manager Version 2.1 End-to-End Business Impact Management April 2003
SG24-6610-00
Note: Before using this information and the product it supports, read the information in Notices on page xxiii.
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).
Copyright International Business Machines Corporation 2003. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxvii Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii Part 1. Concept and planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1. Introduction to business systems management . . . . . . . . . . . . 3 1.1 Business systems management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Tivoli systems management product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 IBM Tivoli Business Systems Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.1 Business system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.2 Discovery processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3.3 Event processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.3.4 Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.4 Document organization and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.5 Lab environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Chapter 2. Components and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1 Product structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2 Base services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.1 Components and data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.2 Installation directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.2.3 Windows registry structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.2.4 Log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.3 Distributed resource feeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.3.1 Agent Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.3.2 Common listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.4 Mainframe (z/OS) resource feeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.4.1 OS/390 components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.4.2 Windows servers connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.4.3 Object registration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Copyright IBM Corp. 2003. All rights reserved.
iii
2.4.4 Bulk discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.4.5 Command support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 2.5 History server, reporting, and health monitor . . . . . . . . . . . . . . . . . . . . . . 68 2.5.1 History server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 2.5.2 The reporting system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 2.5.3 Health monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Chapter 3. Database structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 3.1 Microsoft SQL Server overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.2 The databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.3 Object implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.3.1 Important information sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.3.2 Object structure implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.3.3 Business Systems implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 84 3.3.4 ROOT, BUSC, and LOBC objects. . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3.3.5 Object hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3.4 Status propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.5 Agent listener resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.5.1 Class implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.5.2 AMS tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 3.6 Common listener resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.7 Menu and command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3.7.1 Menu, menu item, and launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3.7.2 z/OS subsystems command support . . . . . . . . . . . . . . . . . . . . . . . 102 3.7.3 Tivoli task support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Chapter 4. User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 4.1 Java console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 4.2 Web console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Chapter 5. Implementation planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 5.1 Planning overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 5.2 Personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 5.3 Hardware specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 5.4 Network and connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 5.5 Software level and prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.5.1 Planning for distributed systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.5.2 Planning for mainframe systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 5.6 Operators and users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 5.7 Business System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 5.7.1 Business System View theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 5.7.2 Business System View design concept. . . . . . . . . . . . . . . . . . . . . . 139 5.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 . . . . . . . . . . . . . . . . . . . . . . . . 149 6.1 Hardware and software prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 6.1.1 Hardware configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 6.1.2 Software components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 6.1.3 Hardware and software configuration for this book . . . . . . . . . . . . . 152 6.2 Prerequisite software components installation . . . . . . . . . . . . . . . . . . . . 154 6.2.1 Operating system: Windows 2000 Server . . . . . . . . . . . . . . . . . . . . 154 6.2.2 MKS Toolkit for Systems Administrators Version 7.5 or 8.0 . . . . . . 155 6.2.3 Windows Resource Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 6.2.4 JDBC Driver: Microsoft SQL 2000 Driver for JDBC . . . . . . . . . . . . 155 6.2.5 Microsoft IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 6.2.6 Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 6.3 Database server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 6.4 Console and propagation server installation . . . . . . . . . . . . . . . . . . . . . . 190 6.5 History server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 6.6 Health Monitor Server implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 199 6.6.1 HMS Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 6.6.2 Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 6.6.3 Health Monitor Client implementation . . . . . . . . . . . . . . . . . . . . . . . 208 Chapter 7. TEC components integration. . . . . . . . . . . . . . . . . . . . . . . . . . 209 7.1 Tivoli Enterprise Console overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 7.2 Setting up the TEC connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 7.2.1 Installing event enablement and the task server . . . . . . . . . . . . . . . 211 7.2.2 Setting up the user ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 7.2.3 Updating the TEC event classes and rules . . . . . . . . . . . . . . . . . . . 217 7.2.4 Enabling TBSM agent listener. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 7.3 IBM Tivoli Monitoring modules integration . . . . . . . . . . . . . . . . . . . . . . . 226 7.4 Creating a generic component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 7.5 Defining a component from DM monitors . . . . . . . . . . . . . . . . . . . . . . . . 235 7.6 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Chapter 8. IBM Tivoli Monitoring integration . . . . . . . . . . . . . . . . . . . . . . 249 8.1 IBM Tivoli Monitoring integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 8.2 Adapter installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 8.2.1 Installing JRE 1.3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 8.2.2 Installing the TBSM adapter for ITM . . . . . . . . . . . . . . . . . . . . . . . . 254 8.2.3 TBSM adapter processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 8.2.4 Configuring the IBM Tivoli Monitoring for 5.1.1 TBSM Adapter . . . 259 8.3 Using the TBSM adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 8.3.1 Discovery process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 8.3.2 Event forwarding to Tivoli Business Systems Manager . . . . . . . . . 264
Contents
8.4 Tracing an event to the Common Listener . . . . . . . . . . . . . . . . . . . . . . . 268 Chapter 9. IBM Tivoli NetView integration . . . . . . . . . . . . . . . . . . . . . . . . 279 9.1 What IBM Tivoli NetView is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 9.2 NetView 7.1.3 installation and configuration . . . . . . . . . . . . . . . . . . . . . . 283 9.2.1 Installation prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 9.2.2 Suggested configuration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 9.3 Adapter installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 9.3.1 Installing the NetView part of the adapter . . . . . . . . . . . . . . . . . . . . 292 9.3.2 Installing the TBSM part of the adapter. . . . . . . . . . . . . . . . . . . . . . 293 9.4 NetView adapter configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 9.5 Using the adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 9.5.1 Bulk discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 9.5.2 How NetView resources are handled . . . . . . . . . . . . . . . . . . . . . . . 297 9.5.3 Launching NetView Web console from TBSM . . . . . . . . . . . . . . . . 303 9.6 Troubleshooting the environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 9.6.1 TBSM adapter basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 9.6.2 TBSM communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 9.6.3 Testing the launch functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 9.6.4 TBSM adapter log and trace files . . . . . . . . . . . . . . . . . . . . . . . . . . 309 9.7 Extending the menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 9.7.1 Extending the NetView Web console . . . . . . . . . . . . . . . . . . . . . . . 312 9.7.2 Extending the TBSM Java console . . . . . . . . . . . . . . . . . . . . . . . . . 319 Part 3. z/OS integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 Chapter 10. z/OS installation and configuration . . . . . . . . . . . . . . . . . . . 331 10.1 Source/390 implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 10.1.1 Pre-installation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 10.1.2 Installing Source/390. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 10.1.3 Bulk discovery configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 10.1.4 Source/390 tuning considerations . . . . . . . . . . . . . . . . . . . . . . . . . 337 10.1.5 Source/390 security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 10.2 Setting up Tivoli NetView for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 10.2.1 Modify the NetView started task procedure . . . . . . . . . . . . . . . . . 339 10.2.2 Modify the DSIPARM members . . . . . . . . . . . . . . . . . . . . . . . . . . 339 10.2.3 Enable the PPI connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 10.2.4 Enable NETCONV connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 10.2.5 Enabling communication between NetView systems . . . . . . . . . . 341 10.2.6 Tuning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 10.3 Implementing the Event Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Chapter 11. z/OS data feeds and discovery . . . . . . . . . . . . . . . . . . . . . . . 347 11.1 z/OS data feeds overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
vi
11.2 System Automation for OS/390 Version 2.1 . . . . . . . . . . . . . . . . . . . . . 349 11.2.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 11.2.2 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 11.2.3 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 11.3 Database 2 (DB2) for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 11.3.1 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 11.3.2 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 11.4 Information Management System (IMS) . . . . . . . . . . . . . . . . . . . . . . . . 357 11.4.1 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 11.4.2 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 11.5 CICSPlex System Manager Version 2.2 . . . . . . . . . . . . . . . . . . . . . . . . 361 11.5.1 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 11.5.2 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 11.6 Tivoli Workload Scheduler for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 11.6.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 11.6.2 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 11.6.3 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 11.7 Resource Object Data Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 11.7.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 11.7.2 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 11.7.3 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 11.8 Resource Measurement Facility (RMF). . . . . . . . . . . . . . . . . . . . . . . . . 381 11.8.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 11.8.2 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 11.9 System Managed Storage (SMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 11.9.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 11.9.2 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 11.10 DFSMS Hierarchical Storage Manager . . . . . . . . . . . . . . . . . . . . . . . . 388 11.10.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 11.10.2 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 11.11 WebSphere HTTP Server for OS/390 . . . . . . . . . . . . . . . . . . . . . . . . . 391 11.11.1 Integration setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 11.11.2 Object discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Part 4. Advanced configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Chapter 12. Automatic Business System View creation . . . . . . . . . . . . . 395 12.1 Automatic Business System View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 12.1.1 Automatic Business Systems design . . . . . . . . . . . . . . . . . . . . . . 396 12.1.2 Automatic Business Systems configuration file. . . . . . . . . . . . . . . 397 12.1.3 Defining the Automatic Business System . . . . . . . . . . . . . . . . . . . 402 12.2 ABS usage example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 12.2.1 Manual creation of the business system view . . . . . . . . . . . . . . . . 403
Contents
vii
12.2.2 BSV creation tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 12.3 Distributed LOB rules to ABS migration . . . . . . . . . . . . . . . . . . . . . . . . 414 12.3.1 Migration description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 12.3.2 Migration example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Chapter 13. Setting up roles and security. . . . . . . . . . . . . . . . . . . . . . . . . 421 13.1 Resource security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 13.1.1 Protecting files and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 13.1.2 Protecting the registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 13.1.3 Windows user ID and groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 13.2 Password protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 13.2.1 TBSM processes passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 13.2.2 Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 13.2.3 Reporting system password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 13.3 TBSM command security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 13.4 TBSM operators and workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 Chapter 14. Maintenance and tuning issues . . . . . . . . . . . . . . . . . . . . . . 437 14.1 SQL Server Agent jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 14.1.1 z/OS-related jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 14.1.2 Distributed resources jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 14.1.3 Database maintenance jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 14.2 Database maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 14.2.1 Database statistic and check . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 14.2.2 Database Maintenance Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 14.3 Microsoft SQL Server and Windows 2000 tuning . . . . . . . . . . . . . . . . . 458 14.3.1 Windows 2000 Advanced Server tuning . . . . . . . . . . . . . . . . . . . . 458 14.3.2 Microsoft SQL Server 2000 tuning . . . . . . . . . . . . . . . . . . . . . . . . 462 Chapter 15. Automatic problem ticketing . . . . . . . . . . . . . . . . . . . . . . . . . 465 15.1 Automatic problem ticketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 15.2 Defining the auto ticketing rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 15.3 Tivoli Information Management for z/OS integration overview . . . . . . . 469 15.4 Installation and configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 15.4.1 Enable problem management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 15.4.2 Extract and customize the input-output processor . . . . . . . . . . . . 474 15.4.3 Setting up the task server and Tivoli NetView for z/OS . . . . . . . . 475 15.4.4 Application customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477 15.5 Using the problem ticket interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 15.5.1 Manual problem ticket operation . . . . . . . . . . . . . . . . . . . . . . . . . . 499 15.5.2 Closing a problem ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 Chapter 16. High availability and failover . . . . . . . . . . . . . . . . . . . . . . . . . 513 16.1 Failover concept and terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
viii
16.2 Implementation of failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515 16.2.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515 16.2.2 Installation and customization of failover . . . . . . . . . . . . . . . . . . . 516 16.2.3 Setup for z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 16.3 Performing failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 16.3.1 Enabling failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522 16.3.2 Enabling reverse failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522 16.4 Limitations and discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523 16.5 Troubleshooting tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525 Chapter 17. Historical reporting with TEDW . . . . . . . . . . . . . . . . . . . . . . . 527 17.1 Tivoli Enterprise Data Warehouse overview . . . . . . . . . . . . . . . . . . . . . 528 17.1.1 Tivoli Enterprise Data Warehouse concepts and components . . . 529 17.1.2 IBM Tivoli Business Systems Manager integration . . . . . . . . . . . . 532 17.2 Installation and configuration for data warehouse . . . . . . . . . . . . . . . . . 533 17.2.1 Warehouse integration pre-installation steps . . . . . . . . . . . . . . . . 533 17.2.2 Setting up the source ETL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534 17.3 Activating collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538 17.3.1 Changes on the TWH_CDW database . . . . . . . . . . . . . . . . . . . . . 539 17.3.2 Creating an ODBC connection to source database . . . . . . . . . . . 539 17.3.3 Defining authority to the Warehouse Sources and Targets . . . . . 543 17.3.4 Scheduling the source ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 17.3.5 Changing the source ETL status to Production. . . . . . . . . . . . . . . 551 17.3.6 Running ETLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 Part 5. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553 Appendix A. Detailed process flow of services . . . . . . . . . . . . . . . . . . . . 555 Appendix B. Sample files and scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557 The gemmfprod.sh script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558 High-level load sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560 ASILoad_Highlevel.ksh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560 ITSO_Highlevel - Sample high-level load source . . . . . . . . . . . . . . . . . . . 564 Appendix C. IBM Tivoli NetView additional information . . . . . . . . . . . . . 565 NetView adapter configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566 The nvid.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566 The topxlistener.properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566 The topxtrapgate.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569 TBSM adapter files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571 Launch menu item add and delete script . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572 NetView Web Server script 3beansalad.js . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Contents
ix
Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577 System requirements for downloading the Web material . . . . . . . . . . . . . 578 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579 Related publications . . . . . . . . . . . . . . . . . . . . . . IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other resources . . . . . . . . . . . . . . . . . . . . . . . . Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . IBM Redbooks collections . . . . . . . . . . . . . . . . . ...... ...... ...... ...... ...... ...... ....... ....... ....... ....... ....... ....... ...... ...... ...... ...... ...... ...... . . . . . . 583 583 583 584 584 584
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Figures
1-1 1-2 1-3 1-4 1-5 1-6 1-7 1-8 1-9 1-10 1-11 2-1 2-2 2-3 2-4 2-5 2-6 2-7 2-8 2-9 2-10 2-11 2-12 2-13 2-14 2-15 2-16 2-17 2-18 2-19 2-20 2-21 2-22 2-23 2-24 2-25 2-26 2-27 Tivoli software product pillars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Tivoli performance and availability solutions . . . . . . . . . . . . . . . . . . . . . . 6 TBSM console: propagation path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 TBSM console: tree view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 TBSM console: Hyperview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 TBSM console: Table view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 TBSM console: Business impact view . . . . . . . . . . . . . . . . . . . . . . . . . . 17 TBSM console: events view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 TBSM properties window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 TBSM Web console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Network diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 IBM Tivoli Business Systems Manager product structure . . . . . . . . . . . 26 TBSM flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 IBM Tivoli Business Systems Manager Windows directory structure . . 39 Registry tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Hierarchical setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Database setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Flowchart for distributed system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 AMS description files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Common listener connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 z/OS components and feeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 TBSM data server startup log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 TBSM object server startup log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 TBSM object pump startup log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Connection from z/OS to TBSM servers . . . . . . . . . . . . . . . . . . . . . . . . 58 Initial conversation for TBSM connection. . . . . . . . . . . . . . . . . . . . . . . . 60 Sample message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Queue file contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 The Resources view after the high-level object load . . . . . . . . . . . . . . . 64 Parameters of the GTMAOPE0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 MVSIPListener registry definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Command aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 History server setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Microsoft IIS virtual directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Reporting system invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Object Event Report Selection screen . . . . . . . . . . . . . . . . . . . . . . . . . . 72 A generated report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Health monitor client window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
xi
2-28 3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 3-9 3-10 3-11 3-12 3-13 3-14 3-15 3-16 3-17 3-18 3-19 3-20 3-21 3-22 4-1 4-2 4-3 4-4 4-5 4-6 4-7 4-8 4-9 4-10 4-11 4-12 4-13 4-14 4-15 4-16 5-1 5-2 5-3 5-4
Registry Editor for Health Monitoring profile . . . . . . . . . . . . . . . . . . . . . 75 Microsoft SQL Server Enterprise Manager . . . . . . . . . . . . . . . . . . . . . . 79 Part of TBSM containment hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 TBSM inheritance hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 The propagation concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Propagation algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 GEM object classes in TBSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Tables for CID G02H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 GEMLookupCID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 GEM_IDlookup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 GEM_DMtoCID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 CL_Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Common listener auto placement table . . . . . . . . . . . . . . . . . . . . . . . . . 96 CL_Severities content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Default context menu for DB2InstanceManager . . . . . . . . . . . . . . . . . . 98 Context menu processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Running the asisp_definemenuitem. . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Invoke MVS D A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Task setting window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Tivoli NetView for z/OS prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Task Monitor result window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Context menu for DIRCDrv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Execution result for DIRCDrv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Java console structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 IBM Tivoli Business Systems Manager icon . . . . . . . . . . . . . . . . . . . . 114 IBM Tivoli Business Systems Manager sign-on dialog . . . . . . . . . . . . 115 Welcome screen for IBM Tivoli Business Systems Manager. . . . . . . . 115 Primary Menu for Super Administrator. . . . . . . . . . . . . . . . . . . . . . . . . 116 Expanded console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Property page of a DB2InstanceManager object . . . . . . . . . . . . . . . . . 118 Expanded console in debug mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Sign on to the IBM Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Welcome screen of the Web console . . . . . . . . . . . . . . . . . . . . . . . . . 122 Primary options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 User profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 User roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 TBSM Sign On screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Business System View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 All Resources View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Flat BSV for Remote Banking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Hierarchical BSV for Remote Banking . . . . . . . . . . . . . . . . . . . . . . . . . 142 Inverted hierarchy BSV for Remote Banking . . . . . . . . . . . . . . . . . . . . 143 Grouped resource BSV for Remote Banking . . . . . . . . . . . . . . . . . . . . 144
xii
6-1 6-2 6-3 6-4 6-5 6-6 6-7 6-8 6-9 6-10 6-11 6-12 6-13 6-14 6-15 6-16 6-17 6-18 6-19 6-20 6-21 6-22 6-23 6-24 6-25 6-26 6-27 6-28 6-29 6-30 6-31 6-32 6-33 6-34 6-35 6-36 6-37 6-38 6-39 6-40 6-41 6-42 6-43
InstallShield Welcome dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Computer Name dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Installation Selection dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 User Information dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Software License Agreement dialog . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Installation Definition dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Instance Name dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Setup Type dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Choose Folder dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Select Components dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Services Account dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Authentication Mode dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Collation Settings dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Network Libraries dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Start Copying Files dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Choose Licensing Mode dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 SQL Server Enterprise Manager view . . . . . . . . . . . . . . . . . . . . . . . . . 170 SQL Server Security options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Change password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Password confirmation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Log on to SQL Query Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Current Connection Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Connection Properties options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Opening the Options menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Tools Options dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Language selection dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 System File Update welcome screen. . . . . . . . . . . . . . . . . . . . . . . . . . 177 Temporary directory selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 System File Upgrade complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Welcome dialog for TBSM installation . . . . . . . . . . . . . . . . . . . . . . . . . 180 License agreement dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Setup path selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Setup type selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Select Components for database server . . . . . . . . . . . . . . . . . . . . . . . 183 Enter Information for SQL database server host name . . . . . . . . . . . . 184 Database parameters dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Database upgrade dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Start copying files dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Setup Complete dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Extract seed database files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Changes in AttachDatabases.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Services setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Component selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Figures
xiii
6-44 6-45 6-46 6-47 6-48 6-49 6-50 6-51 6-52 6-53 6-54 6-55 6-56 6-57 6-58 6-59 6-60 6-61 7-1 7-2 7-3 7-4 7-5 7-6 7-7 7-8 7-9 7-10 7-11 7-12 7-13 7-14 7-15 7-16 7-17 8-1 8-2 8-3 8-4 8-5 8-6 8-7 8-8
Create local groups dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 JDBC driver selection dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Installation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Services list for console and propagation server . . . . . . . . . . . . . . . . . 194 TBSM operators groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 History Server component selection dialog . . . . . . . . . . . . . . . . . . . . . 195 Creating a new database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 History database properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Pop-up message for historyserversetup.ksh . . . . . . . . . . . . . . . . . . . . 197 Health Monitor Server component selection dialog . . . . . . . . . . . . . . . 200 Health Monitor Server host name dialog . . . . . . . . . . . . . . . . . . . . . . . 201 Health Monitor Server parameters dialog . . . . . . . . . . . . . . . . . . . . . . 202 Open the Properties dialog for Health Monitor. . . . . . . . . . . . . . . . . . . 203 Health Monitor Log On tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Health monitor profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Default services definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Settings for Common Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 MonitoredQueueTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Event flow for IBM Tivoli Business Systems Manager integration . . . . 210 Install Product window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Services window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Local Security Settings window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Security setting dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Tivoli BSM Event Enablement Properties window . . . . . . . . . . . . . . . . 216 TME Desktop of Administrator window . . . . . . . . . . . . . . . . . . . . . . . . 217 Event Server Rule Bases window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Import Into Rule Base window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 TBSM console: All Resources - Descendents window . . . . . . . . . . . . 229 GEMLookupCID content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 New generic test object created. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Properties window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Flow diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Event Viewer: Group All - All events . . . . . . . . . . . . . . . . . . . . . . . . . . 238 All Resources - Descendents window . . . . . . . . . . . . . . . . . . . . . . . . . 239 Note editor for closing an event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 IBM Tivoli Business Systems Manager for ITM diagram . . . . . . . . . . . 251 Installing JRE 1.3.0 via GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Install Product window, ITM adapter for TBSM . . . . . . . . . . . . . . . . . . 255 Install Options window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 IBM Tivoli Business Systems Manager console window . . . . . . . . . . . 263 Instrumentation mapping to enterprise . . . . . . . . . . . . . . . . . . . . . . . . 264 Profile Properties window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Indications and Actions window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
xiv
8-9 8-10 8-11 8-12 9-1 9-2 9-3 9-4 9-5 9-6 9-7 9-8 9-9 9-10 9-11 9-12 9-13 9-14 9-15 9-16 9-17 9-18 9-19 9-20 9-21 9-22 9-23 9-24 9-25 9-26 9-27 9-28 9-29 10-1 11-1 11-2 11-3 11-4 11-5 11-6 11-7 11-8 11-9
All Resources - Descendants window . . . . . . . . . . . . . . . . . . . . . . . . . 267 Windows 2000 - Properties window . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 SQL Window: Query-ibmtiv5.Object.sa . . . . . . . . . . . . . . . . . . . . . . . . 275 SQL Window: Query-ibmtiv5.object.sa . . . . . . . . . . . . . . . . . . . . . . . . 276 NetViews main capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 The NetView Web console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Invoking Web console Security from nvsetup . . . . . . . . . . . . . . . . . . . 286 The Web Console Security dialog box . . . . . . . . . . . . . . . . . . . . . . . . . 287 The Add User dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 The NetView Web Console download page . . . . . . . . . . . . . . . . . . . . 288 Changing the default path for the NetView Web Console . . . . . . . . . . 289 Web Console login dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Open a map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 The TBSM Bulk Upload entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 NetViews bulk upload message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 The initial NetView Map contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Initial NetView resources uploaded to TBSM. . . . . . . . . . . . . . . . . . . . 299 Hyperview view of NetView resources . . . . . . . . . . . . . . . . . . . . . . . . . 300 The final discovery in NetView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 The corresponding TBSM hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Various network views in TBSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 TBSMs Launch submenu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 The Web Console Launch results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Launch error message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 The Roles dialog with the new menu entry . . . . . . . . . . . . . . . . . . . . . 317 Parsing error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 NetView Web console and the new menu . . . . . . . . . . . . . . . . . . . . . . 318 The resulting output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 The Launch submenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 NetView Console launch process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 3beansalad.js display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 The new menu entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 The Web console display launched by the new menu . . . . . . . . . . . . . 327 Property page of OS object to enable upload . . . . . . . . . . . . . . . . . . . 344 Feeds for z/OS systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 System Automation for OS/390 2.1 connection to TBSM . . . . . . . . . . 350 Subsystem objects from System Automation for OS/390 . . . . . . . . . . 353 DB2 topology display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 IMS descendants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 CPSM main panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 View selection panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 RTASPEC panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Real time analysis specification update . . . . . . . . . . . . . . . . . . . . . . . . 364
Figures
xv
11-10 11-11 11-12 11-13 11-14 11-15 11-16 11-17 11-18 11-19 11-20 11-21 11-22 11-23 11-24 11-25 11-26 11-27 11-28 11-29 11-30 11-31 11-32 11-33 12-1 12-2 12-3 12-4 12-5 12-6 12-7 12-8 12-9 12-10 12-11 12-12 12-13 13-1 13-2 13-3 13-4 13-5 13-6
Action definition selection panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Creating TBSMA1 action definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Updated action definition list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 CICSPlex System Manager panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 CPSM primary option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 BATCHREP display panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 BATCHREP submission panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Property of a CICSPlex definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 Initiating CICSPlex SM discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 CICSPlex SM CICS Topology display . . . . . . . . . . . . . . . . . . . . . . . . . 372 Detailed operation information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 Inserting SNA APPN network object . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Setting the NetID name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 Setting the OS path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 SNA topology view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Event flow and component descriptions for TBSM/RMF integration . . 382 Invoking RMF registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 SMS information flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Register monitoring interval for SMS resources . . . . . . . . . . . . . . . . . 387 Disk configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Creating an HSM object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 HSM creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 DFSMShsm topology view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 HTTP Server objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 ABS processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 Sample business system view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Database tables with the loaded ABS configuration . . . . . . . . . . . . . . 405 ITSO RESOURCES business system view . . . . . . . . . . . . . . . . . . . . . 406 ABSMain window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 First BSV ITSO Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 BSV tree for the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Adding Production OS filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Defining condition for production OS . . . . . . . . . . . . . . . . . . . . . . . . . . 412 Condition for Production DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 Distributed Line of Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 GEM_InstFiltering table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Table GEM_Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 Changing TivoliManager directorys property . . . . . . . . . . . . . . . . . . . 423 Sharing property for the TivoliManager directory . . . . . . . . . . . . . . . . . 424 Security property of TivoliManager directory . . . . . . . . . . . . . . . . . . . . 425 Advanced security setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Protecting TBSM registry key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 TBSM registry permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
xvi
13-7 13-8 13-9 13-10 13-11 13-12 13-13 14-1 14-2 14-3 14-4 14-5 14-6 14-7 14-8 14-9 14-10 14-11 14-12 14-13 14-14 14-15 14-16 14-17 14-18 14-19 14-20 14-21 14-22 15-1 15-2 15-3 15-4 15-5 15-6 15-7 15-8 15-9 15-10 15-11 15-12 15-13 15-14
Advanced permissions setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 Automatic logon for Event Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 Historical database users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 Extract of the MenuItem table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 Saving a workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Opening a workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Editing a workspace permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 Cleanup Old Log Files job window. . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 Delete Old MVS Upload Output Files window . . . . . . . . . . . . . . . . . . . 443 Cleanup Old DB Queues window . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 Update ObjectEvents stats job wIndow . . . . . . . . . . . . . . . . . . . . . . . . 446 Update Object Stats job wIndow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 Database Maintenance Plan creation . . . . . . . . . . . . . . . . . . . . . . . . . 448 Database Maintenance Plan Wizard: Welcome. . . . . . . . . . . . . . . . . . 449 Database Maintenance Plan Wizard: Select Databases . . . . . . . . . . . 450 Database Maintenance Plan Wizard: Data Optimization settings . . . . 451 Database Maintenance Plan Wizard: Database Integrity Check . . . . . 452 Database Maintenance Plan Wizard: Backup settings . . . . . . . . . . . . 453 Database Maintenance Plan Wizard: Backup Disk Directory settings . 454 Database Maintenance Plan Wizard: Transaction Log Backup settings455 Database Maintenance Plan Wizard: Reports to Generate . . . . . . . . . 456 Database Maintenance Plan Wizard: Maintenance Plan History. . . . . 457 Database Maintenance Plan Wizard summary . . . . . . . . . . . . . . . . . . 458 Windows 2000 System Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 Windows2000 Performance Options . . . . . . . . . . . . . . . . . . . . . . . . . . 459 Windows 2000 Local Area Connection Properties. . . . . . . . . . . . . . . . 460 Windows 2000 File and Printers Sharing Properties . . . . . . . . . . . . . . 461 SQL Server Properties Memory window . . . . . . . . . . . . . . . . . . . . . . . 462 SQL Server Properties Processor window. . . . . . . . . . . . . . . . . . . . . . 463 Problem and change management interface . . . . . . . . . . . . . . . . . . . . 466 Data flow: TBSM operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470 TBSM event ID assisted entry panel . . . . . . . . . . . . . . . . . . . . . . . . . . 478 IBM Tivoli Business Systems Manager class ID assisted entry panel . 479 Tivoli Information Management for z/OS s-word display . . . . . . . . . . . 480 Tivoli Information Management for z/OS p-word display . . . . . . . . . . . 480 Users to notify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 Deleting of the BRANCH control line . . . . . . . . . . . . . . . . . . . . . . . . . . 482 Change DEFAULT to MVS user ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 Control panel update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 Function line summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486 First line option 1: Control flow processing . . . . . . . . . . . . . . . . . . . . . 487 First line oOption 2: Data collection processing . . . . . . . . . . . . . . . . . . 488 First line option 3: Test data processing . . . . . . . . . . . . . . . . . . . . . . . 488
Figures
xvii
15-15 15-16 15-17 15-18 15-19 15-20 15-21 15-22 15-23 15-24 15-25 15-26 15-27 15-28 15-29 15-30 15-31 15-32 15-33 15-34 15-35 15-36 15-37 15-38 15-39 15-40 15-41 15-42 15-43 17-1 17-2 17-3 17-4 17-5 17-6 17-7 17-8 17-9 17-10 17-11 17-12 17-13 17-14
Second line option 1: Control flow processing . . . . . . . . . . . . . . . . . . . 489 Second line option 2: Data collection processing . . . . . . . . . . . . . . . . 490 Second line option 3: Test data processing . . . . . . . . . . . . . . . . . . . . . 490 Third line option 1: Control flow processing . . . . . . . . . . . . . . . . . . . . . 491 Third line option 2: Data collection processing . . . . . . . . . . . . . . . . . . 492 Third line option 3: Test data processing . . . . . . . . . . . . . . . . . . . . . . . 492 Fourth line option 1: Control flow processing . . . . . . . . . . . . . . . . . . . . 493 Fourth line option 2: Data collection processing . . . . . . . . . . . . . . . . . 494 Fourth line option 3: Test data processing . . . . . . . . . . . . . . . . . . . . . . 494 Fifth line option 1: Control flow processing . . . . . . . . . . . . . . . . . . . . . 495 Fifth line option 2: Data collection processing . . . . . . . . . . . . . . . . . . . 496 Fifth line option 3:Test data processing . . . . . . . . . . . . . . . . . . . . . . . . 496 Panel list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 List of modified panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 Panel Copy specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 Problem ticket creation dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 Authentication dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 Problem ticket created . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 Problem ticket icon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 Tivoli Information Management for z/OS with the problem ticket. . . . . 503 Searching for a problem ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504 Problem ticket list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505 Problem ticket window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 Problem ticket updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507 Creating new problem ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508 Searching Tivoli Information Management for ticket no 00000009 . . . 509 Search result for ticket no 00000009 . . . . . . . . . . . . . . . . . . . . . . . . . . 509 Closing problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510 Closing problem dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511 A typical Tivoli Enterprise Data Warehouse environment . . . . . . . . . . 529 IBM Tivoli Business Systems Manager warehouse component . . . . . 532 Installation type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535 Path to the installation media for the GTM. . . . . . . . . . . . . . . . . . . . . . 536 IBM Tivoli Business Systems Manager program installation . . . . . . . . 537 IBM Tivoli Business Systems Manager ETL Installation summary . . . 538 System DSN tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540 Selecting the data source for ODBC System DSN . . . . . . . . . . . . . . . 541 SQL Server data source settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541 User authentication for the new data source . . . . . . . . . . . . . . . . . . . . 542 Other options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542 Completing the data source definition . . . . . . . . . . . . . . . . . . . . . . . . . 543 IBM Tivoli Monitoring Version 5.1.1 Generic ETL1 Sources . . . . . . . . 544 GTM_OBJECT_Source user ID information . . . . . . . . . . . . . . . . . . . . 545
xviii
17-15 17-16 17-17 17-18 17-19 17-20 17-21 A-1
IBM Tivoli Business Systems Manager ETL target . . . . . . . . . . . . . . . 546 GTM_TWH_CDW_Target user ID information . . . . . . . . . . . . . . . . . . 547 GTM_c05_LOBState_Process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 548 Schedule GTM_c05_s010_Load_LOBStage . . . . . . . . . . . . . . . . . . . . 549 Schedule configuration for GTM_c05_s010_Load_LOBStage . . . . . . 550 Promoting scheduled processes to Production status . . . . . . . . . . . . . 551 Work in Progress window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552 Detailed services diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Figures
xix
xx
Tables
1-1 1-2 2-1 2-2 2-3 2-4 5-1 5-2 5-3 5-4 5-5 5-6 6-1 6-2 6-3 6-4 7-1 9-1 10-1 10-2 11-1 12-1 14-1 14-2 14-3 14-4 15-1 15-2 Reading paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Operating system and software detail . . . . . . . . . . . . . . . . . . . . . . . . . . 22 IBM Tivoli Business Systems Manager services by component . . . . . . 31 TBSM services log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 AMS types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 TEC exits for event forwarding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 List of mainframe information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Subsystem naming convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 IMS subsystems checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 DB2 subsystems checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 CICS subsystems checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Pro and cons of BSVs creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Required hardware configuration for TBSM. . . . . . . . . . . . . . . . . . . . . 151 TBSM server configuration running in the lab . . . . . . . . . . . . . . . . . . . 152 Prerequisite software components installed . . . . . . . . . . . . . . . . . . . . 153 Database attributes for reporting system . . . . . . . . . . . . . . . . . . . . . . . 199 IBM Tivoli Monitoring tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 nvid keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 z/OS data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Modification to IBM Tivoli NetView for z/OS startup procedure . . . . . . 339 TBSM batch jobs for SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 Distributed rules not supported by the migration script . . . . . . . . . . . . 416 z/OS Resources SQL jobs: suggested settings . . . . . . . . . . . . . . . . . . 438 Distributed Resources Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 Database Maintenance Jobs suggested settings . . . . . . . . . . . . . . . . 440 Queues tables cleaned up by the Cleanup Old DB Queue job . . . . . . 444 Problem management parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 Create a problem ticket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
xxi
xxii
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.
xxiii
Trademarks
The 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
Preface
This IBM Redbook gives a broad understanding of the IBM Tivoli Business Systems Manager architecture and internals. The in-depth discussion covers the products 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 enterprises 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 customers 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 redbook

This 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 DAmico 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.
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
Thanks to the following people for their contributions to this project: Betsy Thaggard International Technical Support Organization, Austin Center Pam Geiger, Mike Odom IBM Tivoli Software Group Jessie Zhang, Vivian Roberts IBM Australia
Become a published author

Join 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 welcome
Your 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:

redbook@us.ibm.com
Mail your comments to: IBM Corporation, International Technical Support Organization Dept. 0SJB Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493
xxviii
Part 1
Part
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.
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.
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 Business systems management

Over 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 enterprises 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 product

Tivoli, 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.
Tivoli Mgmt Solution Tivoli Mgmt Solution Business Systems Management Business Systems Management
Performance and Availability Configuration and Operations Storage Security
Monitoring Analysis Central Console Reporting
Centralized Control Service Delivery Web Management Pervasive Management
Storage Management Storage Area Network Management Data Protection Disaster Recovery
Access Management Indentity Management Risk Management
Common Infrastructure/Services
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.
Chapter 1. Introduction to business systems management
In the performance and availability area, products are structured as shown in Figure 1-2.
Real time Management Business Impact Management Predictive Management
IBM Tivoli Business Systems Manager
Event Correlation and Automation
IBM Tivoli Service Level Advisor
IBM Tivoli Web Site Analyzer
IBM Tivoli NetView
IBM Tivoli Enterprise Console IBM Tivoli Enterprise Data Warehouse
Monitor Systems and Applications
IBM Tivoli Monitoring
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
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 Manager

IBM 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 enterprises 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 system

A 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 companys 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. Note: In previous versions of IBM Tivoli Business Systems Manager this was known as a line of business (LOB) view.
1.3.2 Discovery processing

IBM 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.
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 processing

IBM 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.
10
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 objects 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.
11
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 Views
IBM 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
12
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 enterprises 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)
13
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
14
Hyperview, which graphically displays a large number of resources at one time as shown in Figure 1-5.
Figure 1-5 TBSM console: Hyperview
15
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
16
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
17
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
18
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
19
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 scope

This 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.
20
Table 1-1 Reading paths

Purpose Understanding IBM Tivoli Business Systems Manager architecture Planning an IBM Tivoli Business Systems Manager implementation Implementing IBM Tivoli Business Systems Manager in distributed environment Relevant topics Chapter 2, Components and functions on page 25 Chapter 3, Database structure on page 77 Chapter 2, Components and functions on page 25 Chapter 5, Implementation planning on page 129 Chapter 5, Implementation planning on page 129 Chapter 6, Base services implementation on page 149 Chapter 7, TEC components integration on page 209 Chapter 8, IBM Tivoli Monitoring integration on page 249 Chapter 9, IBM Tivoli NetView integration on page 279 Chapter 5, Implementation planning on page 129 Chapter 6, Base services implementation on page 149 Chapter 10, z/OS installation and configuration on page 331 Chapter 11, z/OS data feeds and discovery on page 347 Chapter 2, Components and functions on page 25 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
Implementing IBM Tivoli Business Systems Manager in z/OS environment
Maintaining IBM Tivoli Business Systems Manager
Extending IBM Tivoli Business Systems Manager with problem management Providing failover to IBM Tivoli Business Systems Manager servers Collecting historical information from IBM Tivoli Business Systems Manager
Chapter 16, High availability and failover on page 513
Chapter 17, Historical reporting with TEDW on page 527
21
1.5 Lab environment

We 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.
TBSM Servers
ibmtiv3 Windows 2000 Console V2 Server Propagation Server Common Listener
ibmtiv5 Windows 2000 MS SQL Server 2000 Database Server Agent Listener
ibmtiv6 Windows 2000 MS SQL Server 2000 History Server Health Monitor Server
3C041 Windows 2000 Event Server
Ethernet
CapeCod AIX 5.1 Netview 7.1.2
ibmtiv9 Windows 2000 Server Framework 3.7.1 TEC 3.7.1 ITM 5.1.1 ITM for DB/2 5.1 DB/2 7.1 Classic DM 3.7
SC64 - z/OS TBSM Source/390 Netview 5.1 TWS 8.1
SC66 - z/OS TBSM Source/390 Netview 5.1 RODM CICS CICSPlexSM
SC69 - z/OS MVS1 - z/OS TBSM Source/390 TBSM Source/390 Netview 5.1 Netview 5.1 SA/390 2.2 SA/390 2.2 RODM DB2 V7 z\OS IMS V7.1 SMS XRC RMF DFSMSHSM
ibmtiv8 Windows 2000 Server Endpont
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
Name ibmtiv3 OS Windows 2000 Advanced Server Edition Windows NT 2000 Advanced Server Edition Software Console V2 Server Propagation Server Common Listener MS-SQL 2000 Server Enterprise Edition Database Server Agent Listener
ibmtiv5
22
Name ibmtiv6
OS Windows 2000 Advanced Server Edition
Software MS-SQL 2000 Server Enterprise Edition HistoryServer Health Monitor Server TME Endpoint 106 Tivoli Management Framework 3.7.1 IBM Tivoli Enterprise Console 3.7.1 IBM Tivoli Monitoring 5.1.1 ITM for Databases: DB2 5.1 DB2 7.1 Tivoli Distributed Monitoring 3.7 NetView 7.1.2 TBSM Source/390 2.1 Tivoli NetView for z/OS 5.1 System Automation for OS/390 V2R1 Tivoli Workload Scheduler 8.1 DB2 for z/OS 7.1 IMS 7.1 CICS TM CICSPlex SM 2.2 Tivoli Decision Support/390 7.1 System Managed Storage 1.5 DFSMS/HSM 1.5. eXtended Remote Copy Resource Management Facility Event Handler Server
ibmtiv8 ibmtiv9
Windows 2000 Server Edition Windows 2000 Server Edition
capecod IBM S/390s
AIX 5.1 z/OS version 4
3C041
Windows 2000 Advanced Server Edition
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.7 Tivoli Enterprise Console Adapter Configuration Facility 3.7.1 BM Tivoli Monitoring, Version 5.1.0 - JRE 1.3.0 Tivoli Java Client Framework 3.7 Tivoli Java Client Framework 3.7.1 Java for Tivoli 3.7
23
Java for Tivoli 3.7.1 Tivoli Java RDBMS Interface Module (JRIM) 3.7 JavaHelp for Tivoli 3.7 Swing for Tivoli 3.7 Tivoli Enterprise Console Console 3.7.1 Tivoli Enterprise Console Server 3.7.1 Tivoli Enterprise Console User Interface Server 3.7.1 IBM Tivoli Monitoring, Version 5.1.1 Tivoli MDist 2 Graphical User Interface *-----------------------------------------------------------------------------* Patch List *-----------------------------------------------------------------------------* 3.7.1 Tivoli Enterprise Console ACF Fixpack 3 3.7.1 Tivoli Enterprise Console Console Fixpack 3 3.7.1 Tivoli Enterprise Console Server Fixpack 3 Tivoli 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 3 IBM Tivoli Monitoring, Version 5.1.1 - Fixpack 1 IBM Tivoli Monitoring - Tivoli Enterprise Data Warehouse Support, Version 5.1.1 Fixpack 1 Tivoli Java RDBMS Interface Module (JRIM) 3.7.1 JavaHelp for Tivoli 3.7.1 Swing for Tivoli 3.7.1 Tivoli 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.
24
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
25
2.1 Product structure

The major components of the IBM Tivoli Business Systems Manager are shown in Figure 2-1.
Base Services
Database server Event server Propagation server Console server History server others

TBSM Servers
TCP/IP
SNA (LU6.2) TCP/IP
Distributed Resouces Feeds

Mainframe Resources Feeds

Applications Batch systems Database systems Online systems Operating system Storage systems
OS/390
Tivoli Enterprise Console IBM Tivoli Monitoring Tivoli Instrumentation Service (AMS)
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)
26
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:

1
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
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. 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. Serves the client workstation connections. (This used to be called Application server.) Processes events and calculates the necessary propagation action. 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.
Database server
Console server Propagation server History 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
28
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 services

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

To 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.
29
z\OS
Source/390 Tivoli NetView for z\OS Tivoli Data Warehouse
TBSM Servers
Host Integration Server Event Handler Server History Server Web Console
Propagation Server
Database Server
Console Server
Web Console Server
Console
Agent Listener
Common Listener Service
Health Monitor Server
Health Monitor Client
Tivoli Management Region

Task Server TEC Event Enablement
Distributed Data Source. ( Netview, ITM)
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.
30
Table 2-1 IBM Tivoli Business Systems Manager services by component

Server Database server Services ASIDBValidater ASIMVSIPListenerSvc ASIPADispatcher ASIStagedEventLoader ASITaskServer ASIEvent Enablement ASITSDEvent HandlerSvc ASIDBValidater ASIConsoleServerV2 ASIDBValidater ASIRemoteExecutionServer ASIEnqueueProxy Server ASIDBValidater ASIEnqueueProxyServer ASIMVSIPOSListener ASIMVSEventHandlerSvc ASIMVSIPSenderSvc ASIMVSUploadRuleSvc ASIAgentListenerSvc ASIHealthMonitor TivoliPresentationServices HTTPServer TivoliPresentationServices HTTPAdministration ps_wc ps_mcr ASICommonListener Propagation agent is started with ASIPAgent.exe For SNA-based connection: ASIMVSSenderSvc ASIMVSListenerSvc Notes Agent Listener is installed from the Distributed TEC listener component that generally resides in this server
Console Server Propagation Server
Event handler server
Distributed TEC component Health Monitor server Web console server
This is usually installed in the database server Health monitor can be installed in the history server Web server services from Tivoli presentation services for the Web console
Common listener
Common listener can be installed together with application or propagation server No services installed No services installed
History Server Health Monitor Client
The following sections discuss the role of each service.
31
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' begin if 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') end else 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 agents 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.
32
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.
33
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 users 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 consoles 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. Note: If backward compatablity is required for previous IBM Tivoli Business Systems Manager consoles, you also should load Application Server services.
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.
34
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.que Name=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> -t<timeout> -r<repeat_count> -p<pause_time> -s -v -x File path to queue (required). Dequeue timeout in milliseconds. Repeat count. Specify -1 for infinite repeat. Pause between operations in milliseconds. Silent operation. Will not output queue entries to stdout. Useful with binary data. Output all printable data. Useful with binary data. May be used with -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.
35
Example 2-3 MVS IP listener connection

C:\>netstat -a | grep 1022 TCP 3c041:1022 TCP 3c041:1022 TCP 3c041:1022 TCP 3c041:1022 TCP 3c041:1022 3c041:0 LISTENING wtsc66.itso.ibm.com:1051 ESTABLISHED wtsc64.itso.ibm.com:1556 ESTABLISHED wtsc69.itso.ibm.com:3201 ESTABLISHED 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 ASIRuleSvcs ObjectSync table. After creating a new operating system object, run the SQL statement delete from ASIRuleSvc..ObjectSync and then restart the upload rule server.
36
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. Note: Chapter 10, z/OS installation and configuration on page 331 has more information about these z/OS communication services.
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.
37
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.
38
2.2.2 Installation directory structure

IBM 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 bin CommonListener ConsoleServer Data Data\products Configures automatic tracing for Common Listener and Console Server java processes. Main executable path for IBM Tivoli Business Systems Manager. This must be in the system path. Common listener installation directory. Console server installation directory. Data directory used for Tivoli Information Management for z/OS integration. Directories where Tivoli Manager for products definition is stored.
39
Data\Queues Data\Rules Lang Logs man Mgmt sql TDS xdfparser
Queue files directory where the enqueue proxy server writes files. Rule directory that is used by the ASIMVSUploadRule server. Rule files have the .clp extension. Language-specific locale for character translation tables. Main log directory, shared as Logs$ Not used. Directory for health monitor program and output files. This directory is shared as Mgmt$ Directory for storing SQL queries. Topology Display Services: the installation path for event enablement and task server. Parser script for decoding Application management instrumentation definitions into IBM Tivoli Business Systems Manager.
2.2.3 Windows registry structure

Most 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.
40
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. The location of the global settings for this servers IBM Tivoli Business Systems Manager in this server. The values of the installation parameters that we enter from the installation dialogs.
Settings SetupDefaults
The Settings folder has a hierarchical design, so all information is retireved from a branchs 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
41
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
42
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 files

Log 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 ASIDBValidater Tivoli BSM Database Validater ASIPADispatcher Tivoli BSM Propagation Agent Dispatcher ASIEnqueueProxyServer Tivoli BSM Enqueue Proxy Server ASIRemoteExecution Server Tivoli BSM Remote Execution Server PAgent.exe ASIApplicationSvc Tivoli BSM Application Server ASINotificationSvc Tivoli BSM Notification Server ASIMVSIPOSListenerSvc Tivoli BSM MVS IP Listener Log prefix PD EPS RX PA AS NS MVSIP MVSL_nnnn_
43
Process name ASIMVSListenerSvc ASIMVSEventHandlerSvc-nnnn Tivoli BSM MVS EventHandlerSvc-nnnn ASIMVSUploadRuleSvc Tivoli BSM MVSUpload Rule Server ASIMVSIPSenderSvc-nnnn Tivoli BSM MVS IPSenderSvc-nnnn ASIMVSSenderSvc-nnnn Tivoli BSM MVSSenderSvc-nnnn ASIStagedEventLoader Tivoli BSM Staged Event Loader ASIMVSIPListener Tivoli BSM MVSIPListener ASIAgentListener Tivoli BSM Agent Listener ASIRuleSvc Tivoli BSM Rule Server ASITaskServer Tivoli BSM Task Server ASIEventEnablement Tivoli BSM Event Enablement TSDEventHandlerSvc Tivoli BSM TSD Event Handler ASICommonListener Tivoli BSM Common Listener ASIConsoleServerV2 Tivoli BSM Console Server V2
Log prefix LS MVSL_nnnn_ MVSE_nnnn_ MVSURS MVSS_nnnn_ MVSS_nnnn_ SEL IPL AL RLS ihstsmsg.log ihstserr.log ihseemsg.log ihseeerr.log TBSMTSD.log CL ASICLTransportn.log ConsoleServer\TBSMServ ern.log
The logging level for an IBM Tivoli Business Systems Managerbased 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.
44
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 %m %d %H %M %S %t %O DBG INF NOT ERR WRN CRT %o %i %F %L Year Month Date Hour Minute Second Microsecond Record types: debug informational notice error warning critical Priority, which indicates what logging level will show this type of record Thread ID Source program name Line number in the source program
2.3 Distributed resource feeds

The 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.
45
Tivoli Management Region (TMR)
IBM Tivoli Monitoring (ITM) Tivoli Management Framework
APM Instrumentation TBSM Task Server (ihscts) Tivoli Distributed Monitoring Classic
Tivoli Enterprise Console (TEC)
TBSM Event Enablement (ihstdmai)
Tivoli Netview Distributed BMC PATROL
Generic TEC Events CA Unicenter
Net IQ Tivoli Manager for Products
Agent Listener
Common Listener
TBSM Database Server
TBSM Servers
Figure 2-7 Flowchart for distributed system
2.3.1 Agent Listener

The 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
46
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 instrumentation
APM 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.
organizes
Application (GDF) Business Subsystem (BSSDF)
Business System (BSDF)
isComposedOf
isComposedOf
Software Component (CDF)

isComposedOf
Business Component (BCDF)
mapsToSoftwareComponent
Business Mapping (BMDF)
mapsToBusinessComponent
Figure 2-8 AMS description files
47
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 bsdf bssdf bmdf bcdf gdf TBSM definitions Business System View definitions, depending on the type: Business System, Application, or Middleware Business System View definitions Ties the component to its Business System View and provides instance filtering for the Business System View No correlated IBM Tivoli Business Systems Manager definitions are created Defines and provides the name of the default task library
48
AMS filetype cdf
TBSM definitions 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.
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
Exit ihstetec ihstmtec ihstctec ihststec Input event type APM Heartbeat APM Threshold APM Connection Change APM System layer TBSM event type APM Heartbeat APM Threshold - (not used in TBSM) - (not used in TBSM)
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

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. 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
49
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 interface

The 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 objects
This 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.
50
2.3.2 Common listener

The 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.
Application
TBSM adapter
transport layer
Common listener TBSM Database
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.
51
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.
52
2.4 Mainframe (z/OS) resource feeds

Mainframe component connectivity is shown in Figure 2-10.
z\OS
WebSphere for OS/390 DFSMShsm SMS
TBSM SOURCE/390
MVS Console Messages and Commands
XRC
RODM CICSPlex System Manager for OS/390 Resource Management Facility OMEGAMON
EKGNotify
CPSM API
SOURCE/390 Object Pump
GPMSERVE
3270 screen
External Data Interface (EDI) Program-toprogram Interface (PPI)
CICS Transient Data Tivoli Workload Scheduler SA/390 V1R3 and other automation tools CICSPlex
Automation EDI interface
SOURCE/390 Dataspace Tivoli NetView for z/OS SOURCE/390 Object Server
IMS
DB2 System Automation for OS/390 V2R1
GTMAOPE0
TCP/IP NETCONV
SNA
TBSM Servers
MVS IP Listener Host integration Server
Task Server
Database Server
Event Server
Figure 2-10 z/OS components and feeds
53
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 components

Source/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 subsystemssuch as storage information (DFSMS), extended recovery (XRC), and WebSphere informationas well as general JES and z/OS information, are read through the extended MCS console interface.
54
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 Omegamons 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.
GTM5000I GTM4600I GTM4110I GTM5002I GTM5101I GTM5030I GTM5010I
TBSM DATASPACE INITIALIZATION STARTING EXTENDED RECOVERY ENVIRONMENT ESTABLISHED GTMDSPC , USING ID 01 PROCESSING PARMLIB MEMBER: PDSC6900 TBSM DATASPACE CREATED, SIZE= 42467328, ORIGIN=00000000 MODIFY INTERFACE ESTABLISHED, CONSOLE COMMUNICATION AVAILABLE TBSM DATASPACE INITIALIZATION COMPLETE
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.
55
GTM7500I INITIALIZATION IN PROGRESS GTM4600I EXTENDED RECOVERY ENVIRONMENT ESTABLISHED GTM4110I GTMSRVR , USING ID 01 GTM7508I TBSM SERVER DETECTED, JOBNAME=GTMDSPC GTM4403I Q WARM STARTED, QADDR=00001000, ALET=01FF001B, SIZE=100 PAGES, ID=GTMSRVR GTM8205I GTMIPSND : READY TO TRANSMIT TO 9.3.5.11 PORT(1022) GTM8252I GTMIPRCV : LISTENING ON PORT 1024 GTM4403I Q WARM STARTED, QADDR=00071000, ALET=01FF001B, SIZE=50 PAGES, ID=GTMLOG GTM4200I ALLOCATION SUCCESSFUL, DDNAME=ACC1LOG , S99ERROR=0000, S99INFO=0000, DSNAME=GTMV2R1.SC69N.SRVR.LOG1 GTM4010I TBSM INITIALIZATION COMPLETED
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.
56
GTM7500I INITIALIZATION IN PROGRESS GTM4600I EXTENDED RECOVERY ENVIRONMENT ESTABLISHED GTM4110I GTMPUMP , USING ID 01 GTM7508I TBSM SERVER DETECTED, JOBNAME=GTMDSPC GTM4403I Q WARM STARTED, QADDR=00066000, ALET=01FF0010, SIZE=10 PAGES, ID=GTMPUMP GTM7801I STORAGE ALLOCATED FOR 10,016 TRAPS GTM7524I VTAM 3270 SERVICES ARE NOT AVAILABLE MN JOBNAMES,T MONITOR SESS,T IEA630I OPERATOR TM39069 NOW ACTIVE, SYSTEM=SC69 , LU=TM39069 GTM7545I TM69 : SUBSYSTEM INITIALIZED GTM7815I TBSM HAS CONNECTED TO RODM : RODM GTM7890I PPI RECEIVER IS ACTIVE GTM7501I RUNNING INITIAL REXX EXEC : GTMRX004 GTM0001I TBSM INITIALIZATION STARTED - 4 Dec 2002 11:05:29 GTM0002I SYSTEM WAS IPL'D ON 10/23/2002 (102302) AT 16:52:42 GTM0003I TBSM IS RUNNING ON SYSTEM SC69 GTM2101I LOG PROCESSING IS AVAILABLE. DDNAME = ACC1LOG GTM2102I DSNAME = SYSOUT(A) GTM2104I THE LOG WILL BE CLOSED AND OPENED ON THE FOLLOWING INTERVAL: 04:00:00 GTM1620I OBJECT PUMP TO OBJECT SERVER HANDSHAKE STARTED GTM0220I TBSM LOGON PROCESSING INITIALIZATION STARTED ... GTM1001I TBSM EVENT MANAGER INITIALIZATION STARTED ... GTM9520I TBSM COMMAND PROCESSOR INSTALLED GTM0990I TBSM INITIALIZATION COMPLETED GTM1770I ALL REQUIRED SHARED VARIABLES HAVE BEEN REGISTERED, PROCESSING CONTINUES GTM1780I OBJECT PUMP/OBJECT SERVER IS REQUESTING OBJECTS
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 connection

The connection to IBM Tivoli Business Systems Manager servers is shown in Figure 2-14 on page 58.
57
Object Server
Object Server
VTAM
TCPIP
SNA Server
Event Server SNA Client TP Start
Event Server
MVS Sender
MVS Listener
MVS IP Sender
MVS IP OS Listener
Upload queue
Receive queue
Upload queue
Receive queue
Enqueue Proxy Server
MVS Event handler
MVS Event handler
MVS Upload Rule Server
Source/390 programs (ksh)
Source/390 programs (ksh)
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.
58
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.
59
2.4.3 Object registration process

In 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.
01/01
OS identification
OS/390 -> WinNT
WinNT -> OS/390
02/12
Variable creation ENT - COMP - MACH LPAR-OS
02/04
Request objects
02/05
TrapCreation All object traps under the OS (STC, batch, DB2,IMS, CICS etc)
02/09
Omegamon For each Omegemon objects
02/20 02/10
Batch Registration
02/15
TDQ Registration
RMF Registration including each metrics in RMF profile
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 x5C, EBCDIC xE0) and ended with a tilde character (~, ASCII x7E, EBCDIC xA1). 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.
60
Format type - Action type fields 02 Functional command 05 Object monitoring
A typical field 04 Field type object identification rest data
Tilde, end of message
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.
data sent from OS/390
data sent to OS/390
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 OSs 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.
~ I404FEI64\EVIT CANI54\I304FEI 64\EVITCA54\C0 004E400040\MPN 30\CTS20\50\20
~60 0042000040\66C S30\SO20\21\20 ~5000020 00040\YRAMIRP3 0\RAPL20\21\20 ~3000B100004 0\enihcaM66CS3 0\HCAM20\21\20 ~2000 90000040\OSTI3 0\PMOC20\21\20 ~100040000 040\semarfniaM 30\TNE20\21\20
~.9800=D ISA - 20.41.31 =EMIT - DETRAT S - MPN94\EVIT CA54\C0006E40 0040 \MPN 30\I304FEI64\C TS20\0266CS10\ 007029.20:41:3 10220000200\1 0\20
~600052 000040\66CS30\ SO20\3166CS10\ 249536.50:21:3 10220000200\4 0\20
~66CS30 \SO20\866CS10\ 835017.64:90:3 10220000200\1 0\10
~520MNF64\EVITCA54 \C0004E4 00040 \MPN30\CTS20 \50\20

61
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 02 03 04 Timestamp in the format of YYYYMMDDHH:MM:SS.UUUUUU Object type ID, similar to the content of cid column in obj_class table Object name. Native key. A unique 10-character object identification that is constructed of the hexadecimal value of the object ID and the class ID. State. The value that will go to the state attribute of an object. Message ID that is trapped. This must also exist in the MessageDescription table. Description text.
45 46 49
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 discovery

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

IBM Tivoli Business Systems Managers 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.
62
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.
63
Figure 2-18 The Resources view after the high-level object load
Subsystem bulk discovery

This 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.
64
//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-19 Parameters of the GTMAOPE0
GTMAOPE0 functions similarly to FTP (File Transfer Protocol). These are some of the acceptable parameters: TCP/IP_ADDRESS TCP/IP_PORT CODEPAGE COMMAND CONVERT TEXT FORMAT The address of machine that runs the MVS IP listener. Port number for the MVS IP listener; 1021 is the default. The codepage of the OS/390 prediscovery file. This parameter is used when the conversion is needed. Command alias that will be translated by the MVS IP listener to a certain Windows NT command. Whether to convert the data from the mainframe codepage to the codepage of the MVS IP listener. Whether the conversion is for binary data or text. 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.
65
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.
66
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.
67
2.4.5 Command support

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

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

The 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.
68
Linked Server
Bulk Copy Program (BCP)
TBSM
TBSM
TBSM
TBSM
SQL
SQL
SQL
SQL
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 approach

The 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) approach

The 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.
69
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 Managers 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 system

The 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
70
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
71
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
72
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
73
2.5.3 Health monitor

The 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
74
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
75
76
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
77
3.1 Microsoft SQL Server overview

Microsoft 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.
78
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 databases

IBM 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. 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. 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. Temporary loading database for SNA network objects from RODM. Temporary loading database for Tivoli Workload Scheduler (used to be called Tivoli OPC) data. Database for the help and reporting system resources. Contains the processing queues of IBM Tivoli Business Systems Manager. Each queue isrepresented in three tables: Pending<qtype>, LastProcessed<qtype>, and Processed<qtype>. Not used.
ASIRuleSvc
Meta
RODM, RODMLoad OPCLoad WebServer ObjectEvents
ObjectQueues
3.3 Object implementation

IBM 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.
80
3.3.1 Important information sources

Tables 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 link_type isa_table obj_link_table link_chain isa_chain_table method_table Primary table that contains an objects class definition. Primary table that describes existing link types. Inheritance structure table. Lists all possible links between object types. Generated containment structure table. Generated inheritance structure paths. 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. 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. 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.
GEMIDLookup
GEM_DMtoCID
Tables provided with the Common Listener implementation: CL_AutoPlacement Mapping of instrumentation to enterprise CL_LinkRules CL_Options CL_Registration Rules for creating a link based on the cid and other attributes Common Listener global options All known registered connectors
81
CL_RegistrationList List of objects registered through the common listener CL_Severities CL_Stage Platform-specific severity mapping to alert state List of staging transactions whose data resides in the tables CL_StageBulkData, CL_StageDeltaData, and CL_StageEvData Status of staging load processes
CL_Status
3.3.2 Object structure implementation

An 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 cno cname cdesc Class ID, which is a 4 characters name of the object class Class number, which is a numeric identifier for each cid Class name, which is the long name for a cid 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 <cname>_C A single row, single column table that contains the next instance ID for the specific cid. Primary table for the class that stores all the standard attributes for instances of this class. This table is indexed with the instance ID. Attribute table for all non-standard attributes of a class. Provides such class-wide information as status propagation information, icons, and other attributes. 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.
<cname>_A <cname>_S <cname>_V
82
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 Managers All Resources View. Business Systems containment link. These are the links that build the IBM Tivoli Business Systems Manager business systems hierarchy structure. 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. Topology link, used for the new Topology views in IBM Tivoli Business Systems Manager V2.
LOBC
LOB
TOPO
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 ------ENT IPNW NREG NREG dst_cid ------NREG NREG NLOC 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
83
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> asisp_create<cid> delete_<cid> asisp_view<cid> Allocates a new ID and increment the <cid>_ID table Creates a new instance of cid Deletes an instance of 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 implementation

A 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
84
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 objects

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

IBM 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.
85
Figure 3-2 on page 86 shows a sample of the containment hierarchy.
Enterprise
Complex
Network Region Network Location
Machine LPAR OS
Batch Job Set
Batch Schedule Set Batch Schedule NT Server
UNIX
Network Node
Batch Job File
IDMS
Sybase
STC
R3 R3 DB CICS
MQSeries MQManager
GEM objects
IMS objects
DB2 objects
R3 AS MQ Queue MQ Channel MQ Process
Figure 3-2 Part of TBSM containment hierarchy
86
The inheritance hierarchy has several abstract object classes. Part of the inheritance hierarchy is shown in Figure 3-3 on page 87.
Base
CICS Object
Directly Contained Object
DB2 base
MVS Registerable
Windows Viewable Object
Event
MVS Job
Managed Object
Exception
Message
STC
Managed Object 2
IMS Base
RODM Managed Object
SNMP Managed Object
GEM Base SC
GEM GEM SC
GEM DM SC
GEM Generic SC
GEM MF SC
GEM Extended Generic SC
Figure 3-3 TBSM inheritance hierarchy
3.4 Status propagation

One 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.
87
Ch
ild
ev e
nt
Exception m atrix
High Red Yello w M edium Low
O bject
A lert S tate S tate P rio rity
C hild Event m atrix

Hig h Red Ye llo w M ediu m Low
ag e
en
ev
ss
ild
Me
Ch
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. 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. 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.
State
Object priority
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
88
Ex
ce
pt
io n
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 objects 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 exceptions 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 events Alert State and Priority. When the child event
89
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.
Event received
Type = Message
Yes
Apply Alert State and State to Object
No
Priority = Critical
Yes
No
Yes
Priority = Ignore
No Increase Counter in Exception Matrix based on its Priority and Alert State
No
Type = Child Event
Yes
Increase Counter in Child Event Matrix based on its Priority and Alert State
Exceed Exception Limit?
Yes
Yes
Exceed Child Event Limit?
No
No
Apply Alert State to Object
Generate Child Event
Log event and continue
Figure 3-5 Propagation algorithm
90
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 resources

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

The 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.)
GEM Software Component GMSC
GEM Generic GMGN GEM AMS object GMGM GEM Generic GMGX Distributed Monitoring GMDM GEM Mainframe GMMF
Gxxx Gxxx Gxxx
Gxxx Gxxx Gxxx
Gxxx Gxxx Gxxx
Gxxx Gxxx Gxxx
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
91
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. The class table that contains the instances of this class. 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.
G02Hcname_C G02Hcname_S
92
3.5.2 AMS tables

For 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
93
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.
94
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. The Network Region object name is derived from the location. The default derivation is to take the second qualifier of the location name.
GEM_LocationToRegion
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 resources

The 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.
95
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
96
An events 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 launcher

To 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.
97
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.
98
isa _ c h a in
cid = S T C
1
c id
S TC S TC S TC C IC S C IC S C IC S
b as e _c id
S TC M JO B TREO C IC S M JO B TREO
...
...
2
M e n u Ite m
ob j_c id STC TREO TREO STC M JO B B AS E o b j_ id 0 0 0 121 0 0
id c o n trol_ id la b e l p a re nt_ id o rd e r fla gs
1 2 3 4 5 6
c m d.ex e http://tivm gr 1/as i/ind ex .as p O nV ie w H y per V ie w s h.e xe R un S tore dP roc ed ure
C om m an d D oc - in dex H yp erV iew K o rn s h ell R un Te s t D oc u m entatio n 6 9
3 4.00 .0 0.00 2 2.10 .0 0.00 2 7.10 .0 0.00 7 0.00 .0 0.00 9 9.00 .0 0.00 2 2.00 .0 0.00
2 2 56 10 24 2 40 96 8
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. 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 obj_id Command class. The obj_cid can be a super class of a real object. 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 control_id Command ID. Contains the command line, stored procedure, or command text for processing or execution.
99
label parent_id item_order flags
Shows the text that we see in the context menu. Indicates the parent command ID for the submenu. Indicates the command order that should be shown in the menu. Commands may be stacked to nine levels. 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 0x00000002 MI_SEPARATOR; this is a separator entry. MI_COMMANDLINE; the control_id contains the command line string to be executed in the database server by CMD.EXE. MI_DIALOGBOX; opens a dialog box (must define the class for Java console). MI_SUBMENU; indicates that this entry is a staging entry with a submenu attached to it. MI_BUILTINONITEMSELECT; reserved for menu from IBM Tivoli Business Systems Manager. MI_BUILTINONMENUCREATE; reserved for menu from IBM Tivoli Business Systems Manager. MI_DISABLEONSECURITYFAIL; disable this entry when the security flag is not completed. MI_ELIMINATEOVERRIDE; eliminate this entry when there is an override menu item. 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. MI_INVOKEMETHODINVIEW; runs method and displays the result in a class for Java console. MI_ACTIVEXCONTROL; runs an activeX console (not used in the Java console). MI_HYPERVIEW; invokes the hyperview engine. MI_INVOKEMETHOD; invokes an internal objects method as defined in the method table (no graphical display). MI_DISABLEIFNOTEXIST. MI_GRAPHVIEW.
0x00000004 0x00000008 0x00000010 0x00000020 0x00000040 0x00000080 0x00000100
0x00000200 0x00000400 0x00000800 0x00001000
0x00002000 0x00004000
100
0x00008000 0x00010000 0x00020000 0x10000000 0x20000000 0x40000000
MI_MENUBARONLY; this entry is only for the menu bar, not applicable for context menu. MI_INVOKEMETHODINTEXTVIEW; invokes a method and displays the resulting text. MI_APPLAUNCH; launches a GUI application in the workstation. MI_VISIBLESELF; visible for the physical object. MI_VISIBLEAGGREGATE; visible on an aggregate object. 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 -l -c -m -x -w -r -g -a Entry name Platform Connection type Port numbers Timeout in seconds Revision number Command line string Command line argument
AddAppLauncherMenuItem.sh with arguments: -n -c -l -r -a -f -m Entry name Class ID of the object Menu text Control ID for the menu item Installs menu items for all installed languages Specifies an input file containing new entries Name of the menu item (optional)
DeleteAppLauncherMenuItem.sh with arguments: -n -r Entry name revision number
101
DeleteAppLauncherMenuEntry.sh with arguments: -n -c -m -r Entry name Class ID Name of menu item Remove parent menu if empty
3.7.2 z/OS subsystems command support

Command 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 command
The 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 procedure
We 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).
102
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 OUTPUT AS 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 @ReturnCode GO
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.
103
6. Construct the command string and pass it to the asisp_tgmtask390 procedure to invoke it.
Method definition
The 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 definition

Now 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 x50010000 or 1342242816.
104
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
105
Sample result
We implement the command to the GTMPUMP9 started task as shown in Figure 3-17.
Figure 3-17 Invoke MVS D A
106
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
107
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 support

The 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 tmeendpointoid endpointhostname tmeid, tmepw task information The event enablement or task server hostname Object id of the endpoint, in the format of <tmr num>.<dispatcher num>.0+ Endpoints label User ID and password to access the TMR Task name, task library name, and task arguments
108
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/sh if [ x\"$OS\" = x\"Windows_NT\" ] ; then CMD.EXE /C DIR C: else df fi exit 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 OUTPUT AS 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
109
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
include(BusinessObject.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
110
The resulting menu item is shown in Figure 3-21.
Figure 3-21 Context menu for DIRCDrv
111
The output in the Task Monitor is shown in Figure 3-22.
Figure 3-22 Execution result for DIRCDrv
112
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: Users 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
113
4.1 Java console

The 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.
Database Server
Java Console
Console Server
Java Console
Java Console
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 users authority within the console.
114
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 users 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 Resource type window Shows tasks that have been executed and the latest results. Shows the various IBM Tivoli Business Systems Manager resource types (object classes). You can modify some of their settings. Shows the physical object hierarchy that IBM Tivoli Business Systems Manager is managing. Used for setting various console properties.
All Resources Preferences
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.
116
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 objects 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.
117
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.
118
Figure 4-8 Expanded console in debug mode
For more information about using the Java console, refer to IBM Tivoli Business Systems Manager: Users Guide, GC32-0798.
4.2 Web console

The 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
119
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 browsers 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.
120
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.
121
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.
122
The superadmins list is shown in Figure 4-11.
Figure 4-11 Primary options
123
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
124
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
125
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
126
A sample of the Business System View is shown in Figure 4-15.
Figure 4-15 Business System View
127
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: Users Guide, GC32-0798.
128
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.
129
5.1 Planning overview

Almost 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 enterprises 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 Personnel
The 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.
130
Additionally, the IBM Tivoli Business Systems Manager: Administrators Guide, GC32-0799 is required reading for both implementers and the systems 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: Administrators 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: Administrators 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 teams skill base should include at least these three backgrounds.
5.3 Hardware specifications

Capacity and specifications for the IBM Tivoli Business Systems Managers servers must be decided before implementation can begin. This requires careful estimation and planning for the servers 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 servers 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.
132
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 connectivity

As 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 Managers 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.
133
5.5 Software level and prerequisites

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

Complete 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.
134
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 inventory

From the Tivoli Framework, you can issue wlsinst command to check the prerequisites for your Tivoli software level.
ITM profile information

To 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 profiles contents.
TEC classes and rules

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

You must obtain the primary maps and sub-areas that NetView monitors.
5.5.2 Planning for mainframe systems

The 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
135
Mainframe and Logical Partition (LPAR) information

This 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)
Complex Machine LPAR Operating System Version and description IP address SNA information:
SC66
ITSO SC66Machine SC66 z/OS v1.1 Lab Test system 66 9.12.14.22 Not applicable
MVS1
Boulder RETAIN-Test PRIMARY OS/390 v2.10 SysProg Test system 9.99.64.54 Not applicable
VTAM CP Source/390 majornode IBM Tivoli Business Systems Manager SNA server LU majornode
SYSPLEX CICSPLEX Job Entry Subsystem Network management System Automation Job Scheduler MVS perfomance monitor Database subsystem Transaction Program subsystem Subsystem performance monitors Security WTSCPLX1 SC66PLX JES2 NetView for z/OS Not applicable TWS 8.1 RMF Not applicable CICS CICSPlexSM RACF Not applicable Not applicable JES2 NetView for OS/390 SA/390 2.1 Not applicable RMF DB2 and IMS Not applicable Not applicable RACF
136
Subsystem information and naming convention

If 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
Resource
DB2 IMS CICS Monitor STC
Name pattern
DB% IMS??% ?CICS?? OMEG% %
Subsystems checklist
Many of the MVS subsystems consist of further components, which are shown in the following tables.
IMS
Table 5-3 lists the IMS subsystems checklists for IBM Tivoli Business Systems Manager implementation.
Table 5-3 IMS subsystems checklist
Subsystem
IMS1A IMS2A
Version
7.1 7.1
OTMA
Yes Yes
OS
MVS1 MVS1
DB2
Table 5-4 lists the DB2 subsystems for discovery.
Table 5-4 DB2 subsystems checklist
Subsystem
DB2A DSN1 DSN2 DSN3
Version
6.1 6.1 6.1 6.1
Performance monitor
DB2PM No No No
Data sharing
No No No No
OS
MVS1 MVS1 MVS1 MVS1
Discovery
Yes No No No
137
Subsystem
DSN4 DSN5
Version
6.1 6.1
Performance monitor
No No
Data sharing
No No
OS
MVS1 MVS1
Discovery
No No
CICS
Table 5-5 on page 138 lists the CICS subsystems and their corresponding components.
Table 5-5 CICS subsystems checklist
Subsystem
SC66C PCICS01
Version
7.1 7.1
CICSPlex
SC66PLX Not applicable
Performance monitor
CICSPlexSM Not applicable
OS
SC66 MVS1
5.6 Operators and users

You 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
138
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 requirements

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

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

Designing a BSVs 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
139
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 BSVs child event threshold.
5.7.3 Business System View structure

BSVs 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 Bankings BSV consists of: Remote Access service on castore Remote Access service on polluce HYPERDB DB2 database APPL CICS transaction
140
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
141
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
142
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
143
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
144
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
No hierarchy Original hierarchy Inverted hierarchy Separate BSV
Cause effect
No Some Yes Some
Identification
No Yes Yes Yes
Maintenance
Automated No No Automated
Business impact
Not affected Not affected Great impact Not affected
145
146
Part 2
Part
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
147
148
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
149
6.1 Hardware and software prerequisites

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

Basic 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.
150
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
SQL Database Server
CPU
Dual 700MHz 1-MB Cache Pentium III Xeon CPU on a Quad Processorcapable system Single 866MHz Pentium III CPU on a Dual Processorcapable system
Memory
4 GB RAM
System drive
MS Windows 2000 or NT 4 Server OS. TBSM Database base services. Should have about 2 GB of free space. MS Windows 2000 or NT 4 Server OS. TBSM Console, Propagation or Common Listener base services. Should have about 2 GB of free space. MS Windows 2000 or NT 4 Server OS. TBSM Reporting System base services. Should have about 2 GB of free space. MS Windows 2000 or NT 4 Server operating system. TBSM Web console base services. Should have about 2 GB of free space. MS Windows 2000 or NT 4 Server operating system. TBSM Health Monitor Server base services. Should have about 2 GB of free space.
Data drive
SQL Database software and database. Should have at least 72 GB of free space. Should have at least 4 GB of free space.
Console or Propagatio n server
1 GB RAM
History server
Dual 700MHz 1-MB Cache Pentium III Xeon CPU on a Quad Processorcapable system Single 866MHz Pentium III CPU on a Dual Processorcapable system Any Pentium III or IV CPU-based system
4 GB RAM
SQL Database software and database. Should have at least 108 GB of free space. Should have at least 4 GB of free space.
Web console server
1GB RAM
Health Monitor server
64MB or more RAM
4 GB free space
Chapter 6. Base services implementation
151
6.1.2 Software components

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

This section discuss hardware and software configuration.
Hardware configurations
Table 6-2 shows the hardware configurations of the three servers running IBM Tivoli Business Systems Manager system in our lab.
152
Table 6-2 TBSM server configuration running in the lab

Component SQL database server ibmtib5
Dual 700MHz 1-MB Cache Pentium IV CPU on a Dual Processorcapable system 1 GB RAM 4GB drive running MS Windows 2000 Advanced Server OS, System paging swap file, and TBSM/D Database base services.
Console and propagation server ibmtiv3

Dual 700MHz Pentium IV CPU on a Dual Processorcapable system 1 GB RAM 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. None.
History and HMS server ibmtiv6

Dual 700MHz 1-MB Cache Pentium IV CPU on a Dual Processorcapable system 1 GB RAM 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. None.
CPU
Memory System Drive
Data Drive
8.5 GB drive contains SQL software and database.
Software components
Table 6-3 shows the installed prerequisite software in our servers.
Table 6-3 Prerequisite software components installed
Software component
Operating System SQL Database Server Toolkit Windows Resource Kit JDBC Driver
SQL database server ibmtiv5

Microsoft Windows 2000 Advanced Server with Service Pack 2 Microsoft SQL 2000 Server Enterprise Edition with Service Pack 2 MKS Toolkit for System Administrators Version 8.0 Microsoft NT 4.0 Resource Kit Version 4.0 Supplement Three Not applicable

Microsoft Windows 2000 Advanced Server with Service Pack 2 Not applicable

Microsoft Windows 2000 Advanced Server with Service Pack 2 Microsoft SQL 2000 Server Enterprise Edition with Service Pack 2 MKS Toolkit for System Administrators Version 8.0 Microsoft NT 4.0 Resource Kit Version 4.0 Supplement Three Not applicable
MKS Toolkit for System Administrators Version 8.0 Microsoft NT 4.0 Resource Kit Version 4.0 Supplement Three Microsoft SQL Server 2000 Driver for JDBC
153
Software component
IIS Option Pack
SQL database server ibmtiv5

Not applicable

Microsoft Internet Information Server (IIS) Version 5.0

Microsoft Internet Information Server (IIS) Version 5.0
6.2 Prerequisite software components installation

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

After 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
154
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.0

Follow the installation steps supplied with the product. The installed components must be in the Windows system path.
6.2.3 Windows Resource Kit

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

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

Follow 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
155
6.2.6 Microsoft SQL Server

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

Exit 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\ 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. 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.
156
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
157
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.
158
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
159
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
160
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
161
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.
162
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
163
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
164
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
165
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
166
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
167
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
168
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. 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.
Changing SQL Server authentication password

1. 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.
169
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
170
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.
171
Applying Microsoft SQL 2000 Server Service Pack 2

The following procedure upgrades Microsoft SQL Server to Service Pack 2 level. 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. 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 Options

To 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.
172
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
173
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
174
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
175
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. Note: It would be advisable, though not necessary, to reboot the server before proceeding with base services installation.
6.3 Database server installation

The 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.
176
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
177
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
178
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
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. 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.
179
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
180
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
181
8. Select Custom Setup type as shown in Figure 6-33. Click Next to continue.
Figure 6-33 Setup type selection
182
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
183
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
184
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
185
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.
186
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
187
Note: Now configure the database server with IBM Tivoli Business Systems Managers supplied seed database. 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
188
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 SchemaTypes SchemaMessages master master, tempdb, model 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.
189
Figure 6-42 Services setting
6.4 Console and propagation server installation

Most 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.
190
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.
191
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
192
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.
193
Figure 6-47 Services list for console and propagation server
The IBM Tivoli Business Systems Managerrelated groups are shown in the Computer Management display in Figure 6-48.
Figure 6-48 TBSM operators groups
6.5 History server installation

The 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.
194
Figure 6-49 History Server component selection dialog
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. 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 SchemaTypes SchemaMessages master master, tempdb, model master
195
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
196
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
197
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_ibmtiv6 Setting 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_V Done! 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.
198
Table 6-4 Database attributes for reporting system

Parameter
Driver Server Name User ID Password Database name
Default data
(SQL Server) IBMTIV6 sa sa_ibmtiv6 Object
Live data
(SQL Server) IBMTIV5 sa sa_ibmtiv5 Object
Web server
(SQL Server) IBMTIV5 sa sa_ibmtiv5 WebServer
6.6 Health Monitor Server implementation

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

HMS 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. Note: Other, previously installed components will appear as seleted in this dialog. Do not clear these other components from the list.
199
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.
200
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
201
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 Customization
You 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 Application AppParameters <drive>:\TivoliManager\Mgmt\HMS\ShellScript sh.exe 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,
202
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
203
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
204
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
205
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
206
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
207
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 implementation

To 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.
208
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
209
7.1 Tivoli Enterprise Console overview

Tivoli 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.
TEC
APM Heartbeat ihstmtec
interapp
APM Threshold ihsthtec
Sentry 2.0 Base
ihstztec
Event Enablement
ihstdmon
EVENT ihstttec
OS390
ihst3tec
TBSM setemsg status event
gemeeconfig
tbsmstatus Task Server
wpostemsg
tgmtask
TBSM Database
Note Change Trigger Operational commands
TBSM Agent Listener
Figure 7-1 Event flow for IBM Tivoli Business Systems Manager integration
210
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 Sentry events Generic events TBSM events interapp.rls ihstdmon.rls ihstdmon.rls 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 connection

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

Event 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.
212
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 ID

We 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.
213
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
214
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.
215
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.
216
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 rules

In 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.
217
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>bash bash$ ./ihsttec.sh ########################################################### Creating GemEvent rules data base. ATTENTION: If you are installing multiple TMRs, have you updated this 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.sh If 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 to Global Enterprise Manager (GEM)? Enter 'Y' if GEM will be used. Enter 'N' if GEM will not be used. The default is: N n Please enter the name of the TEC Rules Base to copy as a starting point for creating the GemEvent rules base. If no name is entered we will use the name: Default NewDefault 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: N y Should TEC status changes (ACK, RESPONSE, CLOSED) associated with APM Threshold events be sent to TBSM? If no is specified, then APM Threshold events will be automatically closed in TEC when they are received. Enter 'Y' send status events to TBSM. Enter 'N' to not send status event to TBSM.
218
The default is: Y y 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: N y Does your TEC receive OS/390 events from TBSM using the TEC EIF interface? Enter 'Y' if this feature is configured. Enter 'N' if this feature is not used.. The default is: N n Do your DM profiles include NT Monitoring Collections? Enter 'Y' if the do. Enter 'N' if they do not. The default is: N y --> --> --> --> --> y 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: N
Do your DM profiles include Windows/2000 Monitoring Collections? Enter 'Y' if the do. Enter 'N' if they do not. The default is: N y --> 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 GemEv ent. --> The default is: N y Do your DM profiles include OS/2 Monitoring Collections? Enter 'Y' if the do. Enter 'N' if they do not. The default is: N n
219
Do your DM profiles include UNIX Monitoring Collections? Enter 'Y' if the do. Enter 'N' if they do not. The default is: N Do your DM profiles include Univeral Monitoring Collections? Enter 'Y' if the do. Enter 'N' if they do not. The default is: N n Do your DM profiles include OS/400 Monitoring Collections? Enter 'Y' if the do. Enter 'N' if they do not. The default is: N n Create the GemEvent Rules Base Checking to see if GemEvent exists Rule 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 scripts completion results in the new rule base called GemEvent, shown in Figure 7-8 on page 221.
220
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.
221
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
222
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 CLOSED OPEN RESPONSE Custom_status An operator has acknowledged the event and assumed responsibility. The event has been resolved. No action has been taken on the event. A rule has responded automatically to the event. 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,
223
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,
224
'../../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 listener

The 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 ibmtiv9s 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:
225
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 integration

IBM 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 */ */
226
/* 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.
227
Example 7-6 DB2_send_to_TBSM.sh

#!/bin/sh if [ "$1" != "" ]; then EVENT_CLASS=$1 fi # The following will happen with clearing events if [ "$application_version" = "" -o "$application_version" = "N/A" -o "$application_version" = "n/a" ]; then application_version="7.x" fi TMP=`wtemp` LOGDIR=${TMP}/DB2 if [ ! -d $LOGDIR ]; then mkdir $LOGDIR fi LOG=${LOGDIR}/trace_itmDB2_send_to_TBSM.log exec 2>$LOG set -x SOFTCOMP_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;$o rigin" ${TMP}/${FILEPREFIX}_DISCOVERED_to_tbsm.file >/dev/null if [ $? != 0 ]; then echo "$application_class;$application_oid;$application_version;$application_label;$o rigin" >>${TMP}/${FILEPREFIX}_DISCOVERED_to_tbsm.file fi
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.
228
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
Databases: DB2 Databases: Oracle Databases: Informix Business Integration: WebSphere MQ
TEC setup task

DB2ManagerAdminTasks ECC_Configure_TEC_Classes ITMOracle Tasks ConfigureTECOracle IBM Informix Server Tasks Configure_TEC Configure Event Server menu from Monitoring for WebSphere MQ icon
TBSM disovery task

DB2ManagerAdminTasks ECC_TBSM_Discovery ITMOracle Tasks OracleTBSMDiscovery IBM Infomric Server Task. TBSM_Discovery MQS TBSM QMgr:Discover_Queue_Managers MQS TBSM Queue: Discover_Queues MQS_TBSM_Channel:Discover_Cha nnels MQSI Utility Task: MQSI TBSM Discover
Business Integration: WebSphere MQ Integrator
MQSI Event Tasks: Configure Event Server
229
Module
Web InfraStructure: Apache
TEC setup task

itmapache_tec_config_evtsvr.sh CREATE new_rule_base path rule_base_activation WebSphere Event Tasks Configure_Event_Server
TBSM disovery task
itmapache_tec_config_evtsvr.sh CREATE new_rule_base path rule_base_activation

WebSphere Application Server Utility Tasks Send_WebSphere_Discovery_Events _to_TBSM ./itmiis_tbsm_discovery.sh
Web Infrastructure: WebSphere Application Server Web Infrastructure: Microsoft IIS Web Infrastructure: iPlanet Web Infrastructure: WebLogic Application: SAP Application: Siebel
itmiis_tec_config_evtsvr.sh CREATE new_rule_base path rule_base_activation WebLogic Event Tasks icon. WebLogic_Configure_TEC
./itmiplanet_tbsm_discovery WebLogic Server Tasks: WebLogic_TBSM_Discovery mySAP Configuration Tasks Synchronize mySAP Objects on TBSM Siebel Event Tasks Siebel_TBSM_Discover_Job
WebLogic Event Tasks: WebLogic_Configure_TEC

mySAP Configuration Tasks Configure Event Server Siebel Event Tasks Siebel_Configure_Event_Server_Job
7.4 Creating a generic component

In 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 U user P password Specifies the name of the SQL server system Specifies the SQL user ID to the SQL server system Specifies the SQL password to the SQL server system
230
m manufacturer p product v version
Specifies the manufacturer of the software component Specifies the name product of the software component 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.
231
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')
232
) ).
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: Administrators 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#ibmtiv9region";event_key="Processor=0;";eventid="1872068515";severity="CRITICAL";hostn ame="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 2002 event_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 2002 status=SUCCESS; exit_status=0; message=[ ];
233
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
234
Looking at the properties display, you see both the event that caused the objects 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 monitors

In 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.
235
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 -l gemsp_list_DMtoCID: DM profile name Manufacturer Product -------------------- ------------ -------------------ClassicSentryProfile DM ClassicSentryProfile
Version ------1.0
DM only ------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
236
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. 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. 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:
237
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
238
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.
239
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
240
ss=w2k_MemAvailBytes;new_admin='TBSM:administrator';new_status=ACK;origin=9.3.4 .55;END ### END EVENT ### PROCESSED 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_cla ss=w2k_MemAvailBytes;new_admin='TBSM:administrator';new_status=CLOSED;origin=9. 3.4.55;END ### END EVENT ### PROCESSED
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
241
[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 Troubleshooting
If 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. 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. 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.
242
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 ### END EVENT ### PROCESSED
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;
243
date_reception=1038357634; # Nov 26 18:40:34 2002 event_handle=1; task_number=1; command='../../TDS/EventService/ihstztec '; start_time=1038357634; # Nov 26 18:40:34 2002 status=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] => [2] => [3] => [4] rule set tbsmstatus rule set interapp rule set ihstdmon -> 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
244
[27]=> [28]=> [29]=> [30]=> [31]
rule set ihstdmon rule set tbsmstatus rule set interapp rule set ihstdmon -> 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
245
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|GetNext Event: 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|GetNext Event: waiting for message 2002/12/03 13:36:50|625|DBG|0|AL|774|B:\ole\asiruleengine\ASIRuleEngineObj.cpp|307|GetNext Event: got message "(run)" 2002/12/03 13:36:50|671|DBG|0|AL|774|B:\asidb\include\ASIDB\ASISQLDBC.ado.cpp|805|adCmdSto redProc(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)*/,
246
@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.
247
248
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
249
8.1 IBM Tivoli Monitoring integration

IBM 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 resourcefunctions 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.
250
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 configuration

In 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.0

With 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.
252
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.
253
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.
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 ITM

The 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.
254
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.
255
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. 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. 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 processes

The 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.
256
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: 2852 Command line: tmnt_tbsm_eng.exe Base 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
257
Command line: C:\Tivoli\bin\w32-ix86\TME\Tmw2k\tmnt_tbsm_wrapper Base 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.
258
8.2.4 Configuring the IBM Tivoli Monitoring for 5.1.1 TBSM Adapter
The 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.
Note: This adapters 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. 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. Filename to which the trace messages from the adapter will be written. The default is dm.trc.
trace.filename
259
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. 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. 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. 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.enable
adapter.trace.level
transport.trace.level
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 dmml.trace_level Specifies the size of the profile distribution trace in bytes. The default is 500000 bytes. 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 = LocalAdapter adapter.working.dir = C:/Tivoli/db/ibmtiv9.db/dmml soap.envelope = <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Bo dy> loggingmode.default = false loggingmode.filename = DM.log trace.filename = DM.trc adapter.trace.enable = false transport.trace.enable = false adapter.trace.level = low transport.trace.level = low adapter.xml.validation = false
260
transport.class.name = com.tivoli.commonlistener.transport.mqe.client.ClientTransportMQe transport.local.ip.address = 9.3.4.59 transport.request.address = 9.3.4.59.DM.QM+DM.Q transport.request.port = 6969 transport.response.address = 9.3.4.59.DM.QM+DM.Q transport.response.port = 6969 transport.mqe.local.queue.store = file transport.mqe.remote.queue.store = file transport.mqe.usefiller = false transport.mqe.fileregistry = com.ibm.mqe.registry.MQeFileSession transport.mqe.maxchannels = 1 transport.server.mqe.address = ServerQM+ServerQ transport.server.mqe.port = 8082 transport.server.ip.address = 9.3.4.53 heartbeat.send_events_to_tbsm = false heartbeat.send_events_to_tec = false heartbeat.send_events_to_notice = true heartbeat.tec_server = not-configured tbsma.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 process

Once 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.
261
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 -b Processing 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 -v Processing ManagedNode ibmtiv9... Endpoint ibmtiv8 ibmtiv9
| HB status HBOff HBOff
| TBSM status Discovered Discovered
262
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 gateways $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.
263
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 Manager

IBM 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.
264
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.
265
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 -verbose ITM511Profile#ibmtiv9-region TMW_PhysicalDiskModel :Running
266
TMW_HighPhysicalDiskReadBytesSec TMW_PhysicalPossibleFrag TMW_HighPhysicalDiskXferRate TMW_HighPhysicalDiskWriteBytesSec TMW_SlowPhysicalDrive TMW_HighPhysicalPercentDiskTime TMW_Processor :Running TMW_ProcessorBusy TMW_HighProcesses TMW_CPUCantKeepUpWithHW TMW_HWKeepingCPUBusy TMW_BusyHardware TMW_HighPercentUsageDelta
100 100 100 100 100 100
% % % % % %
100 % (Processor=1;) 0 % 100 % 100 % 100 % (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
267
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 Listener

Now 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.
268
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. 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 1000000 wdmconfig -D tbsma.trace_level=2 wdmconfig -D adapter.trace.enable=true wdmconfig -D transport.trace.enable=true wdmconfig -D transport.trace.level=high wdmmn -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_n ame)<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>
269
<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 Utility Tasks']";tasks=" ['dm_mn_send_notice']") </desc> </tbsm> <tecstatus> <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>C alling Adapter::sendEvent(DM+ibmtiv9-9.3.4.53-1389241399-0000000023, ...). XML 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>
270
<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> <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 Utility Tasks']";tasks=" ['dm_mn_send_notice']") </desc> </tbsm> <tecstatus> <severity></severity> </tecstatus> </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
271
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> <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> <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 Utility Tasks']";tasks=" ['dm_mn_send_notice']") </desc> </tbsm> <tecstatus> <severity></severity> </tecstatus> </event>
272
</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
273
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/TBSM AWrapper.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> </id> <action>remove</action> <type>TMW_HighProcesses@TMW_Processor</type> <context>[666252843]Processor=0;</context> <tbsm> <type>EXCP</type> </tbsm> </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+6969 TransactionID: 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> <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>
274
</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.
275
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 sen dData SENDING DATA = <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/ soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encodin g/"><SOAP-ENV:Body><tbsm:sendEvent xmlns:tbsm="urn:tbsm:1.0"><event><time>10377 38248</time><id><class>OperatingSystem</class><instid>os_ibmtiv9</instid></id>< type>TMW_HighProcesses@TMW_Processor</type><context>[666252843]Processor=0;</co ntext><tbsm><type>EXCP</type><desc>High CPU Usage, High CPU Usage User Priv, an d High CPU Usage Process are exceeded on the processor 0. (;highprocesses= 2 .0000;idprocess= 204.0000;percentprocessortime= 98.0000;process="CSRSS&
276
quot;;processor="0")</desc></tbsm><tecstatus><severity>CRITICAL</seve rity></tecstatus></event><event><time>1037738253</time><id><class>OperatingSyst em</class><instid>os_ibmtiv9</instid></id><type>TMW_TaskResult@TMW_Processor</t ype><context>[666252843]Processor=0;</context><tbsm><type>EXCP</type><desc>The tasks associated to the event 'TMW_HighProcesses', have been submitte d for execution. (;eventtriggername="TMW_HighProcesses";return_codes= "[0]";task_libs="['IBM Tivoli Monitoring Utility Tasks&apos ;]";tasks="['dm_mn_send_notice']")</desc></tbsm><tecst atus><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 sen dData NOTE: THIS IS NOT A LOGGING SID = DM+ibmtiv9-9.3.4.53-1389241399-00000000 23 . . . 2002.11.19 14:38:30.734 com.tivoli.commonlistener.tbsmadapter.engine.XMLManager envelop mode = 12 text = <event><time>1037738309</time><id><class>OperatingSystem</class><instid> os_ibmtiv9</instid></id><action>remove</action><type>TMW_HighProcesses@TMW_Proc essor</type><context>[666252843]Processor=0;</context><tbsm><type>EXCP</type></ tbsm></event>
277
278
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.
279
9.1 What IBM Tivoli NetView is

In 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 IBMs 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).
N e tw ork D iscove ry R o o t C a use A n alysis SNMP M a na ge m e n t
N e tw ork M an agem en t
D istrib u te d M a na ge m e n t
T op o log y
Figure 9-1 NetViews 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. Proactively manages network resources through the Simple Network Management Protocol (SNMP)
SNMP management
280
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 NetViews 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
282
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, Users Guide for Beginners, SC31-8891 NetView for UNIX, Administrators Guide, SC31-8892 NetView for UNIX, Administrators Reference, SC31-8893 NetView, Web Console Users 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 configuration

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

This 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.
283
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 steps

We 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.
284
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.
285
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.
286
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
287
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.
288
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-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.
289
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.
290
Figure 9-9 Open a map
9.3 Adapter installation

The 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.
291
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.1 Installing the NetView part of the adapter

The 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 total 11856 drwxr-sr-x 2 drwxr-xr-x 28 -rwxr-xr-x 1 -rw-r----1 -rw-r--r-1 #ls -la sys bin 101 root root sys bin staff sys staff 2560 1024 5333 3031040 3020800 Nov Nov Sep Nov Nov 08 14 26 07 14 10:55 13:12 2001 17:08 2001 . .. Install.ksh tbsmadapter_aix_1_1_nv71_20011114.tar 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.ksh Install.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 Utility Successful Completion Install.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 #
292
9.3.2 Installing the TBSM part of the adapter

To 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 server SQLSERVER=ibmtiv5 # Replace XXXXX with the name of the SQL Server user account SQLUSER=sa # Replace XXXXX with the password for the SQL Server user account SQLPWD=sa_ibmtiv5
9.4 NetView adapter configuration

Before 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.
293
Table 9-1 nvid keywords

Keyword
NVID NetworkID
Comment
Reserved for future use. Must not exceed 15 characters. No spaces allowed. 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. 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). Specifies a backup NetView server that shares the same nnid.conf file
PrimaryURL
secondaryURL
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=TI7043TBSM networkid=NV0 primaryURL=capecod.itsc.austin.ibm.com.ibm.com:8080 secondaryURL=backupnetview.ibm.com:8080 contact=Peter Glasmacher description=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.
294
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.com transport.request.address = capecod.itsc.austin.ibm.com.BASETEST.QM+BASETEST.Q transport.request.port = 9898 transport.response.address = capecod.itsc.austin.ibm.com.BASETEST.QM+BASETEST.Q transport.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 adapter

This section covers the use of IBM Tivoli Business Systems Manager Adapter.
9.5.1 Bulk discovery

After a successful installation, you can use the following steps to verify the NetView side of the adapter installation: 1. Use NetViews /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:/ #nvstat NOTE: ovspmd is process 27850
295
DAEMON NAME actionsvr ems_log_agent . . tbsmadapter . . webserver capecod:/ #
PROCESS 25698 31236
PARENT ovspmd ovspmd
DEPENDENCIES nvsecd,nvcorrd nvsecd,ems_sieve_agent
19662
ovspmd
nvsecd
17584
ovspmd
ovwdb
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.
296
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.
297
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 ibmtiv3 tcp4 0 0 capecod.itsc.aus.9898 ibmtiv3.itsc.aus.1521 tcp4 0 0 capecod.itsc.aus.39109 ibmtiv3.itsc.aus.8082 ESTABLISHED 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.
298
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
299
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
300
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
301
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.
302
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 adapters 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
303
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 NetView Diagnostics
Launches the NetView Web console and displays the actual submap where the resource resides. 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
304
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 environment

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

First, 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
305
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. 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.
tbsmtrap
306
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 communication

If 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 ibmtiv3 tcp4 0 0 capecod.itsc.aus.9898 ibmtiv3.itsc.aus.2245 ESTABLISHED tcp4 0 0 capecod.itsc.aus.45632 ibmtiv3.itsc.aus.8082 ESTABLISHED capecod:/ # c:\>netstat -a|grep capecod TCP ibmtiv3:2245 capecod.itsc.austin.ibm.com:9898 ESTABLISHED TCP ibmtiv3:8082 capecod.itsc.austin.ibm.com:45681 ESTABLISHED c:\>
307
9.6.3 Testing the launch functions

If 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 form nvlaunch.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 scripturl The IP address or name of your NetView server. The location of the script being executed at the server side. The location must be specified relative to /usr/OV/www/webapps. The name or IP address of the node under investigation.
targetnode
Remember to put all the parameters in a single line separated by blanks.
308
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.txt C:\NVWC\lib>"c:\NVWC\jre\bin\java.exe" -jar launch.jar --port 1234 --stdin 0<..\bin\launch.txt C:\NVWC\lib>goto LAUNCH_NT_W2K_DONE C:\NVWC\lib>popd C:\NVWC\bin>if NOT "Windows_NT" == "Windows_NT" goto SKIP_ENDLOCAL C:\NVWC\bin>ENDLOCAL C:\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 files

All 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 NetViews default log directory /usr/OV/log.
tbsma.log
The 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 TI7043TBSM 5:25:57 PM CST Asking for adapter... 5:26:10 PM CST setAdapterListenerIF...
309
5:26:10 5:26:21 NetView 5:26:21 5:26:21
PM CST Asking for SID... PM CST Session identifier: [TBSM Instrumentation for Distributed - TI7043TBSM-9.3.4.53-680817032-0000000055] PM CST Serving port 4321. PM CST Waiting for connections.
tbsmatopo.log
This 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.0 Tue 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 : 140 Tue Dec 3 17:28:58 2002 default 23420 Callback return code 0 Tue Dec 3 17:33:24 2002 default 23420 Ending for the following reason: NetView/6000 ending.
tbsmatrap.log
Contains 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.
310
varbind 4: 1038958353 1208 varbind 5: openview varbind 6: 9.13.0.0 varbind 7: varbind 8: Network managed: Specific: 50790416 Sending 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.log
You 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 menus

Both 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.
311
9.7.1 Extending the NetView Web console

Starting 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.xml This file contains all the actions and functions provided by the Web console in a compressed format. /usr/OV/www/webapps/netview/warf/Templates/WebConsole This 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.
312
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.
313
<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. 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. Defines a name for the action. Defines a menu shortcut for your action. Be sure the mnemonic is specified out of the characters used in the name definition.
<Action id=>
<Name> <Mnemonic>
<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> <ActionHandler> Defines a more specific explanation of your new menu. Appears in the roles dialog as well. Specifies the handler meant to execute the action. Dont change the name LaunchServerAppHandler. This handler will execute your action on the NetView server. Starts a method subsection in which you will define the program to be executed, along with all arguments it might require. Specifies the method assigned to the application handler. The full path of the method is required. In our case it is com.tivoli.netview.client.NetViewApplet.launchServerApp Starts an argument list subsection. Each of the arguments is defined inside a <Val></Val> definition. 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>
<Method>
<MethodName>
<ArgList> <Array>
314
<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"> <ActionRef xlink:href='MyActions.xml#xpointer(id("launchbu"))'/> </MenuItem> </Menu> </Menu> </MenuBar> </Application> </WARF>
<?xml ...>
The same as for the action definition. Dont change the first three lines, and be sure the character set encoding is set to UTF-8. Use the same name as in your action definition. Starts a menu bar definition. Apply the same rules as for the application name. The name must be unique. (You cant give it the name MenuBar because this name is already used for the default menubar of the Web console.)
<Application> <MenuBar>
315
<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. Causes a separator line being inserted into the menu. You can use it anywhere inside a menu definition. 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. Again, this specifies a shortcut to the menu name. As mentioned, our new menu should appear as TBSM in the tools submenu. 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 Managerrelated extensions as new menu items under the IBM Tivoli Business Systems Manager submenu. 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 attribute xlink:href='MyActions.xml#xpointer(id("launchbu"))'.
<Separator/> <Menu>
<Mnemonic> <Name> <MenuItem>
<ActionRef>
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.
316
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.
317
Example 9-20 Parsing errors in securityconsole.log

2002-11-26 13:53:38,762 [Thread-4] ERROR com.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
318
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 console

In 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 NetView Diagnostics Launches the NetView Web console and displays the submap where the physical resource resides. 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.
319
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 executed

The menus that appear on the Java console are stored in IBM Tivoli Business Systems Managers 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.
320
4. Populate console
nvlaunch.jar
3. Request data
NetView server
1. Request Launch entry
2. Launch command
TBSM Console
TBSM Console Server TBSM Database Server
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 entry

As 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.
321
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 routers 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 objectproperties.js submapexplorer.js Provides the diagnostics pane in the Web console. Displays the NetView object properties pane in the Web console. 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 #ls 3beansalad.js diagnostics.js resolvetarget.js README.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.
322
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 dont 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.
323
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.
324
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
325
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.
326
Figure 9-29 The Web console display launched by the new menu
327
328
Part 3
Part
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
329
330
10
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
331
10.1 Source/390 implementation

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

Before 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.
332
Table 10-1 z/OS data sources

Resource
Automation Products:
Name
SC69A RODM MVS console, RMF, Omegamon for MVS TWSC DSNT, DSN2 IMSQ SCSCCMAS DFSMSHSM, XRC, SMS /etc/httpd.conf
System Automation for OS/390 RODM

MVS Job Scheduler DB2 IMS CICSPlex/SM Storage Management WebSphere
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/390

The 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
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 SSSS yy The parameter type: PD for dataspace, PS for object server and PP for object pump. The SMF id of the z/OS image. 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 installation

The 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 //* //DSPC //STEPLIB //ACC1PARM PROC MBR=PD&SYSNAME.00 @P1C
EXEC PGM=GTMACC17,PARM=&MBR DD DISP=SHR,DSN=GTMV2R1.SGTMMODS 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
334
Source/390 object server installation

The 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 //* //SRVR //STEPLIB //AOPLOG //AOPSYSIN //SYSOUT //SYSTCPD PROC MBR=PS&SYSNAME.00 @P1A99 @P2C
EXEC PGM=GTMMAINS DD DISP=SHR,DSN=GTMV2R1.SGTMMODS DD SYSOUT=*,DCB=(LRECL=136,BLKSIZE=1004,RECFM=VB) DD DISP=SHR,DSN=GTMV2R1.LOCAL.PARMLIB(&MBR) DD DUMMY DD DISP=SHR,DSN=TCP.&SYSNAME..TCPPARMS(TCPDATA)
@P1C @P1A @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 ASIMVSIPOSListenerSvc TCPIP_SERVER_PORT=1024 Listening port for the object server VALIDCLIENT=9.3.5.11 IP address of host running IP sender svc LOG1=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 makemvscomponentss -v parameter, which specifies the MVS Listener Service IP port. The TCP_SERVER_PORT control card must be the same value as defined
335
in the makemvscomponentss -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 installation

The 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
336
NUMBER_OF_TERMINALS=0 # VIRTUAL TERMINALS IN POOL MODEL2_LOGMODE=D4A32782 LOGMODE NAME FOR MODEL2 VIRTUAL MODEL3_LOGMODE=D4A32783 LOGMODE NAME FOR MODEL3 VIRTUAL MODEL4_LOGMODE=D4A32784 LOGMODE NAME FOR MODEL4 VIRTUAL MODEL5_LOGMODE=D4A32785 LOGMODE NAME FOR MODEL5 VIRTUAL LOG_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.
TERMINALS TERMINALS TERMINALS TERMINALS
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 configuration

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

Source/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
337
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 security

The 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/OS

Many 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
338
10.2.1 Modify the NetView started task procedure

Modify 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
DD name
STEPLIB DSICLD DSIPARM DSIMSG
TBSM library
hlq.SGTMMODS hlq.SGTMEXEC hlq.SGTMSAMP hlq.SGTMMSGS
Notes
TBSM modules REXX programs sample members message files
10.2.2 Modify the DSIPARM members

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

Uncomment 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.
339
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
DISPPI RECEIVER RECEIVER IDENTITY STATUS -------- -------NETVALRT ACTIVE ISTMTRCV ACTIVE DSIMCAT ACTIVE SC69NSCO ACTIVE SC69NHTM ACTIVE NETVRCV ACTIVE DSIQTSK ACTIVE NETVAOP ACTIVE IHSATEC ACTIVE END OF DISPLAY BUFFER LIMIT ---------1000 500 25 1000 1000 500 100 1000 5000 QUEUED BUFFERS ---------0 0 0 0 0 0 0 0 0 TOTAL BUFFERS ---------3 38 0 0 0 103 0 405 21 STORAGE ALLOCATED ---------0 0 0 0 0 0 0 0 0 RCVR ASID ---005F 001A 005F 005F 005F 005F 005F 0071 006D
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 USETCP/IP SOCKETS PORT The name of the local TCP/IP stack. Must be YES. Specifies the number of supported connections. 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.
340
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.com DUI401I 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 systems

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

These 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.
341
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 Server

In 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/
342
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.
343
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.
344
Example 10-12 Running makeMVSComponent.ksh

C:\>sh makeMVSComponents -BSC64 -OSC64 -wWTSC64.ITSO.IBM.COM:1024 -v1022 Validating 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.exe Copying the Sender Service service bootstrap executable to the proper location/name... //IBMTIV3/C$/TivoliManager/bin/ASIServiceApp.exe -> //IBMTIV3/C$/TivoliManager/bin/services/ASISS_SC64.exe Copying the File Receiver service bootstrap executable to the proper location/name... //IBMTIV3/C$/TivoliManager/bin/ASIServiceApp.exe -> //IBMTIV3/C$/TivoliManager/bin/services/ASIFR_SC64.exe Creating 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.)
345
346
11
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
347
11.1 z/OS data feeds overview

IBM 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.
z\OS
WebSphere for OS/390 DFSMShsm
TBSM SOURCE/390
MVS Console Messages and Commands
SMS
XRC
RODM CICSPlex System Manager for OS/390 Resource Management Facility CICS Transient Data
EKGNotify
CPSM API
SOURCE/390 Object Pump
GPMSERVE
External Data Interface (EDI) Program-toprogram Interface (PPI)
Tivoli Workload Scheduler CICSPlex
Tivoli NetView for z/OS SOURCE/390 Dataspace
IMS
DB2
System Automation for OS/390 V2R1
SOURCE/390 Object Server
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
348
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 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.
11.2 System Automation for OS/390 Version 2.1

System 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 Concept
Figure 11-2 on page 350 shows the conceptual component of the System Automation for OS/390 connection to IBM Tivoli Business Systems Manager.
Chapter 11. z/OS data feeds and discovery
349
NetView System Automation
IHSSMAT
IHSSINIT
discovery
IHSSSTRT
IHS MSG
PPI
TBSM Object Pump
status change
IHSSDISC
IHSSOBSX
Bulk Discovery Data
IHSSBCPJ
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.
350
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 GROUP NVOPS1 NVOPS2 IHSSAUT1,IHSSAUT2 IHSSAUT1,IHSSAUT2
11.2.3 Object discovery

The 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.DATA IHS703I GATHERING DATA - INGLIST IHS703I GATHERING DATA - DISPSTAT IHS703I GATHERING DATA - UNLOADING AUTOMATION MANAGER IHS703I GATHERING DATA - VTAMOPTS IHS703I GATHERING DATA - XCF IHS702I IHSSDISC : END OF PROCESSING
351
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 PIPE PIPE PIPE PIPE NETV INGLIST OUTMODE=LINE NETV DISPSTAT ALL2CONS=YES OUTMODE=LINE NETV INGRVTPO NETOP1 GET_DATA CC ROUTE *ALL,D NET VTAMOPTS,OPTION=(SSCPNAME,NETID) 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.COM TCP/IP_PORT=1021 CODEPAGE=037 BUFFERSIZE=1 TIMEOUT=30 CONVERT=NO
352
TEXT=NO COMMAND=SA390DISCOVERY FORMAT=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/OS

The 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.
353

Perform 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 DB2s 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. An interval for clearing a DB2 and DB2PM exception that has not recurred in the last polling interval. The default is 15 minutes. An interval for resolving a DB2 and DB2PM exception that is cleared within the polling interval. The default is 2 minutes. Limit of initial discovery messages. Default is 500.
IHSBCLER.INTERVAL
IHSBRSLV.INTERVAL
IHS$DISC_FROM
354
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 NAME EVENTID SYSNAME Object class target Matching name of the object Message or event id 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
355
//STEPLIB DD DISP=SHR,DSN=DB2.V7R1.SDSNLOAD //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DB2O) RUN PROGRAM(DSNTIAD) PLAN(DSNTIA71) LIBRARY('DB2.RUNLIB.LOAD') 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 //*
<=== 4.
/* <=== 2. */ /* <=== 5. */ /* <=== 6. */
; ; ; ; ; ; ; ; ; ; ; ;
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.

Recycle 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.
356
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.

The following steps must be completed before integration: NetView-related setup on page 358 IMS-related setup on page 359
357
NetView-related setup
IBM 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 IHSI.$DBSINT IHSI.$LOGAVAIL IHSI.$MSCINT IHSI.$MTOINT IHSI.$PGMINT IHSI.$TXNINT IHSI.$TXQLEN IHSI.$POLLTHRESHOLD IHS$DISC_FROM IHS$DISC_NVTCP/IP Default wait time (in minutes) for the IMS archive log to run before a logging event is generated. Default interval between database status checks. Default minimum number of available IMS online logs (OLDS) before an event is generated. Default interval for checking MSC links. Default interval for checking Master Terminal. Default interval for checking program status. Default interval for checking transaction status. Default maximum queue length for transaction. Threshold on the number of messages to be sent to Windows server to avoid message flood. Limit of initial discovery messages. Default is 500. IP address of the MVS IP Listener. Our setup is TCP/IP_ADDRESS=9.3.4.55.
358
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 NAME EVENTID SYSNAME Object class target Matching name of the object Message or event ID 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 setup
Perform 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.
359
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 IHS371I Successfully loaded Message Table IHSIAOEM IMSQ 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 //* //IEFPROC //* //STEPLIB //SYSPRINT //SYSUDUMP JOB ,'OTMA INITIALIZATION',CLASS=A,REGION=4M EXEC PGM=DFSYSVI0 DD DD DD DISP=SHR,DSN=IMS710Q.SDFSRESL SYSOUT=* 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.
360

Recycle 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.2

The following section describes the configuration steps for integrating the CICSPlex System Manager (CPSM) data source into IBM Tivoli Business Systems Manager.
361

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

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

Events 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).
362
----------------------------CICSPlexSystemManager--------------------------OPTION ===> 2 0 PROFILE 1 PLEXMGR 2 CPSM - User Session Parameters - List of Service Points - CICSPlex SM
Default Criteria for CPSM: Context ===> SC66PLEX Scope ===> Warning Record Count ===> 0 Require Set ===> YES
0 for no checking 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-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 .
19:12:06 ----------- INFORMATION DISPLAY --------------------------COMMAND ===> RTASPEC SCROLL ===> PAGE CURR WIN ===> 1 ALT WIN ===> W1 =MENU==============SC66PLEX=CSYS1H1==11DEC2002==19:12:06====CPSM=========16 CMD 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
Figure 11-7 View selection panel
363
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.
11DEC2002 19:44:00 ----------- INFORMATION DISPLAY --------------------------COMMAND ===> SCROLL ===> PAGE CURR WIN ===> 1 ALT WIN ===> W1 =RTASPEC===========SC66PLEX=CSYS1H1==11DEC2002==19:43:55====CPSM=========10 CMD 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
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.
----------------- Update Analysis Specification for SC66PLEX -----------------COMMAND ===> RTA Spec Name Description SCSCPAA1 ===> Generated by CICS PM
System availability management: Action or Generic ===> TBSMA1 ===> TBSMA1 ===> TBSMA1 ===> TBSMA1 ===> TBSMA1 ===> TBSMA1 Severity ===> ===> ===> ===> ===> ===>
SAM SOS SYSDUMP TRANDUMP MAXTASK STALL
Press ENTER to update the RTA Specification. Type END or CANCEL to cancel without updating.
Figure 11-9 Real time analysis specification update
364
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.
12DEC2002 10:19:52 ----------- INFORMATION DISPLAY --------------------------COMMAND ===> cre SCROLL ===> PAGE CURR WIN ===> 1 ALT WIN ===> W1 =ACTNDEF===========SC66PLEX=CSYS1H1==12DEC2002==10:19:51====CPSM========106 CMD 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-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.
365
-------------------- Create Action Definition for SC66PLEX -------------------COMMAND ===> Action Name Description Event Event View Priority Event Text External Msg Enter Msg Exit Msg Alert CMAS Name Enter Text Exit Text Restart ===> TBSMA1 ===> TBSM Action ===> YES Generate Event (Yes/No) ===> View for Event ===> 1 Event Priority (1 to 255) ===> TBSM Action ===> NO ===> ===> ===> YES ===> SCSCCMAS ===> ===> ===> NO Generate External Message (Yes/No)
Generate Alert (Yes/No) CMAS to Issue Alert
Cancel for ARM Restart (Yes/No)
Press ENTER to create the Action Definition.
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.
12DEC2002 11:00:13 ----------- INFORMATION DISPLAY --------------------------COMMAND ===> SCROLL ===> PAGE CURR WIN ===> 1 ALT WIN ===> W1 =ACTNDEF===========SC66PLEX=CSYS1H1==12DEC2002==11:00:09====CPSM========105 CMD 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
Figure 11-12 Updated action definition list
366
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 IHSCFILE IHSCTRAN IHSCMAS IHSCDB2C IHSCCORB IHSMISC CICS groups Files Transactions CICS regions and connections DB2 connections Corba servers and JAR files 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.
----------------------------CICSPlex System Manager---------------------------OPTION ===> 2 0 PROFILE 1 PLEXMGR 2 CPSM - User Session Parameters - List of Service Points - CICSPlex SM
Default Criteria for CPSM: Context ===> Scope ===> Warning Record Count ===> Require Set ===> SCSCCMAS CSYS1H1 0 YES
0 for no checking 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-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.
367
12DEC2002 13:11:21 ----------- INFORMATION DISPLAY --------------------------COMMAND ===> BATCHREP SCROLL ===> PAGE CURR WIN ===> 1 ALT WIN ===> W1 =MENU==============SCSCCMAS=CSYS1H1==12DEC2002==13:11:21====CPSM=========16 CMD 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
Figure 11-14 CPSM primary option
3. From the panel shown in Figure 11-15, issue sub at the command line.
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-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.
368
------------------------ Start Batch Run for SCSCCMAS ------------------------COMMAND ===> Data Set Name ===> GTMV2R1.LOCAL.SGTMSAMP
Data Set Member ===> IHSCGRP Print Class Print Node Output Userid Run Type ===> A ===> WTSCPLX1 ===> TIVO01 ===> EXECUTE (CHECK or EXECUTE)
Press ENTER to Run the Job. Type END or CANCEL to cancel without Running.
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 updates

This 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.
369
Figure 11-17 Property of a CICSPlex definition

CICSPlex 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 //*
370
//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.55 TCP/IP_PORT=1021 CODEPAGE=037 COMMAND=CPSMDISCOVERY CONVERT=NO TEXT=NO DATA_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
371
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/OS

The 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 Concept
The 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.
372
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.

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

If 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 # # # # # # . . . #EXITS EXITS CALL07(YES) CALL07(NO) GENALERT(OPCERROR) MLOG (ERROROPER) WTO (DURATION ERROROPER LATEOPER OPCERROR QLIMEXCEED RESCONT)
2. Remove the IBM Tivoli Business Systems Manager version of EQQUX007 from any library in LNKLST, or concatenated in the TWS for z/OSs STEPLIB DD statement.
373
Configuring Tivoli Workload Scheduler for z/OS

To 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.
------------------- 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
Figure 11-20 Detailed operation information
374
Preparing the TBSM database

Preparing 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
include(BusinessObject.sqi) 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.
375
Example 11-10 Applying OPC definitions

sh clsql OPC_Class_Definition.sqi sh clsql OPC_Appl_Definition.sqi isql -U sa -P sa -S itsovas3 -i OPC_Class_Definition.sql isql -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.

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

The 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.
376
In our project, we only discuss the configuration for SNA resource data feed and discovery.
11.7.1 Concept
The 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.

To 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 RODM_USERID
The RODM name, typically RODM, assigned to the RODM address space. 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
377
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.
378
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

Modify 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.
379
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=RODM CLASS=UniversalClass DEPTH=ALL WRITEMODE=OVERWRITE WHITESPACE=HIGH REPORTONLY=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.55 TCP/IP_PORT=1021 CODEPAGE=037 TIMEOUT=600 TEXT=YES COMMAND=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.
380
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 Concept
Figure 11-25 on page 382 depicts the event processing data flow for RMF monitoring events for IBM Tivoli Business Systems Manager architectures.
381
RMF Monitor III RMFGAT
TBSM Object Pump

monitoring task
Distributed Data Server GPMSERVE
collector task
reporter task
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 RMFProfileDef List of available RMF profiles. Initially this table contains three RMF profiles: Eliminate, Default, and Stress. 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. Correlates a TBSM object (identified by class ID and instance ID) with an RMF profile (identified by the profile ID).
RMFProfileObjReln

The 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
382
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 Profile BEGIN_RMF_PROFILE(Default) RMF_OBJECT_RELATION(OS,1) END_RMF_PROFILE() -GO
383
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.
384
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 Concept
The conceptual flow is shown in Figure 11-27.
GTMDCLBD GTMUCBBD GTMCATBD GTMVTCBD
TBSM MVS IP Listener
SQL Server Agent jobs

SMS Disk Device Discovery SMS Disk Volume and Storage Group Discovery SMS Data Set Discovery SMS Catalog Entry Discovery
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.

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

Perform 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.
385
Table 11-1 TBSM batch jobs for SMS

Member name
GTMDCLBD GTMUCBBD GTMCATBD GTMVTCBD
Resources
Storage Group,Disk Volume Disk Device Catalog entry data set
Recommended parameter
* (all volumes) ALL ALL ALLVTOCS
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 server

This 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.
386
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
387
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 Concept
The HSM messages are trapped from the system console. This happens when a definition for HSM object exists under the Operating System object.
388

The 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
389
You then specify the name of the new object. We use DFSMSHSM, as shown in Figure 11-31.
Figure 11-31 HSM creation
390
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/390

This section describes the configuration steps for HTTP server data source integration into IBM Tivoli Business Systems Manager.

Several 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.
391
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.

Object 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
392
Part 4
Part
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
393
394
12
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
395
12.1 Automatic Business System View

The 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 Managers new feature, Automatic Business System, that enables the automatic creation of Business System Views.
12.1.1 Automatic Business Systems design

The 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.
Config file
absConfig.ksh
alobListPattern alobListCriteriaAlob dynamic_object_create_path_detail dynamic_object_create_path
Update ObjPathCache
ABS Discovery Process
ABS Creation Process
ObjPathCache
evQueueObject
alobQueueCreateLOB ev_auto_create_object_parm
Object creation or update triggers tI_EV<cid>_C tU_EV<cid>_C tU_EV<cid>_A
ABS Table Purge
Figure 12-1 ABS processing
396
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. 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. These configuration values are stored in these tables: alobListPattern alobListCriteriaAlob List of the pattern-matching attributes 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 file

The 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
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 Pattern The list of all the operands that can satisfy the pattern. The list of all the patterns with their attributes and the logical conditions or operations that the attributes must satisfy The list of the criteria used for the patterns and the relationship between patterns within the same criteria The list of all the BSVs that could be created and their hierarchical order The list of all BSVs that should be created when the particular criteria is met
CriteriaToPattern Path CriteriaToPath
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
PatternList ListName Operand PL_1 DB% PL_1 D2% Pattern Pattern 1 2 3
Class D2SS IMSS IMSS
Attribute name name Path
When Current Current Current
Operator LIKE LIST LIKE LIKE
Operand1 PL_1 IMS% %SC66%
Operand2 % % %
CriteriaToPattern Criteria Pattern 1001 1 1002 2 1002 3 Path Path PP_0_0 PP_0_0 PP_0_1 PP_0_1
PatternRelated 1 2 2
Level Name 1 Remote Banking 2 1 Remote Banking 2
398
CriteriaToPath Criteria Path Level Pattern 1001 PP_0_0 2 1 1002 PP_0_1 2 3
Variable Value name <1:name> 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 Level Name A string representing the BSV that will be created but is not seen outside the database. The number of levels from the Business System Container. 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. Lets 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 3 IMSS IMSS name Path Current Current LIKE LIKE IMS% %SC66% % %
399
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. A valid SQL pattern.
Operand Pattern definitions are: Pattern Class
A unique integer identifier used in the CriteriaToPattern section to identify the pattern for each criteria. The four-letter code representing the internal IBM Tivoli Business Systems Manager class name on which the pattern test will be attempted. The attribute of the Class that identifies the aspect of the object class on which the pattern test will be performed. The version of the attribute value on which the test will be performed. Can be current or previous. 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.
Attribute When Operator
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. The second argument for the operator, used for BETWEEN, NOT BETWEEN, and EGREP. All other operators should use a % character as a placeholder.
Operand2
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.
400
Pattern PatternRelated
An integer pointing to an existing pattern in the Pattern section. 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 Path Level A pointer to a criteria described in the CriteriaToPattern section. A string equal to a path value in the Path section. 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. 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. A string indicating the attribute that will be substituted. 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 1s name. The string also can be a combination such as <2:IPAddress>@<1:name> and it will resolve to the object that satisfied pattern 2s IP address and pattern 1s 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.
Pattern
Variable Value
401
12.1.3 Defining the Automatic Business System

To 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.
402
12.2 ABS usage example

In 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.
ITSO Resources Operating Systems Dynamic OSes Start with SC* or M* DB2 Subsystems Dynamic D2SS Not start with DB
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. Lets create the configuration file.
12.2.1 Manual creation of the business system view

The 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 OPER_SYS OPER_SYS Operand S% 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 resources class attribute to identify the resources we are interested in. The Pattern section is in Example 12-3 on page 404.
403
Example 12-3 Pattern section

Pattern Pattern 1 2 Class Attribute OS name DB2 name When Current Current Operator LIKE LIST NOT LIKE Operand1 OPER_SYS DB% Operand2 % %
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
CriteriaToPattern Criteria Pattern 1001 1 1002 2 PatternRelated 1 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
Path Path PROD_OS PROD_OS PROD_OS PROD_DB2 PROD_DB2 PROD_DB2 Level 1 2 3 1 2 3 Name ITSO RESOURCES Production OS ITSO RESOURCES Production DB2
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
CriteriaToPath Criteria Path 1001 PROD_OS 1001 PROD_OS 1002 PROD_DB2 1002 PROD_DB2 Level 3 3 3 3 Pattern 1 1 2 2 Variable name Desc name Desc Value <1:name> Production_OS <2:name> Production_DB2
404
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
405
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: Administrators 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
406
12.2.2 BSV creation tool

As 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
407
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
408
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
409
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
410
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
411
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.
412
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
PatternList ListName Operand PL_1 SC% PL_1 M% Pattern Pattern 1 2
Class Attribute OS name D2SS name
When Current Current
Operator Operand1 Operand2 LIKE LIST PL_1 % NOT LIKE DB% %
CriteriaToPattern Criteria Pattern 1001 1 1002 2
PatternRelated 1 2
413
Path Path PP_0_0 PP_0_1 PP_0_0 PP_0_0 PP_0_1 PP_0_1
Level 1 1 2 3 2 3
Name ITSO Resources ITSO Resources Operating Systems DB2 Subsystems
CriteriaToPath Criteria Path Level Pattern 1001 PP_0_0 3 1 1002 PP_0_1 3 2
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.
414
12.3.2 Migration example

The 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
415
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
GEM_InstFiltering column Value
when = 0
memTest
memOptions
memExpr
%HB_PRIMARY% %HB_SECONDARY%
or more then one symbol when <> 0 when <> 0
exclusive priority
The preceding values represent distributed rules that must be added manually into the ABS engine. 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 sections unneeded criteria. 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: Administrators Guide, GC32-0799. This script calls
416
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
PatternList ListName Operand Pattern Pattern 1 2
Class Attribute G02E MgedSystemName G02K MgedSystemName
When Current Current
Operator Operand1 Operand2 EGREP i ibmtiv* EGREP i ibmtiv*
CriteriaToPattern Criteria Pattern 1 1 2 2
PatternRelated 1 2
Path Path Distributed NetworkLOBC Distributed NetworkLOBC
Level Name 1 Distributed Network 2
CriteriaToPath Criteria Path 1 Distributed NetworkLOBC 2 Distributed NetworkLOBC
Level Pattern 2 1 2 2
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
417
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
PatternList ListName Operand Pattern Pattern 1 2 3
Class G02E G02K G02J
Attribute MgedSystemName MgedSystemName MgedSystemName
When Current Current Current
Operator EGREP EGREP NOT LIKE
Operand1 i i ibmtiv%
Operand2 ibmtiv* ibmtiv* %
CriteriaToPattern Criteria Pattern 1 1 2 2 3 3
PatternRelated 1 2 3
Path Path Distributed NetworkLOBC Distributed NetworkLOBC TEC Generic TEC Generic TEC Generic
Level 1 2 1 2 3
Name Distributed Network Distributed Network TEC Generic
CriteriaToPath Criteria Path 1 Distributed NetworkLOBC 2 Distributed NetworkLOBC 3 TEC Generic
Level 2 2 3
Pattern 1 2 3
Variable name name name
Value <1:name> <2: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.
418
Figure 12-13 Table GEM_Options
419
420
13
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
421
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 directories

In 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.
422
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 directorys 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
424
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.
425
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 registry

The 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 changeor even readthis information.
426
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
427
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
428
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 groups

The 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
429
13.2 Password protection

Passwords 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 Servers system administrator passwords Section 13.2.3, Reporting system password on page 433 discusses Reporting system passwords
13.2.1 TBSM processes passwords

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

SNA 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.
430
TPSTART consideration
TPSTART 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 AutoAdminLogon Default password for the Windows machine. 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.
431
Task server password consideration

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

Changing 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\DB HKLM\SOFTWARE\Accessible Software, Inc.\Access1\1.0\Settings\Model\Params HKLM\SOFTWARE\Accessible Software, Inc.\Access1\1.0\Settings\Model\Params\Setup Defaults
In some servers, additional keys contain the SQL servers 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]
432
13.2.3 Reporting system password

The online reporting systems 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 security

As 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.
433
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 workspaces

This 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.
434
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
435
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.
436
14
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.
437
14.1 SQL Server Agent jobs

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

All 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
CICS Discovery Load CICS Discovery Process Cleanup CPSM discovery-related tables Cleanup CICS Startup/Shutdown Tasks Delete CICS Transaction Message ENT:1:MVS File Status Request Process Pending State Transition
Suggested settings
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
438
z/OS resources jobs

DB2 Discovery Load DB2 Discovery Process Cleanup DB2 discovery-related tables Delete Unused DB2 Data Sharing Groups IMS Discovery Load IMS Discovery Process Cleanup IMS discovery-related tables CA7 Discovery Load CA7 Discovery Process CA7 Cleanup Audit Events Zeke Discovery Load Zeke Discovery Process Must End Batch Operations Automation Discovery Load Automation Discovery Process RODM Discovery Load RODM Discovery Process RODM Network Auto-register 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 Catalog Entry Discovery Load SMS Catalog Entry Discovery Process SMS Data Set Discovery Load SMS Data Set Discovery Process Cleanup RejectedOPCEvent Completed Schedule Poll OPC Check for new daily plan Delete old auto-discovered batch jobs XRC Session Names Discovery Load XRC Session Names Discovery Process XRC Session Pairs Discovery Load XRC Session Pairs Discovery Process Cleanup Control-M
Suggested settings
Enable these jobs only if you are monitoring DB2 resources with the Tivoli Business Manager DB2 interface Enable these jobs only if you are monitoring IMS resources with the Tivoli Business Manager IMS Tower interface Enable these jobs only if you are monitoring batch schedules from Computer Associates CA-7 Scheduler Enable these jobs only if you are monitoring ASG-Zeke Enable these jobs only if you are using SA/390 to perform automation discovery 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 Enable these jobs only if you are monitoring Systems Managed Storage (SMS)
Enable these jobs only if you are monitoring batch schedules from Tivoli Workload Scheduler Enable these jobs only if you are monitoring XRC subsystem
Enable these jobs only if you are monitoring batch schedules from CONTROL-M for z/OS scheduler
Chapter 14. Maintenance and tuning issues
439
z/OS resources jobs

ENT:1Weekly MVS Register Objects Cleanup Discovery Batches
Suggested settings
Always enable these jobs if you monitor z/OS component with Source/390
14.1.2 Distributed resources jobs

The 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
Distributed resources jobs
GEMCleanupTraceTables GEMOverdueHeratbeatJob CL_ProcessRuleJob CLCleanupJob CLScheduled_SPCallsJob
Suggested settings
Enable these jobs only if you are monitoring distributed resources through the Tivoli Enterprise Console Enable these jobs only if you are using the Common Listener service
14.1.3 Database maintenance jobs

The 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
Database maintenance jobs
Delete Old Child Events Delete Old Closed Notes Delete Old Exceptions Delete Old Messages Delete Old ObjectEvent Records Cleanup UnandledEvent Table
Suggested settings
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.
440
Database maintenance jobs

Cleanup Event Viewer Tables Cleanup Menuitem Cache Cleanup GenerateChildEvent Tables
Suggested settings
These jobs remove any old entries from the tables dealing with Event Viewer, objects Menus, and propagation processing. We recommend keeping them always enabled.
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 Files

The Cleanup Old Log Files job deletes log files with extension *.log, *.txt, or *.msg created by IBM Tivoli Business Systems Manager in the servers 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
441
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> <History_Server> <Application_Server> The name of the machine hosting the Database Server The name of the machine hosting the Historical Server The name of the machine hosting the Console Server
<Propagation_Server> The name of the machine hosting the Propagation Server <Event_Handler> <SNA_Server> Days_to_retain The name of the machine hosting the Event Handler Server The name of the machine hosting the SNA server 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 files 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.
442
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 -D<directory> -n<days> -H<hours> -f<filespec> <Q>uiet mode, no confirmation directory to clean (default=current working directory) number of days to retain (default=0) number of hours to retain (default=0) 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.
443
Cleanup Old DB Queue Entries

The 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
ProcessedAutoTicketEvent ProcessedEvent ProcessedNotification ProcessedPerfMonMsg ProcessedStagedEvent PendingAutoTicketFilteredEvent PendingHeartBeatMsg PendingNotification8 PendingRuleCommand PendingTECExportEvent ProcessedAutoTicketFilteredEve nt ProcessedHeartBeatMsg ProcessedNotification8 ProcessedRuleCommand ProcessedTECExportEvent PendingBatchRule PendingMVSUploadRule PendingNotificationJ PendingScmMsg ProcessedBatchRule ProcessedMVSUploadRule ProcessedNotificationJ ProcessedScmMsg PendingAutoTicketEvent PendingEvent PendingNotification PendingPerfMonMsg PendingStagedEvent
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.
444
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 maintenance

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

IBM 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
445
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
446
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
447
14.2.2 Database Maintenance Plan

The 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
448
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
449
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
450
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: Administrators Guide, GC32-0799 directions. Click Next to continue.
Figure 14-9 Database Maintenance Plan Wizard: Data Optimization settings
451
5. Customize the Database Integrity Check panel as shown in Figure 14-10. Schedule the plan to run once a week in a databases off-peak usage time. Click Next to continue.
Figure 14-10 Database Maintenance Plan Wizard: Database Integrity Check
452
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
453
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
454
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
455
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
456
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
457
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 tuning

This 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.
458
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
459
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
460
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
461
14.3.2 Microsoft SQL Server 2000 tuning

Microsoft 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
462
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
463
464
15
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
465
15.1 Automatic problem ticketing

IBM 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.
Auto Ticketing filter
Event or message
User Action from Console GUI
TBSM User Exit processing routing

3 7
System Configuration table
{XXXXXX}.out file
{XXXXXX}.in file
4 5
Problem or Change Exit
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.
466
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 rule

This 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> -U<user> -P<password> -A<action> Database server name. User name for the database login. Password for the database login. Action to perform, which can be: add drop dump -F<input file> -O<output file> Uses contents of <input file> to add new rules. Uses contents of <input file> to drop rules. Prints out current rule set.
Specifies an input file containing new entries. 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
468
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:
http://www-3.ibm.com/software/sysmgmt/products/support/
From this pages 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. 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. 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.
469
z\OS system
Tivoli NetView for z\OS
TBSM Servers
NETCONV
Tivoli InfoMan
API
Tivoli BSM Task Server
tgmtask.exe
MVS Console
Source/390 system
SNA or IP
MVS Listener
TSD390RPin.rex TSD390RPout.rex
user exit
TSD Event Handler
TBSM Database
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/OSs 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.
470
15.4 Installation and configuration

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

To 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
REQUEST_ PROBLEM REQUEST_ CHANGE REQUEST_ AUTOTICKET
Property name
REQUEST_PROCESSOR_NAME
Usage and default

Program name for problem request Program name for change request Program name for Autoticketing
REQUEST_PROCESSOR_LANGUAGE Program processor (for non EXE programs) REQUEST_PROCESSOR_NAME
REQUEST_PROCESSOR_LANGUAGE Program processor (for non EXE programs) REQUEST_PROCESSOR_NAME
REQUEST_PROCESSOR_LANGUAGE Program processor (for non EXE programs)
471
Group
API_ INTEGRATION_ OPTIONS
Property name
AUTO_CLOSE_DEFAULT DEBUG_MODE DISPLAY_PROBLEM_CLOSURE TICKET_CREATE_DEFAULT TIMEOUT_VALUE CLOSED_TICKET_STATUS_CODE ORIGIN_SYSTEM ORIGIN_COMPONENT ORIGIN_ITEM ORIGIN_MODULE
Usage and default

Closes the problem ticket when the associated note is closed. Default is NO. Deletes the input and output control files. Default is OFF. Activates the problem closure data and text field. Default is NO. Displays problem ticket creation dialog after creating an ownership. Default is NO. Timeout duration for user exit processing. Default is 45 (seconds). Status code of a closed problem ticket. Default is CLOSED. 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
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. Puts the timestamp on the text log. Default is YES.
APPEND_TEXTLOG_TIMESTAMPS
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.exe for problem, change, and autoticket AUTO_CLOSE_DEFAULT DEBUG_MODE TICKET_CREATE_DEFAULT TIMEOUT_VALUE YES ON while testing, to see the interim files YES 120 depending on the communication latency with NetView CLOSED AUTO_CREATE
CLOSED_TICKET_STATUS_CODE ORIGIN_*
PROBLEM_SYSTEM_NETVIEW_USED YES
472
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/390s Object Registration process. Otherwise you must manually register the object: Right-click the OS object and select Source/390 -> Register Objects.
473
15.4.2 Extract and customize the input-output processor

For 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.rex
From 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.rex
We 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
474
* 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/OS
The 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 DISPPI TGMTaskClient::TGMTaskClient host TPConnection::open host= TGMTaskClient::runCommand commandString= TPConnection::send sent 148 bytes TPConnection::recv received 4 bytes TPConnection::recv received 1120 bytes TGMTaskClient::handleReply DISPPI DWO948I RECEIVER RECEIVER BUFFER QUEUED TOTAL STORAGE DWO949I IDENTITY STATUS LIMIT BUFFERS BUFFERS ALLOCATED DWO950I -------- -------- ---------- ---------- ---------- ---------DWO951I NETVALRT ACTIVE 1000 0 3 0 DWO951I ISTMTRCV ACTIVE 500 0 43 0 DWO951I DSIMCAT ACTIVE 25 0 0 0 DWO951I SC69NSCO ACTIVE 1000 0 0 0 DWO951I SC69NHTM ACTIVE 1000 0 0 0 DWO951I NETVRCV ACTIVE 500 0 114 0 DWO951I DSIQTSK ACTIVE 100 0 0 0 DWO951I NETVAOP ACTIVE 1000 0 1635 0 DWO951I IHSATEC ACTIVE 5000 0 166 0 DWO968I END OF DISPLAY TGMTaskClient::~TGMTaskClient TPConnection::close closing open connection Command execution completed.
RCVR ASID ---005F 001A 005F 005F 005F 005F 005F 0071 006D
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.
475
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.
Allocating TBSM interface parameter data set

The 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 AUTHORITY MASTPSWD=MASTER <= PASSWORD OR PRIVILEGE CLASS FOR MASTUID */ SESS=BLGSES69 <= SESSION ID DB=5 <= UPDATE DATABASE ID UIDREC=TBSM <= RECORD ID OR TABLE NAME FOR TBSM UID'S OR 'ALL' SRCHMAX=0100 <= MAX NBR RECS TO BE RETURNED FROM QUERY REQUEST /* @P4C1
476
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

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

After 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.
477
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 CLOSED The Problem Closed message is transferred to the IBM Tivoli Business Systems Manager TSD390 closure process. Assisted entry panel for IBM Tivoli Business Systems Manager event ID, as shown in Figure 15-3.
BLG6BSME
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 | +--------------------------------+---------------------------------+
Figure 15-3 TBSM event ID assisted entry panel
478
BLG6BSMO
Assisted entry panel for IBM Tivoli Business Systems Manager class ID, as shown in Figure 15-4 on page 479.
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-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.
479
Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +===> BLG23502I The specified target string was found. BLM1TDS1 DICTIONARY DISPLAY STRUCTURED WORDS WORD STRUCTURED WORD INDEX WORD ACRONYM PGM GENERAL USED COMMENT
159F 15A0 15A1 15A2 15A3 15A4
RESERVED NO XTBSMS15A0 TBSM=TBSM_NOTI YES XTBSMS15A1 TBSM=TBSM_OBJE YES XTBSMS15A2 TBSM=TBSM_EVEN YES RESERVED NO RESERVED NO
RESERVED. TBSM Integration TBSM Integration TBSM Integration RESERVED. RESERVED.
Type DOWN UP LEFT or RIGHT to scroll the panel or type END to exit.
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.
Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +===> BLG23502I The specified target string was found. BLM1TDP1 DICTIONARY DISPLAY PREFIX WORDS P-WORD PREFIX INDEX P-WORD VALIDATION PGM GENERAL USED COMMENT
06C3 06C4 06C5 06C6 06C7
TBSMO/ TBSME/
CCV9 CCV63
NO YES YES NO NO
RESERVED TBSM Integration TBSM Integration RESERVED RESERVED
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.
480
Creating a user record

The 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.
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-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 facility

The 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 TSPs summary screen as shown in Figure 15-8 on page 482.
481
Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +===> BLM1TSU9 CONTROL FUNCTION LABEL LINE NAME NAME '' COMMON '' LABEL '' USEREXIT '' TESTFIELD d' BRANCH '' USEREXIT '' TESTFIELD '' LABEL '' RETURN '' LABEL CONTROL LINE SUMMARY LITERAL DATA LINE 1 OF 115 GET APPLY VAR NOT
BLGTSPPU NOTIFY THE APPROPRIATE PERSON BLGTSAPI TEST FOR API ENVIRONMENT LEAVETSP 0 MESSAGE EXIT IF ESCALATION CAUSED FILE. ALLISOK 0 LEAVETSP LEAVE TSP AND RETURN TO CALLER ALLISOK RECORD WAS REALLY UPDATED.
NO NO NO NO
NO NO NO NO
Line Cmds: D=Delete U=Update Type DOWN, UP, LEFT, or RIGHT to scroll the panel, or type END to exit.
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.
482
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.
Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +===> BLM1TSU9 CONTROL FUNCTION LABEL LINE NAME NAME '' '' '' '' '' '' '' '' '' '' LABEL LABEL LABEL LABEL LABEL LABEL MOVEVAR USEREXIT LABEL SETFIELD @@@@@@@@ @@@@@@@ @@@@@@ @@@@@ @@@@ @@@ CONTROL LINE SUMMARY LITERAL DATA LINE 11 OF 114 GET APPLY VAR NOT
CHANGE 'DEFAULT' TO THE ID @@@@@ OF YOUR PROBLEM ADMINISTRATOR @@ IN LINE 17. SPACE FILL IF @@@@@ NEEDED. LEAVE POSITIONS @@@@@@@ 1-8 BLANK. POSITION 17 @@@@@@@@ MUST CONTAIN A '.' @@@@@@@@@@@@@ TIVO04 . CALL BLGESPUV TO SAVE 'DEFAULT' YES NO INIT. # OF RECORDS TO CANCEL NO
Line Cmds: D=Delete U=Update Type DOWN, UP, LEFT, or RIGHT to scroll the panel, or type END to exit.
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 panel

The 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 Managerrelated s-word to a saved problem record for a non-closed record.
483
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 Data collection Test data processing Defines the processing code and its behavior. Defines the argument for this processing. Defines the logical relation for the data used.
484
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.
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.
Figure 15-10 Control panel update
485
2. Issue the control command to go to the FUNCTION LINE SUMMARY screen for BLG1A111 as shown in Figure 15-11.
Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +===> BLM1TSCU FUNCTION LINE SUMMARY LINE 1 OF 17 FALSE MESSAGE PROGRAM TARGET PANEL EXIT/TSP
FUNC FUNC S-WORD PREFIX MULT APPLY AUTH TRUE TYPE CODE INDEX INDEX B E NOT CODE TARGET '' I5 '' '' '' '' '' '' '' **** FLOW TEST FLOW TEST FLOW TEST ADD ADD **** 002A 0000 001B 0000 001B 0000 0000 0000 **** 0000 0000 0000 0000 0000 0000 0C34 0C61 **** 0561 0340 0000 0340 0000 0340 00D8 028B * N Y N Y N Y N N * N N Y N Y N N N * N N N Y N N N N
**** ******** ******** ******** ******** 0000 BLG1ACAN 0000 0000 BLGTSPPE 0000 0000 BLGTSPPU 0000 0000 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.
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.
486
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.
Environment Dialog Record Window Options Help -----------------------------------------------------------------------------BLM8CU6A CONTROL FLOW PROCESSING PANEL: BLG1A111 Enter control flow information; cursor placement or input line entry allowed.
1. 2. 3. 4. 5. 6. 7. 8. 9.
Control line type.....<R> Function code index...... Dialog end............... Override dialog target... True target panel........ False target panel....... Authorization code....... Program exit/TSP name.... Message panel............
TEST 0000 Function acronym... __________________ NO_ NO_ ________ ________ 0000 ________ ________
When you finish type END to save or CANCEL to discard any changes.
Figure 15-12 First line option 1: Control flow processing
487
Figure 15-13 shows data collection processing for this procedure.
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. 2. 3. 4. 5. 6. 7. 8. 9.
Structured word index.... Prefix index............. Journal reply............ Journal sequence......... Cognize response......... Cognize only p-word...... Replace previous reply... Data is a date........... Cognize in mixed case?...
15A1 0000 NO_ ORDER NO_ NO_ NO_ NO_ NO_
Structured word.... Word acronym....... Prefix word........ Validation.........
XTBSMS15A1 TBSM=TBSM_OBJECT ______ _________________
Figure 15-13 First line oOption 2: Data collection processing
Figure 15-14 shows test data processing output for this procedure.
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. 2. 3. 4. 5. 6.
Begin multiple test...... End multiple test........ Structured word index.... Prefix word index........ Apply not logic.......... Case-sensitive compare?..
YES NO_ 15A1 0000 NO_ NO_
Structured word.. Word acronym..... Prefix word...... Validation.......
XTBSMS15A1 TBSM=TBSM_OBJECT ______ ________________
Figure 15-14 First line option 3: Test data processing
488
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.
1. 2. 3. 4. 5. 6. 7. 8. 9.
TEST 0000 Function acronym... CODE - UNASSIGNED NO_ NO_ ________ ________ 0000 ________ ________
Figure 15-15 Second line option 1: Control flow processing
489
Figure 15-16 shows data collection processing output for this procedure.
1. 2. 3. 4. 5. 6. 7. 8. 9.
XTBSMS15A0 TBSM=TBSM_NOTIFIED ______ _________________
Figure 15-16 Second line option 2: Data collection processing
Test data processing, shown in Figure 15-17, requires no 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. 2. 3. 4. 5. 6.
NO_ NO_ 15A0 0000 NO_ NO_
XTBSMS15A0 TBSM=TBSM_NOTIFI ______ ________________
Figure 15-17 Second line option 3: Test data processing
490
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.
1. 2. 3. 4. 5. 6. 7. 8. 9.
TEST 0000 Function acronym... __________________ NO_ NO_ ________ ________ 0000 ________ ________
Figure 15-18 Third line option 1: Control flow processing
491
Data collection processing is shown in Figure 15-19.
1. 2. 3. 4. 5. 6. 7. 8. 9.
0000 0272 NO_ ORDER NO_ NO_ NO_ NO_ NO_
__________ CODE - UNASSIGNE STAC/ <CLOSED>
Figure 15-19 Third line option 2: Data collection processing
Test data processing is shown in Figure 15-20.
1. 2. 3. 4. 5. 6.
NO_ NO_ 0000 0272 YES NO_
__________ CODE - UNASSIGNE STAC/ <CLOSED>
Figure 15-20 Third line option 3: Test data processing
492
d. The fourth line adds s-word 15A0. Control flow processing is shown in Figure 15-21.
1. 2. 3. 4. 5. 6. 7. 8. 9.
ADD_ 0000 Function acronym... CODE - UNASSIGNED NO_ NO_ ________ ________ 0000 ________ ________
Figure 15-21 Fourth line option 1: Control flow processing
493
Data collection processing is shown in Figure 15-22.
1. 2. 3. 4. 5. 6. 7. 8. 9.
XTBSMS15A0 TBSM=TBSM_NOTIFIED ______ _________________
Figure 15-22 Fourth line option 2: Data collection processing
Test data processing, shown in Figure 15-23, requires no 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. 2. 3. 4. 5. 6.
NO_ NO_ 15A0 0000 NO_ NO_
XTBSMS15A0 TBSM=TBSM_OBJECT ______ ________________
When you finish, type END to save or CANCEL to discard any changes.
Figure 15-23 Fourth line option 3: Test data processing
494
e. The fifth line invokes BLGTBSMU. Control flow processing for this procedure is shown in Figure 15-24.
1. 2. 3. 4. 5. 6. 7. 8. 9.
FLOW 001B Function acronym... CODE-FILE TSP NO_ NO_ ________ ________ 0000 BLGTBSMU ________
Figure 15-24 Fifth line option 1: Control flow processing
495
Data collection processing for this procedure is shown in Figure 15-25.
1. 2. 3. 4. 5. 6. 7. 8. 9.
0000 0000 NO_ ORDER NO_ NO_ NO_ NO_ NO_
__________ CODE - UNASSIGNED ______ _________________
Figure 15-25 Fifth line option 2: Data collection processing
Test data processing for this procedure is shown in Figure 15-26.
1. 2. 3. 4. 5. 6.
NO_ YES 0000 0000 NO_ NO_
__________ CODE - UNASSIGNED ______ ________________
Figure 15-26 Fifth line option 3:Test data processing
496
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 set

Most 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.
Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +===> BLM1TPDS LOGICAL NAME 1. WPANELS 2. RPANEL0 3. RPANEL1 TYPE CURRENT ALLOCATION DATA SET NAME DATA SETS
WRITE READ READ
TIVOLI.BLM.SC69.WPANELS TIVOLI.BLM.SC69.IBMPNLS TIVOLI.BLM.SC69.RPANEL1
Figure 15-27 Panel list
497
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.
Environment Dialog Record Window Options Help ------------------------------------------------------------------- MORE: +===> BLM1TPAL PANEL LIST DISPLAY TIVOLI.BLM.SC69.WPANELS ST PANEL NAME BLGTSPPU BLG1A111 ST PANEL NAME ST PANEL NAME ST PANEL NAME PANEL 1 OF 2
1. 2.
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.
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. 2. 3. 4.
To panel name...................... To data set definition label....<R> Replace panel...................... Copy all panels....................
________ RPANEL1_ ___ YES
To start the COPY function press Enter without field modifications.
Figure 15-29 Panel Copy specification
4. Press ENTER and exit the PMF.
498
15.5 Using the problem ticket interface

This section walks you through the implementation of the problem management user exit.
15.5.1 Manual problem ticket operation

1. 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
499
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
500
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
501
5. In the console, an icon appears beside the object as shown in Figure 15-33.
Figure 15-33 Problem ticket icon
502
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.
BLG0BU00 Reported by............ Assignee name.......... Tracked by............. Network name........... System name............ Program name........... Device name............ Key item affected......
PROBLEM SUMMARY VBUDI CEDRIC _______________ LOB TBSM D7Q2 ________ 76
PROBLEM: 00000008 OPEN ________ 01 ________ MASTER 12/12/2002 17:02 12/12/2002
Problem status.......... Current phase........... Current priority........ Owning priv. class...... Entry priv. class....... Date entered............ Time entered............ Date last altered.......
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.
Figure 15-34 Tivoli Information Management for z/OS with the problem ticket
503
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
504
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
505
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
506
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.
507
15.5.2 Closing a problem ticket

Repeat 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.
508
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.
BLG0EN20 OPTIONS: 1. 2. 3. 4. 5. 6. 7. 8. 9.
--- PRIMARY OPTIONS MENU ---
APPLICATION: MANAGEMENT
OVERVIEW.......Display general information and product enhancements. PROFILE........Display or alter invocation or session defaults. APPLICATION....Change application list available applications. CLASS..........Change current class list available classes. ENTRY..........Create a record. INQUIRY........Search for records. UTILITY........Copy display print delete and update records. GLOSSARY.......Display a list of searchable words in the database. 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
Figure 15-40 Searching Tivoli Information Management for ticket no 00000009
The search result is shown in Figure 15-41.
BLG1TSRL DATABASE: 5
SEARCH RESULTS LIST
LINE 1 OF 1
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. ===>
Figure 15-41 Search result for ticket no 00000009
509
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.
BLG0BU00 Reported by............ Assignee name.......... Tracked by............. Network name........... System name............ Program name........... Device name............ Key item affected......
PROBLEM SUMMARY VBUDI ALESSIO _______________ LOB TBSM D7Q2 ________ 76
PROBLEM: 00000009 OPEN ________ 01 ________ MASTER 12/12/2002 17:06 12/12/2002
Problem status.......... Current phase........... Current priority........ Owning priv. class...... Entry priv. class....... Date entered............ Time entered............ Date last altered.......
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
Figure 15-42 Closing problem
510
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 BLG0B300 PROBLEM CLOSE ENTRY PROBLEM: 00000009
Enter problem closing data; cursor placement or input line entry allowed.
1. 2. 3. 4. 5. 6. 7. 8. 9.
Resolved by.....<R> Resolver dept...... Resolver phone..... Resolver class..... Date closed.....<R> Time closed........ Total time......... Duplicate count.... Outage.............
VBUDI__________ ___________ _____________ ________ 12/12/2002 _____ ________ ___ ________
10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Problem status.....<R> Cause code.........<R> Program name.......... Device name........... Original prob. number. Cause change number... Fix change number..... Date rep. notified.... Rerun time............ Vendor PD time........
CLOSED_ SW______ D7Q2____ ________ ________ ________ ________ __________ ________ ________
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.
511
512
16
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
513
16.1 Failover concept and terminology

The 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. 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. The set of IBM Tivoli Business Systems Manager Windows servers that are actively processing events. The set of IBM Tivoli Business Systems Manager Windows servers that are currently inactive. The process of moving active IBM Tivoli Business Systems Manager processing from the primary site to the secondary site. The process of moving active IBM Tivoli Business Systems Manager processing from the secondary site to the primary site. 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.
Secondary Site
Source Site Target Site Failover
Reverse Failover
Log Shipping
514
Failover Scripts
a set of Korn shell scripts to perform failover configuration, transaction Log Shipping initialization, and failover execution.
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. The following sections discuss the implementation and considerations for this failover process.
16.2 Implementation of failover

This 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 Prerequisites
Prerequisites 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>
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 failover

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

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

Synchronize 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 servers time.
516
Implementing the failover code

The 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> <passw> <server> is the SQL server user ID is the password for the <sa> user ID 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
517
Editing the failover control file

First, 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 | IBMTIV5 ROLE_HistServer_Primary | IBMTIV5 ROLE_ConsoleServer_Primary | IBMTIV5 ROLE_AppServer15_Primary | IBMTIV5 ROLE_PaServer_Primary | IBMTIV5 ROLE_SnaServer_Primary | IBMTIV5 ROLE_EhServer_Primary | IBMTIV5 ROLE_SsServer_Primary | IBMTIV5 ROLE_UpLoadRuleServer_Primary | IBMTIV5 ROLE_WebServer_Primary | IBMTIV5 ROLE_HmServer_Primary | IBMTIV5 ROLE_AgentListener_Primary | IBMTIV5 ROLE_CommonListener_Primary | IBMTIV5 ROLE_TECListener_Primary | IBMTIV5 ROLE_TSDMonitor_Primary | IBMTIV5 ROLE_TGMTaskServer_Primary | IBMTIV5 # ROLE_SQLServer_Secondary | IBMTIV5 ROLE_HistServer_Secondary | IBMTIV5 ROLE_ConsoleServer_Secondary | IBMTIV5 ROLE_AppServer15_Secondary | IBMTIV5 ROLE_PaServer_Secondary | IBMTIV5 ROLE_SnaServer_Secondary | IBMTIV5 ROLE_EhServer_Secondary | IBMTIV5 ROLE_SsServer_Secondary | IBMTIV5 ROLE_UpLoadRuleServer_Secondary | IBMTIV5 ROLE_WebServer_Secondary | IBMTIV5 ROLE_HmServer_Secondary | IBMTIV5 ROLE_AgentListener_Secondary | IBMTIV5 ROLE_CommonListener_Secondary | IBMTIV5 ROLE_TECListener_Secondary | IBMTIV5 ROLE_TSDMonitor_Secondary | IBMTIV5 ROLE_TGMTaskServer_Secondary | IBMTIV5
518
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 | IBMTIV5 ROLE_HistServer_Primary | IBMTIV6 ROLE_ConsoleServer_Primary | IBMTIV3 ROLE_AppServer15_Primary | ROLE_PaServer_Primary | IBMTIV3 ROLE_SnaServer_Primary | ROLE_EhServer_Primary | IBMTIV3 ROLE_SsServer_Primary | IBMTIV3 ROLE_UpLoadRuleServer_Primary | IBMTIV3 ROLE_WebServer_Primary | IBMTIV6 ROLE_HmServer_Primary | IBMTIV6 ROLE_AgentListener_Primary | IBMTIV5 ROLE_CommonListener_Primary | IBMTIV3 ROLE_TECListener_Primary | IBMTIV5 ROLE_TSDMonitor_Primary | IBMTIV5 ROLE_TGMTaskServer_Primary | IBMTIV5 # ROLE_SQLServer_Secondary | TBSMSQL1 ROLE_HistServer_Secondary | TBSMHIST1 ROLE_ConsoleServer_Secondary | TBSMCON1 ROLE_AppServer15_Secondary | ROLE_PaServer_Secondary | TBSMCON1 ROLE_SnaServer_Secondary | ROLE_EhServer_Secondary | TBSMCON1 ROLE_SsServer_Secondary | TBSMCON1 ROLE_UpLoadRuleServer_Secondary | TBSMCON1 ROLE_WebServer_Secondary | TBSMHIST1 ROLE_HmServer_Secondary | TBSMHIST1 ROLE_AgentListener_Secondary | TBSMSQL1 ROLE_CommonListener_Secondary | TBSMCON1 ROLE_TECListener_Secondary | TBSMSQL1 ROLE_TSDMonitor_Secondary | TBSMSQL1 ROLE_TGMTaskServer_Secondary | TBSMSQL1
519
Activating failover
Failover 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/OS

Use 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.
520
SNA-based connectivity
We 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 connectivity
Two 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 failover

Once 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.
521
16.3.1 Enabling failover

Failover 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 command F 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 failover

Reverse 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
522
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 discussion

Log 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.
523
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.
524
16.5 Troubleshooting tips

Although 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.
525
526
17
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
527
17.1 Tivoli Enterprise Data Warehouse overview

Customers 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.
528
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 components

In 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.
Source Applications TEDW Environment
ITM
ITM Database
Data Mart
TEC
TEC Database
Data Mart
Source Appls ETLs
TEDW Central Data Warehouse
Target ETLs
Data Mart
TEDW Reporting Interface
Data Mart
ITMfWeb
ITM Database
Data Mart
Business Intelligence and Reporting Tools

ITMfBI
ITM Database
TEDW Control (Metadata)
IBM BRIO
Cognos
TEDW Control Center
Business Objects
Crystal Reports
Third Party
Third-Party Database
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
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
530
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.
531
17.1.2 IBM Tivoli Business Systems Manager integration

The structure of the IBM Tivoli Business Systems Manager reporting component is shown in Figure 17-2.
W indows 2000 DB2 EE Server TEDW Server TBSM E TL (G TM)
TED W Server
1
TBSM SQL D atabase Server
TW H _M D
2
TW H_CDW
Object Database
TW H _MAR T
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.
532
17.2 Installation and configuration for data warehouse

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

It 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.
533
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/v7fphis t.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. 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.
17.2.2 Setting up the source ETL

This 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.
534
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
535
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
536
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
537
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 collection

Some 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
538
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 database

The 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_CDW db2 force application all db2 terminate db2stop db2admin stop db2admin start db2start
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 Servers Object database should be defined.
539
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
540
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
541
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
542
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 Targets

You 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).
543
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
544
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
545
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
546
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
547
17.3.4 Scheduling the source ETL

In 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
548
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
549
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.
550
17.3.5 Changing the source ETL status to Production

The 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
551
17.3.6 Running ETLs

The 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.
552
Part 5
Part
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
553
554
Appendix A.
Detailed process flow of services

This appendix shows a diagram of the detailed process flow of IBM Tivoli Business Systems Manager services.
555
Tivoli Framework
Tivoli Enterprise Console
Event Enablement
Task Server
Tivoli NetView
IBM Tivoli Monitoring
AgentListener.que
Agent Listener TBSM Adapter(s)
tgmtask.exe
Common Listener Microsoft SQL Server Staged Event Loader
Console Server V2
TBSM Console
Database Validater
MVS IP Listener
Propagation Agent Dispatcher
MVS Event Handler
MVSUpload.que
Enqueue Proxy Server MVS Sender

ROOT-0001.que
Remote Execution Server
MVS IP OS Listener
pagent.exe
Object Server Data space Object Pump
RMF
Tivoli NetView for zOS
IMS
Tivoli Workload Scheduler
DB2
z/OS
System Automation
CICSPlex Systems Manager
CICS
Figure A-1 Detailed services diagram
556
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
557
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: o do # 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
558
elif [ $o = x ] then set -x else usage $0 exit 1 fi done . 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 1 fi 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 <<EOF include(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 1 fi 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.ksh
create_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 declare declare declare declare @ent_id @comp_id @mach_id @lpar_id @os_id ObjID ObjID ObjID ObjID ObjID
560
-- 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
561
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
562
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" }
563
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 source

Mainframes/ITSO Mainframes/ITSO Mainframes/ITSO Mainframes/ITSO Enterprise/ITSO//SC64Machine//Primary//SC64/ Enterprise/ITSO//SC66Machine//Primary//SC66/ Enterprise/ITSO//SC69Machine//Primary//SC69/ Enterprise/RETAIN-Test//9672-Y56//Primary//MVS1/
564
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
565
NetView adapter configuration files

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

This 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=TI7043TBSM networkid=NV0 primaryURL=capecod.itsc.austin.ibm.com.ibm.com:8080 secondaryURL=backupnetview.ibm.com:8080 contact=Peter Glasmacher description=The coolest NetView on earth
The topxlistener.properties file

Example 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
566
# # # # # # # # #
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 = ../log
adapter.working.dir
# 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/" SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">\n\t<SOAP-ENV:Bod y> # LOGGING MODE PROPERTIES
loggingmode.default loggingmode.filename
= false = 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 transport.trace.level
= medium = 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 #transport.request.address #transport.request.port #transport.response.address #transport.response.port = = = = = localhost localhost.BASETEST.QM+BASETEST.Q 9898 localhost.BASETEST.QM+BASETEST.Q 9898
transport.local.ip.address = capecod.itsc.austin.ibm.com transport.request.address = capecod.itsc.austin.ibm.com.BASETEST.QM+BASETEST.Q transport.request.port = 9898 transport.response.address = capecod.itsc.austin.ibm.com.BASETEST.QM+BASETEST.Q transport.response.port = 9898 # MQe transport properties # queue store: this key can be file or memory or reduced transport.mqe.local.queue.store = file transport.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 5 transport.mqe.usefiller = false transport.mqe.fileregistry = com.ibm.mqe.registry.MQeFileSession transport.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
568
transport.server.mqe.port transport.server.ip.address
= 8082 = ibmtiv3.itsc.austin.ibm.com
# proxy #transport.proxy.mqe.address = localProxyQM+ProxyQ #transport.proxy.mqe.port = 8083 #transport.proxy.ip.address = localhost
The topxtrapgate.conf
Example 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 Marginal 50790401 Segment Normal 50790402 Segment Marginal 50790403 Network Normal 50790404 Network Marginal 50790405 Segment Added 50790406 Segment Deleted 50790407 Network Added 50790408 Network Deleted 50790416 Manage Network 50790417 Unmanage Network 50790418 Manage Node 50790419 Unmanage Node 50790420 Manage Segment 50790421 Unmanage Segment 50790441 Manage Interface 50790442 Unmanage Interface 50790450 NT- Acknowledge Event for Client/Server 50790451 Unix Unacknowledge Event 58720263 SNMP data collection exceeded 58720264 SNMP data collection rearmed 58785792 Interface Added 58785793 Interface Deleted 58785794 Node Added 58785795 Node Deleted
569
58785796 58785797 58916864 58916865 58916866 58916867 58916868 58916869 58916871 58916966 58916967 58916968 58916969 58916970 58916971 58916972 58916973 58916974 58916975 58916976 58916977 58916978 58916979 58916982 58916983 58982400 58982401 58982402 58982403 58982404 58982405 58982406 58982407 58982408
HSRP interface added HSRP interface Deleted Node Up Node Down Interface Up Interface Down Segment Critical Network Critical SNMP Status Events Interface USER1 status User 2 status Network is now unreachable Network is reachable again Router interface is UNREACHABLE Router is DOWN Router is Unreachable Router is UP Router is Marginal Service Up Service Down Service Marginal Service Acknowledge Service Unacknowledge ISDN backup line active ISDN backup line dormant Link Level Address Changed Mismatch of Link Level Address Undetermined Link Level Address Object Identifier Change System Descr Change System Name Change Subnet Mask Change Forwarding status change Forwarding to a host
570
TBSM adapter files

This 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.
571
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 script

The 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 server SQLSERVER=ibmtiv5 # Replace XXXXX with the name of the SQL Server user account SQLUSER=sa # Replace XXXXX with the password for the SQL Server user account
572
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 entries delete_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_entries elif [ "$1" == "delete" ] ; then delete_entries else echo "Usage: nvlaunchconfig.sh add|delete" fi
573
NetView Web Server script 3beansalad.js

The 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) {
574
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();
575
576
Appendix D.
Additional material
This appendix refers to additional material from the redbook that can be downloaded from the Internet.
Locating the Web material

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

The additional Web material includes the following files: ABSJava.zip Zipped Java classes for running the ABS configuration file utility
577
SG246610.readme
Readme file for using the ABSJava.zip (similar to this appendix)
System requirements for downloading the Web material

The following system configuration is recommended: Hard disk space: Prerequisite software: 220 kb free space Java Runtime Environment (JRE) v1.3
How to use the Web material

Perform 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.
578
Abbreviations and acronyms

ABS ACF AIX AMI AMS ANSI APAR APF API APM APPC APPN ASCII BCP BMP BSM BSV CD-ROM CDW CICS CID
Automatic Business System View Advanced Communication Functions Advanced Interactive Executive Application Management Interface Application Management Specification America National Standard Institute Authorized Program Analysis Report Authorized Programming Facility Application Prorgramming Interface Application policy Management Advanced Program to Program Communication Advanced Peer-to-peer Networking American Standard Code for Information Interchange Bulk Copy Program Bitmap Business Systems Manager Business System View Compact Disc - Read-Only Memory Central Data Warehouse Customer Information Control Systems Class IDentifier
CIM CLI CMIP CPSM CPU CST CWM DASD DB2 DB2PM DBCTL DBRC DDS DFSMS DNS EBCDIC EDI EIF EMCS EOF ETL FTP GB GEM GMFHS GMT
Common Information Management Command Line Interface Common Management Information Protocol CICSPlex Systems Manager Central Processing Unit Central Standard Time Common Warehouse Model Direct Access Storage Device Database 2 Database 2 Performance Monitor Database Control Database Recovery Control Distributed Data Services Data Facility Systems Managed Storage Domain Name Services Extended Binary Coded Decimal Information Code External Data Interface Event Integration Facility Extended Multi Console Service End-of-file Extract transform load File Transfer Program Gigabyte Tivoli Global Enterprise Manager Graphics Monitoring Facility Host Subsystems Greenwich Mean Time
579
GUI HLQ HMS HSM HTML HTTP HTTPD IBM ICMP IIS IMS IMSAO IPL ISO ISPF ITM ITSO JAR JCL JDBC JES JRE JRIM JVM KB LAN LOB LPAR LRECL MB
Graphical User Interface High-Level Qualifier Health Monitoring Server Hierarchical Storage Manager Hypertext Markup Language Hypertext Transport Protocol HTTP Daemon International Business Machine Corporation Internet Control Message Protocol Internet Information Server Information Management System IMS Automated Operator Initial Program Load International Standard Organization Interactive System Productivity Facility IBM Tivoli Monitoring International Technical Support Organization Java archive Job Control Language Java Database Connectivity Job Entry Subsystems Java Runtime Environment Java RDBMS Interface Module Java Virtual Machine Kilobyte Local Area Network Line of Business Logical Partition Logical Record Length Megabyte
MCS MIB MKS MPF MRM MSDTC MVS NTFS ODBC OLAP OLDS OPC OSA OTMA PDF PDS PID PMF PPI PTF RACF RDBMS RFC RFT RMF RODM SMF SMP/E SMS
Multiple Console Support Management Information Base Mortice Kern Software Message Processing Facility MAS Resource Monitoring Microsoft Distributed Transaction Coordinator Multiple Virtual Storage NT filesystems Open Database Connectivity Online analytical processing Online log data set Operation Planning and Control Open System Adapter Open Transaction Manager Access Portable Document Format Partitioned Data set Process ID Panel Management Facility Program to program interface Program Temporary Fix Resource Access Control Facility Relational database management systems Request for Comment Report Format Table Resource Measurement Facility Resource Object Data Manager System Measurement Facility Systems Modification Program/Extended Systems Managed Storage
580
SNA SNMP SOAP SQL STC TBSM TCP/IP TEC TEDW TMR TSD TSO TSP TWS URL USS VSAM VTAM WMI WTO XCF XML XRC
Systems Network Architecture Simple Network Management Protocol Simple Object Access Protocol Structured Query Language Started Task IBM Tivoli Business Systems Manager Transmission Control Protocol/Internet Protocol IBM Tivoli Enterprise Console Tivoli Enterprise Data Warehouse Tivoli Management Region Tivoli Service Desk Time Sharing Option Terminal Simulator Program Tivoli Workload Scheduler Universal Resource Locator UNIX System Services Virtual Storage Access Method Virtual Telecommuncations Access Method Windows Management Instrumentation Write to Operator cross-system coupling facility Extensible Markup Language Extended Recovery Control
Abbreviations and acronyms
581
582
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 Redbooks
For 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 resources
These publications are also relevant as further information sources:
NetView for UNIX,Users Guide for Beginners, SC31-8891 NetView for UNIX, Administrators Guide, SC31-8892 NetView for UNIX, Administrators Reference, SC31-8893 NetView, Web Console Users 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
583
Referenced Web sites

These Web sites are also relevant as further information sources: List DLL vendor web site:
http://www.sysinternals.com
SOAP XML organizations template URLs:

http://schemas.xmlsoap.org/soap/envelope http://schemas.xmlsoap.org/soap/encoding
Microsoft SQL Server download site:

http://www.microsoft.com/sql/downloads/default.asp
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 Redbooks

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

Redbooks are also available on CD-ROM. Click Redbooks on CD in the Redbooks Web sites navigation bar for information about available CD-ROMs, as well as updates and formats.
584
Index
Numerics
1.1-TDW-0002 534 1.1-TDW-0005E 534 1.1-TDW-FP01a 534 3beansalad.js 322, 574 AMS 47 AMS definition Application 48 Business Component 48 Business Mapping 48 Business Subsystem 48 Business System 48 Software Component 48 AMS object types 91 AOPEDI 374 AOPNOTF 377 APF authorized 333 APM Heartbeat 49 Application Management Instrumentation 50 Application Management Interface, see AMI Application Management Specification 47 Application Policy Management 47, 134, 224 Application Registration Files 312 Application Server 34 ApplyUpgrade 517 ASIAgentListenerSvc 37 AsiCleanDir 443 ASICommonListener 38 ASIConsoleServerV2 34 ASIDBValidater 3132 ASIEnqueueProxyServer 34, 59 ASIEventEnablement 33 ASIHealthMonitor 37 ASILoad_Highlevel.ksh 560 ASIMVSEventHandlerSvc 36, 59 ASIMVSIPListener registry setting 65 ASIMVSIPListenerSvc 33, 65 ValidClients 66 ASIMVSIPOSListener 35 ASIMVSIPOSListenerSvc 58 ASIMVSIPSenderSvc 37, 59 ASIMVSListenerSvc 36, 58 ASIMVSSenderSvc 37, 59, 61 ASIMVSUploadRuleSvc 36, 59, 61 ASIPADispatcher 32 ASIPAgent.exe 35 ASIRemoteExecutionServer 34 ASIRuleSvc database 36, 80
A
ABS configuration file 397 ABS Creation Process job 397 ABS Discovery Process job 397 ABS Table Purge job 397 absAllowedClassAttribute 402, 407, 578 absconfig.ksh 405, 418 ABSMain 408 absTest.ksh 406 ACC1RCV 58 ACC1RECV 59 Access1 40 Accessible Software, Inc. 40, 427 ACF REFRESH 351 action type field 60 Actions.xml 312 Active Server Page, see ASP ACTNDEF 365 AddAppLauncherEntry.sh 101 AddAppLauncherMenuItem.sh 101 addLOB.sh 414 addpvToLOB.sh 414 addpvToLOBInst.sh 414 AF/Operator 28 Agent Listener 37, 46 agent listener logfile 246 aggregation 250 AIX commands netstat 298 smit 284 alert state 88 alert state attribute 88 All Resources 116 alobListCriteriaAlob table 397 alobListPattern table 397 AMI 50
585
asisp_logcleanup 442 ASIStagedEventLoader 32 ASITaskServer 33 ASITSDEventHandlerSvc 33 ASP 71 AttachDatabases.sql 189 Authentication mode 165 authority 116 AUTOAMI 362 auto-discovery 9 AUTOLOGN 342 Automated Business System, see ABS automatic logon mechanism 431 AUTOTASK 68, 341 autotrace 39
business system containment link 83 Business System View 1011, 130 business systems management 4
C
CA TNG 27 Candle AF/Operator 28 Candle Omegamon II 27 cdesc 82 CDW 530 central data warehouse, see CDW child 89 child event 89 child event matrix 89 CICS 54 CICS Transaction Server 27 CICSPlex resource 369 CICSPlex System Manager, see CPSM cid 82 CIM 250 CL_AutoPlacement table 81, 96, 263 CL_LinkRules table 81 CL_Options table 81 CL_Registration table 81, 95 CL_RegistrationList table 82 CL_Severities table 82, 97 CL_Stage table 82 CL_StageBulkData table 82, 96 CL_StageDeltaData table 82, 96 CL_StageEvData table 82, 96 CL_Status table 82, 275 clsql 110, 375 CMIP 376 cname 82 CNMSCAT2 339 CNMSTYLE 362 cno 82 Cognos 528 command security 433 commands bcp 69 clsql 110 CreateDiscoveryBatch 67 dequeue 34 dumpfqueue 34 gemeeconfig 37, 225 gemgenprod 50 gmdmmap 49
B
backslash character 60 baroc 135 base services 26 BCP 352 BCP approach 69 bcp command 69 BCP transfer 195 BLG1A111 477, 483 BLGTSPPU 481 BMC Mainview 27 BMC Patrol 27 book content 20 Brio Technology 528 BSV design 139 BSV planning 139 BSV structure 139 grouped resources 144 inverted hierarchy 143 no hierarchy 141 original hierarchy 142 Bulk Copy Program, see BCP bulk discovery 51, 62 BULK INSERT 67 bulk object discovery high-level load 63 business impact management 4 business impact views 17 business intelligence reporting 531 Business Objects 528 business system 8 Business System Container 85
586
isql 79 ping 515 rkill 515 SC 515 SCLIST 515 tgmtask 33, 68, 102 wbkupdb 211 winstall 33 wlookup 135 wlsinst 135 wlsinstl 23 wruntask 211 wtdumprl 233 wtdumptr 233 Common Information Model, see CIM common listener 38, 51, 95, 134 bulk discovery 51 delta discovery 51 event information 51 transaction ID 273 Common Management Information Protocol, see CMIP Common Warehouse Metadata 528 CommonListener log 271 components 26, 152 configuration 150 configuration file 397 Connection Properties 176 connectivity 133 console server 28, 31, 3334, 39, 44 installation 190 containment hierarchy 8486 context menu 97 correlation 250, 528 CPSM 361 CPSM commands ACTNDEF 365 RTASPEC 363 CreateDiscoveryBatch 64, 67 Crystal Decisions 528 CWM standard 528
D
data mart 531 data mining 531 data space 54 data warehouse 530 Database 2, see DB2
database engine 152 database maintanance jobs 440 Database Maintanance Plan 448 database server 28 installation 176 Database Validater 32 dataspace 334 DB2 54 DB2 Performance Monitor 27, 353 DB2_send_to_TBSM.sh 228 DBCC CHECKDB 445 debug mode 118 DefaultData database 198 DEFLOGS 335 DeleteAppLauncherMenuEntry.sh 102 DeleteAppLauncherMenuItem.sh 101 dequeue 34 detachhistorydatabases.sql 195 DFSMS 54 DFSMShsm 388 DFSYINIT 360 DFSYSVI0 360 directory alias 70 directory structure 39 discovery processing 9 discovery tasks 229 DISPPI 340 distributed environment 45 distributed resources feeds 26 distributed resources jobs 440 Distributed systems 134 dm.trc 276 dmml directory 276 document organization 20 document_print 434 domain trust 516 download page 288 DSICMD 339 DSICTMOD 341 DSIOPF 339 DSIPARM 339 DSISVRT 341 DSITBL01 339 DSPURX00 360 DUIFPMEM 340 DUIIGHB 340 dumpfqueue 34 dynamic_object_create_path table 397 dynamic_object_create_path_detail table 397
Index
587
E
ECC_TBSM_Discovery 228 EDI 350 EKGNotify method 55 enabling Reporting system 198 end-to-end view 528 Enqueue Proxy Server 34 Enterprise Manager 79 EQQUX007 373 ETL programs 530 event 10 Event Automation Services 50 Event Enablement 33 event enablement exits ihstctec 49 ihstetec 49 ihstmtec 49 ihststec 49 ihstttec 50, 227 ihstztec 50, 225 event handler server 28 event propagation 12 Event Server 59 event type child event 89 exception 89 message 89 state 89 event types 10 event views 18 exception matrix 88 EXCMD 339 exhaustive discovery 62 Extend Daily Plan job 372 extended markup language, see XML extended recovery 54
fo_commonlistener.ksh 522 fo_config 518, 520 fo_logship 520 format type field 60 Future administrators 131
G
GEM_DMtoCID table 81 GEM_DMtoID 94 GEM_IDlookup 94 GEM_InstFiltering column 416 GEM_InstFiltering table 415416 GEM_LookupCID table 81 GEM_Options table 418 gemdmmap.sh 49, 236 gemeeconfig 37, 225, 246 gemgenprod.sh 50, 230 GEMIDLookup table 81 gemimageimport.sh 232, 236 GEMLookupCID 94 gemmfprod.sh 50, 558 GMFHS 376 GPMSERVE 381 GTM 532 GTM_c05_LOBState_Process 548549 GTM_DB 541 GTM_TWH_CDW_Target 547 GTM1620I 56 GTM1770I 56 GTM1780I 56 GTM4041I 55 GTM5010I 55 GTM6BSME 478 GTM7406I 55 GTM7424I 55 GTM7815I 377 GTM8205I 55 GTM8252I 55 GTMAOPE0 33, 64, 337 GTMDSPC 334 GTMPUMP 336 GTMSAM16 379 GTMSDPRM 476 GTMSRVR 335 GTMTBSMU 478 GTMWSBD 391
F
failover 514 failover system 150 Failover.upg 517 FAT filesystem 422 files and directories permission 422 Filtering 11 flags 100 fo_chk_connectivity 525 fo_cmd_execute.ksh 522
588
H
hardware configuration 150 hardware specifications 132 health monitor 74 Health Monitor Client 199 Health Monitor Server 29, 37, 199 heap size 539 high level load 62 high-level objects 63 historical data 528 history server 28, 68 BCP approach 69 installation 194 Linked Server approach 68 HistoryServerSetup.ksh 197 histUsers table 433 HKEY_LOCAL_MACHINE 40, 427 HMS 150 HMSQueries.ksh 37, 74, 202 host integration server 28 host name 528 HTTP server 391 hyperview 15
I
IBM Object REXX 152 IBM System Automation for OS/390 27 IBM Tivoli Business Systems Manager base services 26 components 26 Web console 20 IBM Tivoli Business Systems Manager, see TBSM IBM Tivoli Enterprise Console 7, 26 IBM Tivoli Monitoring 7, 24, 27, 51, 249250 IBM Tivoli Monitoring for Databases 226 IBM Tivoli NetView 26, 51, 280 IBM Tivoli Operations, Planning, and Control 27 IBM Tivoli Storage Management Systems 27 IBM Tivoli Workload Scheduler 26 IBM Tivoli Workload Scheduler for z/OS 27 IBMConsole 121 IEA630I 56 IEAAPFxx 333 IHS$CAT2 339, 351 IHS$CMD 339 IHS$MAT 339, 351 IHS$OPF 339, 351 IHS$PARM 337
IHSBCMD 354 IHSBMAT 354 IHSBOPR 354 IHSBTBND 355356 IHSCCRUN 370 IHSCMAT1 362 ihscts 213 IHSIAO0J 359 IHSIAOE0 359 IHSIAOEC 359 IHSIAOEE 359 IHSIAOML 359 IHSICMD 358 IHSIMAT 358 IHSIMOPR 358 IHSSBCPJ 351 IHSSDISC 351 IHSSINIT 350 IHSSMAT 350 IHSSOBSX 350 IHSSSTRT 350 ihstctec 49 ihstdmai 213 ihstdmon.rls 211 ihstetec 49 ihstmtec 49 ihststec 49 ihsttec.sh 218 ihstttec 227 ihstztec 50, 225 ihszfmt 246 immediate notification 477 implementation 149 Implementation team 131 Implementation type 132 IMS 54 IMS Automated Operator 359 IMS Control Region 360 Information Management System, see IMS inheritance hierarchy 85 Input providers 131 Install.ksh 292 installation 154 console server 190 database server 176 history server 194 propagation server 190 Windows 2000 Server 154 interapp.rls 211
Index
589
IP address 528 IRXANCHR 337 isa_chain table 97, 99 isa_chain_table table 81 isa_table table 81 isql 79 isqlw 79 ITM discovery tasks 229 ITM TEC setup task 229
J
Java console 114 Java Database Connectivity 152 JDBC driver 192 JRE 47 jre130.image 252
L
Landmark TMON 27 launch_securityconsole 316 line of business 9 link_chain table 81 link_type table 81 Linked Server approach 68 LOB class 84 LOB Container 85 LOB link business system link 83 LOB, see line of business LOBC link 83 log datasets 335 log files 43 Log Shipping 514 log_ship_status 520 logging level 44 LogHeading 45 logical partitions 136 LogLevel 44 Logs directory 40 Logs$ share 40 low-level objects 63 LPAR 136 LU 6.2 session 55
mainframe resources feeds 27 MakeMVSComponent.ksh 344 Management Information Base, see MIB maps 135 MAS resource monitoring 367 master database 78 MasterDBChanges.sql 189 MCS console 54, 56 MenuItem table 97, 433 Flags 100 security values 434 message queue file 59 Meta database 80 metadata interchange 528 method_table table 81 Mgmt directory 40 MIB 282 Microsoft Distributed Transaction Coordinator, see MSDTC Microsoft Internet Information Server 152 Microsoft SQL Server 78 tuning 462 Microsoft SQL server sa password 432 Microsoft SQL Server Enterprise Manager 79 migrateToAbs.ksh 416 MKS Toolkit 152 model database 78 MONITOR command 56 MonitoredQueueTable table 208 msdb database 78, 438 msdb..log_ship_status 520 MSDTC 78 MVS 339 MVS Display Active 102 MVS Event Handler 36 MVS IP Listener 33, 379, 438 MVS IP OS Listener 35 MVS IP Sender 37 MVS Listener 36 MVS Sender Svc 37 MVS Upload Rule Server 36 MVSIPListener 352
M
mainframe component 53 mainframe data sources 349
N
NETCONV connection 340 NETCONV session 33, 68 NetIQ AppManager 27
590
netstat 298 NETVAOP 54, 340 NetView Bulk Upload 296 NetView commands launch_securityconsole 316 nvsetup 285 nvstat 295, 306 ovaddobj 285 ovstart 305 ovstatus 295, 306 ovstop 306 NetView Console 304 NetView Diagnostics 304 NetView for z/OS commands DISPPI 340 EXCMD 339 MVS 339 NetView Object Properties 304 NetView Web Console 282 launching 303 netviewd 310 Network discovery 280 networking infrastructure 133 Northwind database 78 NTFS filesystem 422 number of machines 132 nvid.conf 293, 566 nvlaunchconfig.sh 293 nvsetup 285 nvstat 295, 306 nvwcinstal.exe 288
installation 335 ObjectEvents database 32, 80 ObjectQueues database 80 Objects database 80 ObjectSync table 36 ODBC 539540 OGET 392 OLAP analysis 531 Omegamon II 55 OPC_Appl_Definition 375 OPC_Class_Definition 375 OPCLoad database 80 OPCParseDailyPlan.ksh 372 open interface 528 Open Transaction Manager Access, see OTMA operating system 152 OPERCMDS 338 OTMA 360 ovaddobj 285 ovstart 305 ovstatus 295, 306 ovstop 306 Ownership 10
P
PARMSRIP 335 password reporting system 433 Passwords 430 performance CPU 458 performance and availability portfolio 6 performance tuning 458 permission 422 directories 422 files 422 registry 428 PHYC link 83 physical containment link 83 ping 515 PMF 481, 485 PPI 339, 350 PPI receiver 54 pre-discovery 9 primary site 514 PrimaryData database 198 problem management
O
obj_class table 81 obj_link_table table 81 Object database 532 object hierarchy GEM 91 Object Management Group 528 object population download 64 object priority 88 object properties 117 object pump 54 installation 336 object registration 6061 object server 54
Index
591
closure 511 problem ticket 466, 469 TBSM operation 470 program to program interface, see PPI PROGxx 333 propagation 1112 Propagation agent 35 Propagation Agent Dispatcher 32 propagation matrix 88 propagation server 28 installation 190 properties 117
RODM database 80 RODMLoad database 80 roles 34, 125, 131, 287, 316 root cause analysis 281 ROOT object 85 RTASPEC 363
S
sa 432 registry keys 432 SA390DISCOVERY 353 SC 515 SchemaMessages.sql 189 SchemaTypes.sql 189 SCLIST 515 secondary site 514 security 421 security column 433 securityconsole.log 317 Send to TBSM 265 Server.properties 155 servers wintel 150 SETPROG 333 Simple Network Management Protocol, see SNMP Simple Object Access Protocol 51 smit 284 SMP/E 332333 SMS 385 SNA topology manager, see SNATM SNA/APPN Network object 377 SNATM 376 SNMP 280, 282 SNMP management 280 SOAP 51, 96 software level 134 software prerequisites 152 Sort Order 166 source ETL 534 running 552 scheduling 548 status 551 source site 514 Source/390 54 data space 54 object pump 54 object server 54 SQL database 7
Q
Quality Assurance 150 queue files 34, 60 SC66.que 59 SC66-Upload.que 59
R
raw data 528 RDBMS 529 RDM_LAUNCHER table 308 recentfile_view 434 Redbooks Web site Contact us xxviii rediscovery 9 REGEDT32 202 REGION size 341 Remote Execution 34 Report Interface, see RI reporting system 70 directory alias 70 Resource Measurement Facility, see RMF resource models 250 Resource Monitoring Facility, see RMF Resource Object Data Manager, see RODM Resource type window 116 reverse failover 514 RI 531 rkill 515 RMF 55, 381 RMF Distributed Data Server 381 RMFGAT 382 RMFProfile table 382 RMFProfileDef table 382 RMFProfileObjReln table 382 RODM 55
592
SQL Query Analyzer 79, 189 SQL Query Profiler 79 SQL Server Agent 78 database 438 SRC 479 SRVANY 37, 202 Staged Event Loader 32 state 88 state attribute 88 state changes 11 status observer 350 status propagation 87 alert state 88 attributes 88 object priority 88 propagation matrix 88 state 88 stored procedures 38, 82, 84, 95, 102, 446, 517 stored response chain, see SRC Super Administrator 116 system administrator 432 System Automation for OS/390 349 System Automation/390 54 System DSN 540 System Managed Storage, see SMS System Modification Program Extended, see SMP/E systems management 5 disciplines 5
T
table view 16 target ETLs running 552 target site 514 Task monitor 116 Task Server 33 TBSM class 91 command support 97 Java console 114 object registration 60 Web console 119 TBSM Adapter 255 TBSM commands absAllowedClassAttribute 402 absconfig 405 absTest 406 addLOB 414
addpvToLOB 414 addpvToLOBInst.sh 414 ApplyUpgrade 517 ASICleanDir 443 clsql 375 fo_chk_connectivity 525 fo_cmd_execute 522 fo_commonlistener 522 fo_config 518, 520 fo_logship 520 gemeeconfig 246 ihszfmt 246 MakeMVSComponent 345 migrateToAbs 416 parser 47 tgmtask 475 TBSM databases ASIRuleSvc 36, 80 Meta 80 ObjectEvents 32, 80 ObjectQueues 80 Objects 80 OPCLoad 80 RODM 80 RODMLoad 80 WebServer 80 TBSM directory structure 39 TBSM log files 43 TBSM reporting system 70 TBSM servers console server 28 database server 28 event server 28 health monitor server 29 history server 28, 68 host integration server 28 propagation server 28 SNA server 28 Web console server 28 TBSM services ASIEnqueueProxyServer, see ASIEnqueueProxyServer ASIMVSListenerSvc, see ASIMVSListenerSvc ASIMVSSenderSvc, see ASIMVSSenderSvc ASIMVSUploadRuleSvc, see ASIMVSUploadRuleSvc TBSM setemsg event 211 TBSM tables dyn_obj_path 376
Index
593
dyn_obj_path_detail 376 GEM_DMtoID 94 GEM_EEHostToEnterprise 95 GEM_HostnameToLocation 95 GEM_IDlookup 94 GEM_LocationToRegion 95 GEMLookupCID 93 isa_chain 97 MenuItem 97 opc_app_pattern 376 TBSM_for_TEDW.pdf 532 TBSM_setemsg_status_event 241 tbsma.jre_root 259 tbsma.log 309 tbsmadapter 305 tbsmatopo.log 310 tbsmatrace.log 311 tbsmatrap.log 310 tbsmbulkupload.ksh 297 tbsmstatus.rls 211 tbsmtopo 306, 309 tbsmtrap 306 TCP_SERVER_PORT 335 TCPIP_ADDRESS_BACKUP 336 TCPIP_PORT_BACKUP 336 TDS directory 40 TEC 209 TEC setup tasks 229 TEDW 527 configuration 529, 533 TEDW Control Center 531 tempdb database 78 tempinstall 176 test servers 150 tgmtask 33, 47, 68, 102, 475 commands tgmtask 108 distributed 108 tilde character 60 Tivoli BSM Database Validater 32 Tivoli BSM Enqueue Proxy Server, see ASIEnqueueProxyServer Tivoli BSM Event enablement service 213 Tivoli BSM MVS Event handler service, see ASIMVSEventHandlerSvc Tivoli BSM MVS IP Listener, see ASIMVSIPListenerSvc Tivoli BSM MVS IP OS Listener, see ASIMVSIPOSListener
Tivoli BSM MVS IP Sender service, see ASIMVSIPSenderSvc Tivoli BSM MVS Listener, see ASIMVSListenerSvc Tivoli BSM MVS Sender service, see ASIMVSSenderSvc Tivoli BSM MVS Upload Rule Server, see ASIMVSUploadRuleSvc Tivoli BSM Task Server service 213 Tivoli commands wdmconfig 256, 259 wdmdiscovery 251, 262 wdmlseng 242, 266 wdmmn 258 wdmtrceng 269 wlseng 242 wtdumprl 242 wtdumptr 243 Tivoli Distributed Monitoring 7, 27, 47 Tivoli Enterprise Console 46, 134 Tivoli Enterprise Data Warehouse 7, 530 data mart 530 ETL processes 531 ETL programs 530 source applications 530 warehouse packs 530 Tivoli Enterprise Data Warehouse, see TEDW Tivoli Framework tasks 108 Tivoli Global Enterprise Manager 7 Tivoli Management Framework 23, 216 Tivoli Management Region, see TMR Tivoli NetView for OS/390 27 Tivoli NetView for z/OS 33 Tivoli Presentation Services 119 Tivoli product 5 Tivoli software Tivoli systems management 5 Tivoli solution Configuration and Operation 5 Performance and Availability 5 Security 5 Storage Management 5 Tivoli Workload Scheduler 54 Tivoli Workload Scheduler for z/OS, see TWS for z/OS Tivoli Workload Scheduler V8s 51 tmnt_tbsm_eng 256 tmnt_tbsm_wrapper 256 TMR 33 TMW_Clearing 235 TMW_HighProcesses 267
594
tmw2k.log 269 Tmw2kProfile 252 TOPO link topology link 83 topology display 281 topology display services 40 topxgate.conf 295, 306 topxlistener.conf 294 topxlistener.properties 307, 566 topxtrapgate.conf 569 TPSTART 58, 431 trace_tmnt_tbsm_eng1.log 269 trace_tmnt_tbsm_wrapper1.log 270 transaction program 58 transport.server.ip.address 259 transport.server.mqe.port 259 tree view 14 triggers 84 trouble ticket 466 TSD Event Handler 33 TSD/390 application customization 477 NetView customization 475 TWH_CDW 531, 539 changes 539 TWH_MART 531532 TWH_MD 531 TWS for z/OS types of ETLs Central Data Warehouse 530
U
UNIX System Services 392 UpdateObjPathCache 397 UQ64483 362 USERS record 481
wdmmn 258 wdmtrceng 269 Web Application Registration Files 312 Web console 20, 119 roles 125 web console 312 Web console server 28 WebServer database 80, 433 WebSphere OS/390 27 Windows 2000 tuning 458 Windows 2000 Server 154 Windows Management Instrumentation, see WMI Windows NT permission 422 security 422 sharing 424 Windows registry 40 Windows Resource Kit 152 Winlogon 431 winlogon AutoAdminLogon 431 DefaultDomain 431 DefaultPassword 431 DefaultUserID 431 winstall 33 wintel servers 150 wlookup 135 wlseng 242 wlsinst 23, 135 WMI 250 wruntask 211 wtdumprl 233, 242 wtdumptr 233, 243
X
xdfparser 47 xdfparser directory 40 XML messages 51 XML tags 269 XRC 54
V
VTAMOPTS 377
W
warehouse pack 530 WARF 312 wbkupdb 211 wdmconfig 256, 259 wdmdiscovery 251, 262 wdmlseng 242, 266
Z
z/OS commands OGET 392 SETPROG 333 z/OS jobs 438
Index
595
596

(1.0 spine) 0.875<->1.498 460 <-> 788 pages
Back cover

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 products 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 enterprises 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 customers 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.
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL 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

SG24-6610-00 ISBN 0738427055

Tivoli Business Systems Manager V2.1 End-To-End Business Impact Management Sg246610

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tivoli Business Systems Manager V2.1 End-To-End Business Impact Management Sg246610

Încărcat de

Drepturi de autor:

Formate disponibile

Front cover

Tivoli Business Systems Manager Version 2.1

Copyright IBM Corp. 2003. All rights reserved.

Copyright IBM Corp. 2003. All rights reserved.

17-15 17-16 17-17 17-18 17-19 17-20 17-21 A-1

Copyright IBM Corp. 2003. All rights reserved.

Copyright IBM Corp. 2003. All rights reserved.

The team that wrote this redbook

Copyright IBM Corp. 2003. All rights reserved.

Become a published author

Send your comments in an Internet note to:

Concept and planning

Copyright IBM Corp. 2003. All rights reserved.

Introduction to business systems management

Copyright IBM Corp. 2003. All rights reserved.

1.1 Business systems management

1.2 Tivoli systems management product

Monitoring Analysis Central Console Reporting

Centralized Control Service Delivery Web Management Pervasive Management

Access Management Indentity Management Risk Management

Chapter 1. Introduction to business systems management

IBM Tivoli Business Systems Manager

Event Correlation and Automation

IBM Tivoli Service Level Advisor

IBM Tivoli Web Site Analyzer

IBM Tivoli NetView

IBM Tivoli Enterprise Console IBM Tivoli Enterprise Data Warehouse

Monitor Systems and Applications

IBM Tivoli Monitoring

Figure 1-2 Tivoli performance and availability solutions

1.3 IBM Tivoli Business Systems Manager

Chapter 1. Introduction to business systems management

1.3.1 Business system

1.3.2 Discovery processing

Chapter 1. Introduction to business systems management

1.3.3 Event processing

Chapter 1. Introduction to business systems management

Figure 1-3 TBSM console: propagation path

Chapter 1. Introduction to business systems management

Figure 1-4 TBSM console: tree view

Figure 1-5 TBSM console: Hyperview

Chapter 1. Introduction to business systems management

Figure 1-6 TBSM console: Table view

Figure 1-7 TBSM console: Business impact view

Chapter 1. Introduction to business systems management

Figure 1-8 TBSM console: events view

Figure 1-9 TBSM properties window

Chapter 1. Introduction to business systems management

Figure 1-10 TBSM Web console

1.4 Document organization and scope

Table 1-1 Reading paths

Implementing IBM Tivoli Business Systems Manager in z/OS environment

Maintaining IBM Tivoli Business Systems Manager

Chapter 16, High availability and failover on page 513

Chapter 17, Historical reporting with TEDW on page 527

Chapter 1. Introduction to business systems management

1.5 Lab environment

ibmtiv3 Windows 2000 Console V2 Server Propagation Server Common Listener

3C041 Windows 2000 Event Server

CapeCod AIX 5.1 Netview 7.1.2

SC64 - z/OS TBSM Source/390 Netview 5.1 TWS 8.1

SC66 - z/OS TBSM Source/390 Netview 5.1 RODM CICS CICSPlexSM

ibmtiv8 Windows 2000 Server Endpont