Ibm tivoli monitoring for network performance v2.1 the mainframe network management solution sg246360

Front cover

IBM Tivoli Monitoring for
Network Performance V2.1
The Mainframe Network Management Solution

Managing TCP/IP network performance
from z/OS

Sample implementation
scenarios

Operational examples
and tips

Budi Darmawan
Venugopal Devarasetti
Gary Kalatucka
Garth Madella
Tian Huat Peh
Giancarlo Rodolfi

ibm.com/redbooks

International Technical Support Organization

IBM Tivoli Monitoring for Network Performance V2.1:
The Mainframe Network Management Solution

October 2004

SG24-6360-00

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

First Edition (October 2004)

This edition applies to Version 2, Release 1, Modification 0 of IBM Tivoli Monitoring for Network
Performance (product number 5698-FNP).

© Copyright International Business Machines Corporation 2004. 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

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Chapter 1. Introduction to network performance monitoring . . . . . . . . . . . 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 The automation blueprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 IBM Tivoli Monitoring for Network Performance . . . . . . . . . . . . . . . . . . . . . 4
1.4 Redbook environment and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Document organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 2. Components and architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Components and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Web application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Web application structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Web application user interface functions . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Role-based security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.4 Problem determination for Web application . . . . . . . . . . . . . . . . . . . 19
2.3 Monitor functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1 Process structure of the monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.2 Files used by the monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.3 Performance data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.4 Setting options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.5 Problem determination for the monitor . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Communication and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.1 User authentication mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.2 Communication port usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.3 Certificates and authentication with SSL. . . . . . . . . . . . . . . . . . . . . . 38
2.4.4 Transport between DB2 and monitor . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5 Database structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5.1 Configuration tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5.2 Measurement tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Chapter 3. Implementation scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1 Implementation components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

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

3.2 Implementation scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.1 Distributed servers environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.2 Pure z/OS environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3 Scenario comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.1 Distributed consideration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.2 z/OS only consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.3 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4 Scenario implementation roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.5 User operation and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 4. AIX Web application implementation . . . . . . . . . . . . . . . . . . . . 57
4.1 Web application on AIX overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Preparing for the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.1 File system space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.2 Setting up the Java Messaging Service . . . . . . . . . . . . . . . . . . . . . . 61
4.2.3 User authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.4 Enabling DB2 password encryption . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2.5 WebSphere access to DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3 Web application implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.1 Implementation steps overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3.2 Web application installation details . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.3 Setting up LDAP in z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3.4 Configuring WebSphere Application Server for LDAP on z/OS . . . . 74
4.3.5 Verification of the distributed implementation . . . . . . . . . . . . . . . . . . 78
4.4 Some problems and their solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.4.1 Problem with console users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.4.2 LDAP user ID character constraint . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.4.3 Uninstallation from admin console . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.4.4 Set up the X-windows DISPLAY properties to enable graphics . . . . 86
4.4.5 LTPA key generation problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.4.6 Problem with SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.5 Start and stop procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.6 Backup and recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.6.1 File system backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.6.2 DB2 database backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.6.3 DB2 database restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.6.4 File system restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Chapter 5. Mainframe Web application implementation . . . . . . . . . . . . . 101
5.1 Scenario overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.2 Preparing for the implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.2.1 Preparing HFS files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.2.2 Preparing DB2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

iv IBM Tivoli Monitoring for Network Performance V2.1: The Mainframe Network Management Solution

5.2.3 Graphic package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.2.4 Preparing WebSphere Application Server . . . . . . . . . . . . . . . . . . . 110
5.3 Web application implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.3.1 Installation procedure overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.3.2 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.4 Start and stop procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.4.1 Start up the Web application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.4.2 Shut down the Web application. . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.5 Backup and recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.5.1 Backup and restore of file systems . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.5.2 Backup and restore of DB2 database . . . . . . . . . . . . . . . . . . . . . . . 121

Chapter 6. Monitor implementation and operation . . . . . . . . . . . . . . . . . 125
6.1 Monitor installation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.1.1 Before the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.1.2 Preparing the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.1.3 Parameters for itmnp.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.2 Some problems and their solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6.2.1 Missing Tivoli common directory . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.2.2 Setting APF authorized attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.3 Start and stop procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
6.4 Sample monitor configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.5 Monitoring best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.5.1 Monitored metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.5.2 Monitoring configuration design . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.5.3 Monitoring information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.5.4 Monitoring storage usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.5.5 Monitoring network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Chapter 7. Discovery and alert interfaces. . . . . . . . . . . . . . . . . . . . . . . . . 161
7.1 NetView Integrated TCP/IP services component . . . . . . . . . . . . . . . . . . 162
7.1.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
7.1.2 Configure NetView Integrated TCP/IP Services Component . . . . . 162
7.1.3 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
7.2 Event integration with IBM Tivoli Enterprise Console . . . . . . . . . . . . . . . 164
7.2.1 Customizing TEC rulebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
7.2.2 Configuring event forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.2.3 Sample event automation program . . . . . . . . . . . . . . . . . . . . . . . . . 173
7.3 Event integration with IBM Tivoli NetView for z/OS. . . . . . . . . . . . . . . . . 175
7.3.1 Setting up Event Automation Service . . . . . . . . . . . . . . . . . . . . . . . 176
7.3.2 Defining threshold and event generation . . . . . . . . . . . . . . . . . . . . 177
7.3.3 Automating NetView alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Chapter 8. Historical reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Contents v

8.1 Tivoli Data Warehouse overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
8.2 Tivoli Data Warehouse setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
8.2.1 Installation for distributed data source . . . . . . . . . . . . . . . . . . . . . . 186
8.2.2 Installation for mainframe data source . . . . . . . . . . . . . . . . . . . . . . 186
8.3 Installation of the Warehouse Enablement Pack. . . . . . . . . . . . . . . . . . . 187
8.3.1 Back up TWH databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
8.3.2 Warehouse Enablement Pack installation. . . . . . . . . . . . . . . . . . . . 188
8.4 ETL processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
8.4.1 ETL overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
8.4.2 Testing, scheduling, and promoting the ETLs . . . . . . . . . . . . . . . . . 199
8.5 Sample reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
8.5.1 Configuring Crystal Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
8.5.2 Available reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
8.5.3 Accessing the Crystal ePortfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Appendix A. ITMNP configuration files and test programs. . . . . . . . . . . 217
AIX itmnp.properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
z/OS itmnp.properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Sample server TSO REXX program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Sample object REXX client program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Appendix B. z/OS LDAP SDBM back end configuration files . . . . . . . . . 223
z/OS LDAP setup configuration file: ldap.profile . . . . . . . . . . . . . . . . . . . . . . 224
z/OS LDAP configuration file: SLAPDCNF. . . . . . . . . . . . . . . . . . . . . . . . . . . 225
z/OS LDAP started procedure: LDAPSRV . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Appendix C. Tips collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
WebSphere Application Server Version 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
J2EE based application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Startup and shutdown procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
DB2 Universal Database Version 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Relational database system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
DB2 on z/OS systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
DB2 on AIX or Window systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Differences between z/OS and distributed DB2 processing . . . . . . . . . . . 231
Important tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
z/OS Communication Server TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
IBM Tivoli NetView for z/OS Version 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Alerts structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Automation support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Event automation service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
IBM Tivoli Enterprise Console Version 3.9. . . . . . . . . . . . . . . . . . . . . . . . . . . 235
IBM Tivoli Enterprise Console structure . . . . . . . . . . . . . . . . . . . . . . . . . . 235

vi IBM Tivoli Monitoring for Network Performance V2.1: The Mainframe Network Management Solution

IBM Tivoli Data Warehouse Version 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Data warehouse concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Warehouse enablement pack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Appendix D. Underlying technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Light-weight Directory Access Protocol (LDAP) . . . . . . . . . . . . . . . . . . . . . . . 242
eXtensible Markup Language (XML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Microsoft Excel for browsing XML files . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Certificates and encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Secret Key Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Public Key Cryptography. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Refinements on cryptographic techniques . . . . . . . . . . . . . . . . . . . . . . . . 256
Secure Sockets Layer protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
The Record Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
The communication protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Contents vii

viii IBM Tivoli Monitoring for Network Performance V2.1: The Mainframe Network Management Solution

Notices

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

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

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

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

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

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

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

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

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

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

© Copyright IBM Corp. 2004. All rights reserved. ix

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

AIX® IMS™ RDN™
Cloudscape™ iSeries™ RMF™
CICS® Lotus® SecureWay®
Database 2™ MQSeries® System/390®
Domino® MVS™ Tivoli Enterprise™
DB2 Universal Database™ NetView® Tivoli Enterprise Console®
DB2® OS/390® Tivoli®
Eserver® pSeries® VTAM®
Eserver® Redbooks™ WebSphere®
IBM® Redbooks (logo) ™ z/OS®
ibm.com® RACF® zSeries®

The following terms are trademarks of other companies:

Microsoft, Windows, 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.

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

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

x IBM Tivoli Monitoring for Network Performance V2.1: The Mainframe Network Management Solution

Preface

This IBM® Redbook explains the new IBM Tivoli Monitoring for Network
Performance Version 2.1. This version of IBM Tivoli Monitoring for Network
Performance provides a complete redesign of the z/OS® TCP/IP management
tools that was started by the NetView® Performance Monitor for TCP/IP.

IBM Tivoli Monitoring for Network Performance provides a comprehensive
TCP/IP stack monitoring for z/OS. It collects performance metrics from the z/OS
Communication Servers system management interface, measuring response
time and Simple Network Management Protocol (SNMP) Management
Information Base (MIB) variable collection.

IBM Tivoli Monitoring for Network Performance uses strategic IBM software
platforms, such as WebSphere® Application Server, as the Web application
platform, and DB2® Universal Database™ as the central repository.

This redbook starts with exploring the architecture of IBM Tivoli Monitoring for
Network Performance and its components. We also discuss various
implementation scenarios and evaluate the benefits and drawbacks of each
scenario. Implementation planning and consideration is presented and
operational consideration is explained.

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.

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

Figure 1 The redbook team

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 on distributed and z/OS. Before
joining the ITSO five years ago, Budi worked in IBM Indonesia as a lead IT
Specialist performing implementation services and solution architecting. His
current interest is advanced business service management solution.

Venugopal Devarasetti is a Software Engineer at IBM Software Labs,
Bangalore, India. He has been with IBM for four years, after receiving his
Engineering degree from Kuvempu University, India. He has been involved with
the IBM Java™ Development Kit on AIX® and z/OS. His area of expertise
includes J2EE, Web Services, and JVM Internals.

Gary Kalatucka is a Senior IT Consultant for Tivoli® Services Americas in the
United States. He has 26 years of experience in the z/OS field, including four
years of Tivoli software experience. His areas of expertise include z/OS, SNA,
z/OS Automation products, and various Tivoli software products.

Garth Madella is a Information Technology Specialist with IBM South Africa. He
has 18 years of experience in the System/390® networking field. He has worked
with IBM for eight years. His areas of expertise include VTAM®, SNA TCP/IP,

xii IBM Tivoli Monitoring for Network Performance V2.1: The Mainframe Network Management Solution

and sysplex. He has written extensively on TCP/IP and Enterprise Extender
issues.

Tian Huat Peh is a Advisory IT specialist with IBM Singapore. He has nine years
of experience in the OS/390® system and TCP/IP field. His areas of expertise
include z/OS USS, OSA-Express implementation, and z/OS TCPIP
implementation.

Giancarlo Rodolfi is a zSeries® Certified Consultant TSS in Brazil. He has 18
years of experience in zSeries field. His areas of expertise include zSeries and
Linux. He has written extensively on z/OS Communication Server.

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

Wade Wallace
International Technical Support Organization, Austin Center

Bob Haimowitz and Richard M Conway
International Technical Support Organization

Laura Knapp and Douglas Gibbs
IBM US, Tivoli Software

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.

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

Preface xiii

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 online Contact us review redbook form found 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

xiv IBM Tivoli Monitoring for Network Performance V2.1: The Mainframe Network Management Solution

1

Chapter 1. Introduction to network
performance monitoring
This chapter introduces you to the network performance monitoring, specifically
TCP/IP network performance monitoring. It begins by putting performance
management in context and develops the discussion of the usage of IBM Tivoli
Monitoring for Network Performance in this perspective.

The discussion in this chapter is divided into the following sections:
1.1, “Introduction” on page 2
1.2, “The automation blueprint” on page 2
1.3, “IBM Tivoli Monitoring for Network Performance” on page 4
1.4, “Redbook environment and scope” on page 5
1.5, “Document organization” on page 5

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

1.1 Introduction
Mainframes are playing a vital role in the current network computing environment
and on-demand initiatives. They serve as the premier servers servicing hundreds
and thousands of users. These mainframes are interconnected together and they
interact with other machines and services through the network. Primary
communication protocol shifted from the traditional Systems Network
Architecture (SNA) to the Transmission Control Protocol/Internet Protocol
(TCP/IP). This introduces a new challenge for managing the TCP/IP network
communication on these mainframe servers.

The IBM Tivoli Monitoring for Network Performance provides the facility to
manage all aspects of TCP/IP communication from the z/OS’s IBM
Communication Server TCP/IP. IBM Tivoli Monitoring for Network Performance
Version 2.1 brings a new management paradigm on this area. It is a complete
re-design of the product from previous versions and NPM/IP product.

This redbook discusses the new IBM Tivoli Monitoring for Network Performance
Version 2.1 implementation and operation scenarios. Since this is a critical
component in the overall system management and automation environment, we
will also discuss its role in the automation blueprint.

1.2 The automation blueprint
The IBM Tivoli solution is the base of providing automation on the overall system
management for the on demand world. Automation is so critical for businesses to
achieve resiliency, efficiency, responsiveness, and flexibility. The IBM
automation platform shows the structure of the automation components in
providing on demand automation capability. The IBM automation blueprint is
shown in Figure 1-1 on page 3.

2 IBM Tivoli Monitoring for Network Performance V2.1: The Mainframe Network Management Solution

Business Service Management

Policy Based Orchestration

Availability Assurance Optimization Provisioning

Virtualization
Software Resources System Resources

Figure 1-1 IBM automation blueprint

The IBM automation blueprint is a game-changing plan for reducing the
complexity of technology to allow you to focus on the business goals and the
application of resources to business objectives rather than the management of
technology. The blueprint enables enterprises to implement automation in an
evolutionary fashion that acknowledges the heterogeneous nature of the
infrastructure.

At the bottom of the blueprint is the foundation – the Software and System
Resources with native automation capabilities required for higher level
automation functions. Many of these resources may be virtualized to the other
capabilities. Here, the key point is that in order to achieve the highest levels of on
demand automation, resources need to be virtualized so that they can be
dynamically provisioned as business policies require.

Above the resources are the key automation capabilities:
Availability helps ensure that systems are available 24x7.
Reliance or security keeps your systems protected from threats and provides
the functions for a great user experience in accessing applications and data
they need – while keeping out unwelcome users.

Chapter 1. Introduction to network performance monitoring 3

Optimization provides tools to make the most of the resources you have – so
that they are running at peak performance and efficiency and providing you
with the maximum return on your investment.
Provisioning focuses on the self-configuring, dynamic allocation of individual
elements of your IT infrastructure – so that Identities or Storage or Servers
are provisioned as business needs dictate.

The next layer, Policy-based Orchestration, helps customers automatically
control all the capabilities of the four areas we just discussed so that the entire IT
infrastructure is responding dynamically to changing conditions according to
defined business policies. This orchestration builds on the best practices of the
customer’s collective IT experience, and helps to ensure that complex
deployments are achieved with speed and quality – on demand.

Finally, Business-driven Service Management capabilities provide the tools you
need to manage service levels, meter system usage and bill customers for that
usage, as well as model, integrate, connect, monitor, and manage your business
processes end-to-end for complete linkage of IT and business processes. Being
able to view IT resources in context of business systems is a unique capability
that we need.

The IBM Tivoli Monitoring for Network Performance provides availability
monitoring for mainframes TCP/IP network servers. It resides in the availability
function and provides networking server performance monitoring.

1.3 IBM Tivoli Monitoring for Network Performance
IBM Tivoli Monitoring for Network Performance Version 2.1 provides a
centralized monitoring of the TCP/IP networking protocol.

IBM Tivoli Monitoring for Network Performance meets your daily tactical needs
as well as your long-term strategic systems management goals, providing an
effective way to gain control of mission-critical network resources, performance
issues, and workload distributions. IBM Tivoli Monitoring for Network
Performance provides timely analysis of performance related metrics, such as
response time, traffic flow, system workload, and CPU utilization.

Using the IBM Tivoli Monitoring for Network Performance Web application,
operators can monitor the performance of the network in an effort to anticipate
problems and resolve them before they occur. The performance data can be
used to detect bottlenecks and other potential problems, which eliminates the
need for network systems programmers to manually scan through extensive
amounts of performance data. The network systems programmer can use this
data to perform detailed problem determination for problems that cannot be


resolved by the network operators. In addition, the network systems programmer
can use this data to validate service level agreements and improve network
performance through network tuning. After the data is summarized and
aggregated into the Tivoli Data Warehouse, the capacity planner can use this
data to do trend analysis and forecasting to improve performance and better plan
for network growth.

1.4 Redbook environment and scope
This redbook discusses the implementation and operation scenarios of the IBM
Tivoli Monitoring for Network Performance Version 2.1. The discussion is divided
into two scenarios: the mainframe based scenario and the combination of
mainframe and distributed scenario.

The detailed environment is presented in 3.4, “Scenario implementation
roadmap” on page 54.

1.5 Document organization
The discussion in this document is divided into the following chapters:
Chapter 1, “Introduction to network performance monitoring” on page 1, this
chapter, serves as the book introduction.
Chapter 2, “Components and architecture” on page 7 explains, in detail, the
IBM Tivoli Monitoring for Network Performance components and their
interaction.
Chapter 3, “Implementation scenarios” on page 47 discusses possible
implementation scenarios and how we will discuss them in this redbook.
Chapter 4, “AIX Web application implementation” on page 57 explains the
implementation of the AIX-based Web application.
Chapter 5, “Mainframe Web application implementation” on page 101
explains the implementation of the z/OS-based Web application.
Chapter 6, “Monitor implementation and operation” on page 125 explains the
monitoring components and some discussion in monitoring process.
Chapter 7, “Discovery and alert interfaces” on page 161 describes integration
with IBM Tivoli NetView for IP resource discovery and also alerts usage with
IBM Tivoli Enterprise™ Console or IBM Tivoli NetView for z/OS.
Chapter 8, “Historical reporting” on page 183 explains the data collection
implementation for IBM Tivoli Monitoring for Network Performance data.

Chapter 1. Introduction to network performance monitoring 5

The appendices provide program listing and additional information for your
reference in reading this redbook.


2

Chapter 2. Components and
architecture
This chapter discusses the product architecture of IBM Tivoli Monitoring for
Network Performance. This chapter includes the following sections:
2.1, “Components and functions” on page 8 discusses the primary
components of IBM Tivoli Monitoring for Network Performance and their
functions.
2.2, “Web application” on page 10 describes the Web application structure.
2.3, “Monitor functions” on page 22 explains the monitoring subsystem.
2.4, “Communication and security” on page 34 shows the communication
between the components of IBM Tivoli Monitoring for Network Performance.
As it is a distributed application, security of the communication is of a
concern.
2.5, “Database structure” on page 41 describes the underlying data structure
for IBM Tivoli Monitoring for Network Performance.

© Copyright IBM Corp. 2004. All rights reserved. 7

2.1 Components and functions
IBM Tivoli Monitoring for Network Performance monitors the performance of the
TCP/IP network in your enterprise from the mainframe perspective. Performance
data from all monitored systems are stored in a central DB2 database. The data
collected by IBM Tivoli Monitoring for Network Performance can be accessed
using the Web application and also be used as source information for historical
reports generation using Tivoli Data Warehouse.

The basic function of the IBM Tivoli Monitoring for Network Performance is to
collect performance data, which requires you to install the IBM Tivoli Monitoring
for Network Performance monitor component on each of the z/OS systems that
you want to monitor. In addition, you must install the IBM Tivoli Monitoring for
Network Performance Web application on a system that has WebSphere
Application Server and DB2 database run. The supported operating systems for
the IBM Tivoli Monitoring for Network Performance Web application are z/OS
and AIX.

Figure 2-1 shows the overall IBM Tivoli Monitoring for Network Performance
architecture.

NetView
Integrated TCP/IP WebSphere Application Server
Services Component IBM Tivoli
IBM Tivoli Monitoring
Monitoring for
Windows/AIX for Network
JMS Network
Performance
Performance
Web Application
monitor
DB2
z/OS

Monitor
Configuration
Tivoli Data
Warehouse Performance IBM Tivoli
Server Central Data data
Enterprise Console
Warehouse and
Crystal Data marts AIX or z/OS
Enterprise IBM Tivoli NetView
Server for z/OS
Windows

Figure 2-1 IBM Tivoli Monitoring for Network Performance components

As shown in Figure 2-1, the IBM Tivoli Monitoring for Network Performance
architecture consists of several components. The required components are
shown in the darker boxes, while optional components are shown in white boxes
and connected by dotted lines.


The required components are:
WebSphere Application Server and DB2: The WebSphere Application Server
and the DB2 are required for the IBM Tivoli Monitoring for Network
Performance Web application. Both components must be run on the same
server. WebSphere Application Server provides the platform for running the
IBM Tivoli Monitoring for Network Performance Web application. DB2 acts as
the central repository that contains a database that holds the configuration
and performance data. See 2.5, “Database structure” on page 41 for more
information.
Web application: The IBM Tivoli Monitoring for Network Performance Web
application runs as a WebSphere Application Server application. It is installed
using Install Shield Multi-Platform (ISMP) on AIX or Windows® platform or
using a script from the UNIX® Systems Services command line for z/OS. The
product interface is a role-based Web application that is accessible from your
Web browser. The Web Application provides the interface to view and
configure the IBM Tivoli Monitoring for Network Performance environment.
See 2.2, “Web application” on page 10 for more information.
Monitors: The IBM Tivoli Monitoring for Network Performance Monitor is
configured and runs on each z/OS operating system. The monitor performs
three separate functions: collect performance data for the z/OS operating
system, collect SNMP data from configured IP addressable, and collect
availability and response time data from IP-addressable resources in the
enterprise that the monitor is able to ping. In a normal configuration, there
would be multiple instances of the z/OS monitors recording data to the DB2
database for the IBM Tivoli Monitoring for Network Performance Web
application. See 2.3, “Monitor functions” on page 22 for more information.

The optional components are:
Event receivers: IBM Tivoli Monitoring for Network Performance can be
configured to forward events in Event Integration Facility (EIF) format. This
means that the events can be forwarded to IBM Tivoli Enterprise Console®
(TEC) or IBM Tivoli NetView for z/OS. IBM Tivoli Monitoring for Network
Performance provides the necessary TEC classes to receive events. Events
forwarded to IBM Tivoli NetView for z/OS need to be received using the Event
Automation Service.
NetView Integrated TCP/IP Services Component (ITSC): It is highly
recommended you install the NetView Integrated TCP/IP Services
Component, which provides automatic discovery of IP-addressable resources
in your enterprise. ITSC can discover and classify any IP-addressable
resources that are running SNMP agent. The SNMP information can be
queried for additional information, such as resource type, which can be used
to group these resources into SmartSets. It can automatically detect z/OS
systems and other TCP/IP stack information from z/OS. NetView Integrated

Chapter 2. Components and architecture 9

TCP/IP Services Component software is provided with IBM Tivoli Monitoring
for Network Performance.
Tivoli Data Warehouse: IBM Tivoli Monitoring for Network Performance
captures performance data that can be collected into Tivoli Data Warehouse.
Tivoli Data Warehouse is a strategic cross-application infrastructure for
collecting historical data and generating reports. IBM Tivoli Monitoring for
Network Performance provides a set of extract, transform, and load (ETL)
programs utilities to summarize and migrate historical performance data to
Tivoli Data Warehouse. Historical data stored in Tivoli Data Warehouse is
used to generate historical performance reports using Crystal Enterprise,
which is provided as part of Tivoli Data Warehouse.

2.2 Web application
The Web application is the main component of IBM Tivoli Monitoring for Network
Performance. It serves as the central contact point for other components. It uses
WebSphere Application Server and DB2 database. This section discusses the
structure of the Web application. The discussion is divided into:
2.2.1, “Web application structure” on page 10
2.2.2, “Web application user interface functions” on page 12
2.2.3, “Role-based security” on page 17
2.2.4, “Problem determination for Web application” on page 19

2.2.1 Web application structure
Figure 2-2 on page 11 shows the overview of the Web application components
and their connections.


itmnp21 Enterprise Application

JMS messaging JDBC interface
ITMNPDB

ITMNP ITMNP
JMX EJB

itmnpItsc itmnpUI
SERVLETs Web interface

Netview ITSC
monitors Web browser
nvexportd

Figure 2-2 The Web application component structure

The Web application consists of several modules. Some of these modules have
external interfaces to interact with other components. The following are the
modules of the itmnp21 J2EE application:
The itmnpJMX is a Java resource module that contains Java Management
eXtension classes. These classes are subclasses that represent the JMX
objects that reside in the monitors. This is an internal component of the Web
application. This resource package for the JMX connector is stored in a
resource archive (rar) file.
The itmnpEJB module is an Enterprise Java Beans (EJBs) module for
WebSphere Application Server. This module consists of EJBs for various
objects that are managed by IBM Tivoli Monitoring for Network Performance,
such as nodes, ITSC processes, commands, and so on. These EJBs provide
the means to search and retrieve objects from a relational database through
Java programs. Some of the objects here communicate using Java
Messaging Service (JMS).
The itmnpItsc module is the module that uses servlets and interacts with
EJBs for IBM Tivoli Monitoring for Network Performance. It provides the
interface to the monitors and NetView ITSC. The z/OS version of this module
does not support SSL or HTTPS communication. This module utilizes the
EJB and JMX modules for IBM Tivoli Monitoring for Network Performance.
The itmnpUI module is the Web application user interface module that
interacts with an operator using a Web browser. This module contains Java


Server Pages and static Web content for the operator Web console. This
module can be accessed using either HTTP or HTTPS protocol on all
platforms.
Database access is performed though the JDBC interface to the DB2
database.

2.2.2 Web application user interface functions
The Web application serves the IBM Tivoli Monitoring for Network Performance
user interface to a Web browser. This section describes the user interface
functions of the Web application:
A product interface for a user to access by browser
The user interface is a role-based Web application that is accessible from a
Web browser. When security is enabled, a user name and password are
required to sign on to the Web application. The initial login window is shown in
Figure 2-3. The Administrator Full Access check box allows configuration and
maintenance functions to be available when the user is authorized.

Figure 2-3 Initial login window

Function based portfolio
When the user is initially logged in, the left side of the window contains the
menu portfolio that the user can access. Figure 2-4 on page 13 shows a user


with administrator role menu. It has both the display and management menus.
The management options are shown in the red box.

Figure 2-4 Portfolio menu for an administrator

Maintains and manages the configuration for the monitors
The Web application provides three configuration wizards to create the
monitor definition. The wizards are for:
– z/OS monitor
– SNMP monitor
– Availability and response time monitor
The following are the steps that you will go through with the wizard:
– Defines one or more monitor locations
The monitor location table contains the z/OS system name and IP address
(or fully qualified host name) of one or more monitors in your enterprise.


The IP addresses or host names that you enter into this table are used by
the IBM Tivoli Monitoring for Network Performance Web application when
communicating with the monitor component.
– Provides a list of resources to monitor
The list of resources to monitor will differ dependent on the type of monitor
definition you are creating.
• z/OS monitor definition: You will specify the list of TCP/IP stacks on
each z/OS system that you want to monitor. By default, you will monitor
the TCP/IP stack you provided when you defined the monitor locations.
If the z/OS systems you are monitoring has multiple TCP/IP stacks,
you will provide the IP address or fully qualified host name of each
additional stack that you want to monitor. The TCP/IP stacks must
reside on the same z/OS system where the monitor resides.
• SNMP monitor definition: You will specify the IP address or fully
qualified host name of each resource you want to monitor. You must
have network connectivity to each of these resources from the monitor
and the SNMP agent must be running on each of these resources in
order to retrieve data using an SNMP query.
• Availability and Response Time monitor definition: You will specify the
IP address or fully qualified host name of each resource you want to
monitor for availability and response time. In order to collect availability
and response time data, you must be able to ping each of these
resources from the monitor. Availability and Response time monitor
definitions should be created to monitor the most critical IP resources
in your environment.
– Specifies the type of data to collect
The type of data to collect will differ depending on which type of monitor
definition you are creating.
• z/OS monitor definition: You will choose from a list of 10 different
categories of data to collect, such as TCP, IP, UDP, FTP, and so on.
• SNMP monitor definition: You will chose from a list of MIBS that
contain performance data.
• Availability and Response Time monitor definition: Availability and
response time data will be collected for each of the resources you are
monitoring.
– Specifies threshold and rearm values
Threshold values can be specified for each monitored metric. The
threshold value is used to determine the point to which an alert is
generated. Each piece of performance data that is collected by the
monitor is compared to the threshold value to determine if the threshold


has been crossed for all data that has been displayed on the user
interface. If the threshold has been crossed, a red indicator will be placed
next to the value of that metric when it is displayed. In addition, you can
choose to generate an event when a threshold is crossed.
– Define schedule: Collection time and interval
A schedule entry defines the day of the week and time that you want to
start collecting data and the day of the week and time that you want to
stop collecting data. Additionally, for each schedule entry, you will define a
collection interval and frequency.

Note: Data collection for FTP and TN3270 sessions happens
immediately following the completion of the session. This data is not
stored based on the interval. Multiple monitor definitions that request
the same data are combined to collect the data only once.

When different collection definitions contain different schedules for similar
data, IBM Tivoli Monitoring for Network Performance data collection
engine must choose which intervals are used. The basic algorithm for
collecting z/OS Communications Server data is as follows:
i. It selects the shortest collection interval from all the collection
instruction.
ii. If more than one definition is currently active that have the same
collection interval, it chooses one based on the order in which the
definitions were delivered to the monitor component, meaning the
order is an arbitrary choice by the monitor.
Sets operation preferences for the environment
You must set the operational values for your environment before creating and
deploying the monitor configurations. Doing so ensures that the monitor
collects performance data and generates events. The following are the
operation preferences:
– Database purge preferences
The Database Purge Preferences task is used to define the number of
days to retain data in the database, the time of day the daily purge occurs,
and whether the purge is dependent upon completion of the ETL process.
– SNMP preferences
The SNMP preferences task must be defined in order to collect
performance data from SNMP resources in your enterprise. The SNMP
agent must be running on each IP resource that you want to monitor.


– Define event receivers.
An event is generated when specific thresholds are crossed. Events can
be viewed using IBM Tivoli Enterprise Console or any applications that is
capable of receiving and displaying events. The event receiver defines the
fully qualified host name or IP address and port for the IBM Tivoli
Enterprise Console Server or the IBM Tivoli NetView for z/OS.
Data view in graphics and table format
The IBM Tivoli Monitoring for Network Performance Web application shows
performance data in table and graphical format view of the performance data
collected in the DB2 database. Figure 2-5 shows the table view of the
performance data. This is the default view mode.

Figure 2-5 Table view of performance data

Figure 2-6 on page 17 shows the graphic view of the performance data. For
more information on getting the graph, refer to the IBM Tivoli Monitoring for
Network Performance Operator Guide, SC31-6365.


Figure 2-6 Graphical view

Note: The graphic engine for a z/OS Web application server uses a
shareware program called pja toolkit, while for an AIX based Web application
server it uses X-Windows graphic classes; therefore, the DISPLAY
environment variable must be set to refer to a server with an active X-server.

2.2.3 Role-based security
The user interface is secured with a set of roles. The Web application roles are
configured using the WebSphere Application Server Web-based administration.


An authenticated user ID and password are required to sign in to the Web
application. Depending on the platform and authentication mechanism, the
creation of the user IDs are the responsibility of the security administrator. The
user IDs are then associated with a role in the Web application.

The IBM Tivoli Monitoring for Network Performance Web application uses three
roles for user assignment:
ITMNP Operators can view collected performance metrics for various
configured monitors through the Web application.
ITMNP Admin can configure and manage monitors to collect performance
data, and set run-time preferences and global defaults for the product.
ItscAllAuthority is used for connecting to the itmnpItsc module; this is for the
monitor or NetView ITSC component when it connects to the Web
application. The default is the ItscAllAuthority is assigned to everyone. Do not
change this, as the monitors may fail.

User authentication is handled by WebSphere Application Server. This can be a
local operating system user ID or a remote LDAP directory server user ID. Most
installations may want to use a z/OS based user ID to be consistent. The user ID
needs to be assigned to a role in WebSphere Application Server. Role
assignment is performed using WebSphere Application Server’s administrative
console. Figure 2-7 on page 19 shows the role assignment dialog for IBM Tivoli
Monitoring for Network Performance.


Figure 2-7 Role assignment for the Web application

2.2.4 Problem determination for Web application
All components of the Web application run on a single Java Virtual Machine
(JVM) started by the WebSphere Application Server. This JVM has the standard
output and standard error redirected to files called SystemOut.log and
SystemErr.log respectively. Those files reside under the path:

<WebSphere directory>/AppServer/logs/<server name>

where:
WebSphere directory
The path where WebSphere is installed; on AIX, it is
typically /usr/WebSphere.
server name The WebSphere server name; on AIX, it is typically called
server1. Our z/OS server is called ws611sc61.


You can activate tracing for a WebSphere component to get more detail on the
processing of the component from the WebSphere Application Server
administrative console. From the administrative console, select
Troubleshooting → Logs and Trace, as shown in Figure 2-8.

Figure 2-8 Trace menu

Select the server name that you want to modify and select the Diagnostic Trace
property. The diagnostic trace setting dialog is shown in Figure 2-9 on page 21.


Figure 2-9 WebSphere trace setting

In Figure 2-9, the trace is enabled for Java Messaging Services and it is writing to
a file with a size of 20 MB. You may need to modify this size, as it may not be
enough for a busy system. If you want to modify the components to be traced,
click on the Modify button and you get the setting page, similar to Figure 2-10 on
page 22.


Figure 2-10 Setting component trace

Click on the Apply, Close, OK, Save, and then Save again to save the setting.

For more information, refer to IBM Tivoli Monitoring for Network Performance:
Messages and Troubleshooting, SC31-6366.

2.3 Monitor functions
The IBM Tivoli Monitoring for Network Performance monitor component runs on
z/OS systems to collect TCP/IP network performance data and send the
collected data to a DB2 database. The monitor performs the following functions:
Collects performance data from the z/OS system where the monitor resides.
The z/OS performance data is stored in a central DB2 database and can be
displayed using the IBM Tivoli Monitoring for Network Performance Web
application.


Collects SNMP performance data from IP-addressable resources in the
network that are running the Simple Network Management Protocol (SNMP)
agent. The SNMP data cannot be shown using the Tivoli Monitoring for
Network Performance Web application, but it is stored in the DB2 database.
Collects availability and response time data from IP-addressable resources in
the network. It uses the ping command or ICMP protocol to collect this
information. Availability and response time data is stored in the central
database and can be displayed using the IBM Tivoli Monitoring for Network
Performance Web application.
Sends events when performance metrics indicate a possible problem in the
network. The events are sent in Event Integration Facility (EIF) format.

The monitor configuration defines which resources to monitor, which types of
data to collect, when to start and stop collecting data, and how often to collect
data. A monitor configuration can consist of one or more monitor definition. The
monitor configuration is defined using the Web application.

2.3.1 Process structure of the monitor
The monitor process structure is shown in Figure 2-11.

itm np M o n ito r.sh L a un che r

M o n ito r_ cs3 9 0 Java V irtu al M ach in e

IT M N P M o nitor (U S S )

z/O S
C o m m un ica tion S N M P d ae m on
S e rve r

z/O S

W e b A p plicatio n D B2

Figure 2-11 Monitor startup process


As shown in Figure 2-11 on page 23, the processes for the monitor are:
A shell script, itmnpMonitor.sh, initializes environment variables before
starting the launcher.
The launcher starts the two main processes running in z/OS Unix System
Services (USS), and a C-language program monitor_cs390 collects
performance data from z/OS Communication Server and a Java Virtual
Machine (JVM) that communicates with the Web application and DB2.
– The JVM establishes the communication link with the Web application
through the itmnpItsc servlets and with DB2 through Java Database
Connectivity (JDBC). The JVM reads the monitor configuration and setup
data collection. The JVM process also collect SNMP and ICMP monitors.
– The monitor_cs390 collects data for the z/OS Communication server API.
It retrieves data for TCP/IP stack, FTP, TN3270, TCP applications, TCP
connections, TCP storages, UDP endpoints, Enterprise Extender (EE) and
High Performance Routing (HPR), Common Storage Manager (CSM)
storage, and so on.

2.3.2 Files used by the monitor
The files used by the IBM Tivoli Monitoring for Network Performance monitor
process is shown in Figure 2-12.

$tivoli_common_dir/FNP/
logs/fnp_config.xml $DBCacheDirectory/dbcache

ITMNP Monitor
$CONFIG_DIR/Itmnp.properties $tivoli_common_dir/FNP/logs/msg_fnp_monitor*.log

$FNPlogPropertiesLocation $tivoli_common_dir/FNP/logs/trace_fnp_monitor*.log
/etc/ibm/tivoli/common/cfg/log.properties

Figure 2-12 The monitor file usage


From Figure 2-12 on page 24, the monitor uses the following configuration
information:
itmnp.properties This is the main configuration file. The location of this file
is under the $CONFIG_DIR path, as specified in the
startup script for the monitor.
log.properties This configuration file contains the path to the Tivoli
common directory. It typically resides in the
/etc/ibm/tivoli/common/cfg; however, if you set the
environment variable $FNPlogPropertiesLocation in the
startup script, you can specify the location of the file.
fnp_config.xml This is the configuration of the monitoring process. This
file is retrieved from the Web application when the monitor
is started. This configuration is used to build the objects
for metric collection. It resides in the common log
directory.

The monitor uses the following files for output:
dbcache This is the location of information caching in a
Cloudscape™ database before being written to DB2. The
location of this directory is specified in the variable
$DBCacheDirectory from the itmnp.properties
msg_fnp_monitor*.log and trace_fnp_monitor*.log
These are the messages and traces log files, which reside
under the tivoli common directory, as specified in the
log.properties file.

The configuration XML file, fnp_config.xml, is the latest configuration XML file
that the monitor has received from the Web application. It is stored in the same
directory as the log files. The structure of the XML file is shown in Figure 2-13 on
page 26.


Poller Configuration Document
Poller Configuration

Collection Collection

CS390 Collection SNMP Collection
SNMP Expression
CS390 Target
MIBData
CS390 Data

UDPTable FTP TN3270 TCPDetail
TCPStor TCPListen SNMP Expression
MIBData
Threshold Value CS390Attributes

CS390 System Data
CSMStor EEHPT Interval
CS390 System Target
Event Forwarding

Interval

Event Forwarding

Figure 2-13 Structure of fnp_config.xml

As shown in Figure 2-13, the configuration of the monitor is split into multiple
collection instructions. Each collection represents the requirement for data and
the target table monitor to collect. There are three types of collection:
OS390 collection, which collects data from the z/OS communication server
SNMP collection, which acquires MIB data from SNMP
ICMP collection, which records availability and response time data

Each collection is further qualified with the interval definition and event
forwarding destination information.

2.3.3 Performance data sources
The monitor uses a set of network management interfaces provided by the z/OS
Communications Server to collect most of the z/OS performance data. The
remaining performance data is collected using SNMP queries for performance
data that is stored in MIBs.

SNMP data can be collected from any IP-addressable resource in the enterprise
that is running the SNMP agent. Tivoli Monitoring for Network Performance has
provided a specific set of performance metrics that you can choose from when
creating an SNMP monitor definition. For a complete list of the SNMP
performance metrics supported by IBM Tivoli Monitoring for Network
Performance, refer to Appendix B, “SNMP Performance Data”, in the IBM Tivoli
Monitoring for Network Performance Version 2 Release 1 Administrator Guide,
SC31-6364.


Note: Some of the z/OS performance data is collected using SNMP queries.
To ensure that you collect the necessary performance data, you must have
the OSNMPD agent running on each of the z/OS TCP/IP stacks that you want
to monitor.

Availability and response time data can be collected from any IP-addressable
resource in the enterprise that the monitor is able to ping. The monitor uses the
ping command to determine the availability of the resource. It uses the ping
response times to calculate an average response time for each resource being
monitored.

The data collection schedule is determined by the start and end times and the
intervals specified in the monitor definitions. The interval determines how often
the monitor will collect data. For example, if the interval is set to 30 minutes, the
monitor will collect data every 30 minutes. This is true for all types of data except
for FTP data and data that is displayed on the TN3270 Server Sessions screen.
FTP and TN3270 Server Session data is provided by the z/OS Communications
Server as events occur. As a result, the data on these screens will not change
according to the specified interval. Table 2-1 shows where the performance data
is collected from.

Table 2-1 Performance data sources
Performance data category Data source

TCP stack SNMP V2 Management Information Base
for Transmission Control Protocol using
SMIv2 and z/OS Communications Server
management interfaces.

UDP stack SNMPv2 Management Information Base for
the User Datagram Protocol using SMIv2.

IP stack SNMPv2 Management Information Base for
the Internet Protocol using SMIv2.

TN3270 and FTP sessions z/OS Communication Servers management
interfaces.

HPR and EE information z/OS Communication Servers management
interfaces.

Interface Interface group MIB.

Adapter interface IBM OSA-Express Direct SNMP
Enterprise-Specific MIB.


Performance data category Data source

Memory data z/OS Communications Server management
interfaces.

Response time Result of ping command.

SNMP performance data Use SNMP queries to collect performance
data that is stored in MIBs.

More discussion on monitors and the data related to them can be found in 6.5.1,
“Monitored metrics” on page 138.

2.3.4 Setting options
The itmnp.properties file contains configuration parameters for the monitor. This
file is typically copied to /etc/itmnp/ directory. This directory is specified in the
variable $CONFIG_DIR within itmnpMonitor.sh shell script. The itmnp.properties
file consists of the configuration parameters for the monitor. The detailed
information for each parameters are provided as comments in the member; see
our examples in “AIX itmnp.properties” on page 218 and “z/OS itmnp.properties”
on page 218.

The parameters can be grouped into:
Monitor configuration
monitor_hostname The fully qualified domain name of the system where
the monitor is located. This name is used to retrieve
the monitor configuration from the Web application
and must match the monitor name provided when
defining the monitor configuration.
bind_interface The interface or stack which the monitor binds on this
host.
CSAPIport The first of the two ports used by the monitor for
internal communication. The monitor uses the port and
the next numbered port (such as 1670 and 1671). This
is the port monitor_cs390 process is listening on.
Communication between the monitor and Web application; see also 2.4,
“Communication and security” on page 34
local_httpport The port number that the monitor listens on, and the
Web application used to communicate with the
monitor. This port is used by the Web application to
transmit the monitor configuration.


WAS_hostname The host name of the WebSphere Application Server
where the Web application runs.
WAS_httpport The port number that the monitor uses to
communicate with the Web application.
socksServer, socksPort
The fully qualified URL and port for the Socks server
the monitor will use to communicate with the
WebSphere Application Server. (Optional)
Database properties
DBName The name of the DB2 database where the
performance data will be stored.
DBUserName The database user who has the authority to store data
in the DB2 database.
DBPassword The password of the DB2 database user.
DBHostName The fully qualified host name of the system where DB2
is located. This is the same system as the WebSphere
Application Server host name.
DBPort The port number that DB2 database server is listening
on. Typical value for AIX is 50000, while in z/OS you
can see it from the DSNL004I message in the DB2
startup.
DBDriverType The type of driver used to establish connections with
the database. Use the value of UNIVERSAL.

Tip: Although this parameter defaults to DBDriverType=UNIVERSAL, we
found that we need to comment it out for a DB2 for z/OS database. Explicitly
specifying DBDriverType=UNIVERSAL make the connection to a distributed
DB2 database.

DBCacheDirectory The directory to be used by the monitor to store the
collected data in a local cache. This cache stores the
collected data before it is sent to the DB2 database.
This directory is only used when the DBCachRowLimit
and DBCacheTimeout are > 1.
DBCacheTimeout The maximum number of seconds that the monitor will
store data in a local cache before sending the data to
the DB2 database. Data will be transferred to the DB2
database when either the maximum number of
seconds is reached or the maximum number of rows is
reached.


DBCacheRowLimit The maximum number of rows of data that the monitor
stores in a local disk cache before attempting to store
the data in the DB2 database.
enableCloudscape Use Cloudscape as a cache. This may improve the
performance for high volumes systems.
db2Security This is the setting for the security level between the
monitor and DB2 database. See 2.4.4, “Transport
between DB2 and monitor” on page 39.
SSL properties; all the keyStore and trustStore settings are for HTTPS
protocol with the Web application resides on AIX.
WebSphereServletProtocol
The protocol that the monitor uses to communicate
with the Web application. For non-secure, it is HTTP,
and for secure, it is HTTPS.
trustStoreName The name of the file where the WebSphere Application
Server and monitor certificates are stored.
trustStorePassword The password used to access the trust store file.
keyStoreName The name of the file where the WebSphere Application
Server and monitor keys are stored.
keyStorePassword The password to access the key store file.
keyManagerPassword
The password to access the key manager interface.
This should be the same as keyStorePassword.
Message and trace log properties; see 2.3.5, “Problem determination for the
monitor” on page 31 for more details
trace.maxFiles The maximum number of trace files that may exist at
one time. When the monitor closes a full trace file, it
will ensure that no more than the maximum number
exists by deleting the oldest trace file before creating a
new trace file. When the number is 1, the file size limit
is ignored. You can specify individual type (Java, CLI,
or C) separately.
trace.maxFileSize The maximum size (in kilobytes) each trace file may
contain before the monitor closes the old trace log and
creates a new trace log. You can specify individual
type (Java, CLI, or C) separately.
message.maxFiles The maximum number of message files that may exist
at one time. When the monitor closes a full message
file, it will ensure that no more than the maximum


number exists by deleting the oldest message file
before creating a new message file. You can specify
individual type (Java, CLI, or C) separately.
message.maxFileSize
The maximum size (in kilobytes) each message file
may contain before the monitor closes the old trace log
and creates a new message log. You can specify
individual type (Java, CLI, or C) separately.
monitor.trace.level The logging level for the trace logs. This controls how
much trace data is collected. The possible values are
DEBUG_MIN, DEBUG_MID, and DEBUG_MAX.

2.3.5 Problem determination for the monitor
For more information on problem determination, refer to IBM Tivoli Monitoring for
Network Performance: Messages and Troubleshooting, SC31-6366. This section
contains our experience on performing the troubleshooting.

In debugging the monitors, the main information sources are the XML trace and
log files. These files are located under the Tivoli common directory, typically
/var/ibm/tivoli/common/FNP/logs. This directory contains the following files:
fnp_config.xml: The current configuration file; if this file does not exist, the
monitor initialization may fail or the monitor cannot communicate with the
Web application.
msg_fnp_monitor*.log: The message file for the JVM process shown in
Figure 2-11 on page 23. The database connection and configuration file
processing messages are here. The number of files and their size are
governed by the parameters message.Java.maxFiles and
message.Java.maxFileSize.
trace_fnp_monitor*.log: Trace file for detailed information on the JVM
process; the number of these files and their size are governed by the
parameters trace.Java.maxFiles and trace.Java.maxFileSize.
msg_fnp_monitorc*.log: The message file for the monitor_cs390 and the
launcher process, as shown in Figure 2-11 on page 23. The calls to
Communication Server API messages are shown here. The number of files
and their size are governed by the parameters message.C.maxFiles and
message.C.maxFileSize.
trace_fnp_monitorc*.log: Trace file for detailed information on the
monitor_cs390 process; the number of this files and their size are governed
by the parameters trace.C.maxFiles and trace.C.maxFileSize.


Note: The parameters trace.maxFiles, trace.maxFileSize, message.maxFiles,
and message.maxFileSize contain the default value for the derivative
trace.*.maxFiles, trace.*.maxFileSize, message.*.maxFiles, and
message.*.maxFileSize parameters.

The tracing levels provided are DEBUG_MIN, DEBUG _MID, and DEBUG_MAX.
We recommend running the processes with the DEBUG_MIN level, as these files
have an XML format and are huge. In our environment, a two minute interval
produces more than 50 MB of trace files with a DEBUG_MAX level. The
serviceability consideration must be take into account when allocating the HFS
dataset.

The trace level can also be modified using a Command Line Interface. You start
the CLI using the command itmnpMonitor.sh cli. This will give the menu shown
in Figure 2-14.

VBUDI @ SC66:/itmnp/V2R1M0/bin>./itmnpMonitor.sh cli
Launching ITMNP Monitor CLI

Main Menu
Current state: Running
Configuration last loaded: Tue Jun 15 12:59:00 EDT 2004
Build level: Thu Apr 29 09:00:00 2004
1) Change trace logging levels
2) Suspend collection of all measurements
3) Resume collection of all measurements
4) Exit
Type your selection number:

Figure 2-14 Monitor CLI menu

The trace level is changed by selecting 1 from the menu in Figure 2-14. This
gives the screen in Figure 2-15 on page 33.


Change Trace Logger Levels Menu
1) All loggers
2) CS390 Data Layer DEBUG_MIN
3) CS390 Layer DEBUG_MIN
4) CS390 Socket Data Layer DEBUG_MIN
5) Command Line Interface DEBUG_MIN
6) Database Layer DEBUG_MIN
7) ICMP Layer DEBUG_MIN
8) JMX Layer DEBUG_MIN
9) Monitor Base Code DEBUG_MIN
10) Monitor CS390 - Base DEBUG_MIN
11) Monitor CS390 - CSM Storage DEBUG_MIN
12) Monitor CS390 - EE and HPR DEBUG_MIN
13) Monitor CS390 - FTP and TN3270 DEBUG_MIN
14) Monitor CS390 - Hash table DEBUG_MIN
15) Monitor CS390 - SNA Management DEBUG_MIN
16) Monitor CS390 - TCP Applications DEBUG_MIN
17) Monitor CS390 - TCP Connections DEBUG_MIN
18) Monitor CS390 - TCP Storage DEBUG_MIN
19) Monitor CS390 - UDP Endpoints DEBUG_MIN
20) Monitor Services Code DEBUG_MIN
21) Monitor utilities DEBUG_MIN
22) Monitor utilities - Socket DEBUG_MIN
23) SNMP Layer DEBUG_MIN
24) Return to previous menu.


Figure 2-15 Trace setting

As an example, if you want to change the CS390 Data Layer setting, select 2 and
then specify the trace level, as shown in Figure 2-16.

Type your selection number: 2

Select New Logging Level For: CS390 Data Layer
1) DEBUG_MIN
2) DEBUG_MID
3) DEBUG_MAX
4) Return to previous menu.

Figure 2-16 Trace level


Ibm tivoli monitoring for network performance v2.1 the mainframe network management solution sg246360

Ibm tivoli monitoring for network performance v2.1 the mainframe network management solution sg246360

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Viewers also liked

Viewers also liked (20)

Similar to Ibm tivoli monitoring for network performance v2.1 the mainframe network management solution sg246360

Similar to Ibm tivoli monitoring for network performance v2.1 the mainframe network management solution sg246360 (20)

More from Banking at Ho Chi Minh city

More from Banking at Ho Chi Minh city (20)

Recently uploaded

Recently uploaded (20)

Ibm tivoli monitoring for network performance v2.1 the mainframe network management solution sg246360