1. Automation Using Tivoli NetView OS/390 V1R3
and System Automation OS/390 V1R3
Holger Stamme, Ling Xiao Gao, Marcio Guimaraes, Clive Kennedy, Jason Wyer
International Technical Support Organization
www.redbooks.ibm.com
SG24-5515-00

3. SG24-5515-00
International Technical Support Organization
Automation Using Tivoli NetView OS/390 V1R3
and System Automation OS/390 V1R3
March 2000

4. Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix D, “Special notices” on page 245.
First Edition (March 2000)
This edition applies to Tivoli NetView for OS/390 V1R3 and System Automation for OS/390 V1R3 for
use with the OS/390.
This document created or updated on March 14, 2000.
Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. OSJB Building 003 Internal Zip 2834
11400 Burnet Road
Austin, Texas 78758-3493
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 2000. All rights reserved.
Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

5. Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Chapter 1. Introduction to Tivoli NetView for OS/390 V1R3 . . . .. . . . . .1
1.1 At a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .1
1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .1
1.3 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .3
1.3.1 IP management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .3
1.3.2 Graphical console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .5
1.3.3 Automation features . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .6
1.3.4 Other customer satisfaction enhancements . . . . . . . . . . .. . . . . .7
1.3.5 Product positioning in the market . . . . . . . . . . . . . . . . . . .. . . . . .9
Chapter 2. Benefits of using System Automation for OS/390 . . . . . . . 11
2.1 Why automate? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Proactive management of OS/390 subsystem tasks . . . . . . . . . . . . . . 12
2.3 Monitoring and recovery capabilities of OS/390 subsystems . . . . . . . 12
2.4 Automation features of System Automation for OS/390 V1R3 . . . . . . 13
2.4.1 New Interface - Single system image support . . . . . . . . . . . . . . . 13
2.4.2 Better managing your applications . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Simultaneously updating policy databases for applications . . . . . 14
2.4.4 Notifying the Tivoli Enterprise Console . . . . . . . . . . . . . . . . . . . . 14
2.4.5 Other enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Chapter 3. The ITSO automation project environment . .. . . . . .. . . . . 17
3.1 Types of communication. . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . 19
3.1.1 Communication using a LU 6.2 session . . . . . . . .. . . . . .. . . . . 19
3.1.2 Communication using a LUC session . . . . . . . . . .. . . . . .. . . . . 20
3.1.3 Communication using an OST-NNT session . . . . .. . . . . .. . . . . 20
3.2 Resource Object Data Manager (RODM) . . . . . . . . . . .. . . . . .. . . . . 20
3.2.1 RODM object oriented structure . . . . . . . . . . . . . .. . . . . .. . . . . 21
3.3 Graphic Monitor Facility Host Subsystem (GMFHS) . . .. . . . . .. . . . . 21
3.4 Status Display Facility (SDF) . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . 22
Chapter 4. Customization of Tivoli NetView OS/390. . ........... . . 25
4.1 Planning the Tivoli NetView for OS/390 environment ........... . . 26
4.2 Defining the Tivoli NetView for OS/390 environment ........... . . 27
4.2.1 Recommended library structure in multi-system environment . . . 27
4.2.2 OS/390 subsystem extensions . . . . . . . . . . . . . ........... . . 31
4.2.3 Usage of OS/390 system symbolics . . . . . . . . . ........... . . 32
© Copyright IBM Corp. 2000 iii

6. 4.3 Network management environment . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.1 Creation of common networking NetView libraries . . . . . . . . . . . 34
4.3.2 Setting up the base components NetView for OS/390. . . . . . . . . 36
4.3.3 Setting up the Resource Object Data Manager . . . . . . . . . . . . . . 36
4.3.4 Setting up the Graphic Monitor Facility Host Subsystem . . . . . . . 37
4.3.5 Setting up the Automated Operation Network feature . . . . . . . . . 37
4.3.6 Creation of local (domain specific) NetView libraries . . . . . . . . . 37
4.4 Automation environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4.1 Creation of common automation NetView libraries . . . . . . . . . . . 40
4.4.2 Setting up the base NetView for OS/390. . . . . . . . . . . . . . . . . . . 47
4.4.3 Setting up the Resource Object Data Manager . . . . . . . . . . . . . . 47
4.4.4 Customizing RODM load jobs in the automation environment . . . 49
4.4.5 Setting up the Graphic Monitor Facility Host Subsystem . . . . . . . 49
4.4.6 Creation of local (domain specific) NetView libraries . . . . . . . . . 50
Chapter 5. Customization of System Automation for OS/390 . . . . . . . 53
5.1 Base System Automation customization . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.1 Preparation and set up jobs for System Automation . . . . . . . . . . 53
5.1.2 Preparing the OS/390 system environment and library . . . . . . . . 55
5.1.3 Creating System Automation policy database dialog panels . . . . 56
5.2 Usage of system symbolics and System Automation synonyms . . . . . 59
5.3 Defining all systems and objects to System Automation . . . . . . . . . . . 60
5.3.1 Starting the System Automation policy database dialog . . . . . . . 61
5.3.2 Creating a new System Automation policy database. . . . . . . . . . 62
5.3.3 Entering all systems and objects . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3.4 Building SA Automation Control File (ACF) . . . . . . . . . . . . . . . . . . . . 98
5.3.5 Build RODM loader input file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.4 Defining dependencies and start-up behavior . . . . . . . . . . . . . . . . . . 103
5.4.1 Define dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.4.2 Define start-up behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.5 Customizing the Status Display Facility (SDF) . . . . . . . . . . . . . . . . . 108
5.5.1 Customizing the panel member AOFPNLS . . . . . . . . . . . . . . . . 108
5.5.2 Customizing the status member AOFTREE . . . . . . . . . . . . . . . 110
5.5.3 Defining SDF gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.5.4 Starting the SDF monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Chapter 6. Installation of the NetView Management Console . . . . . . 115
6.1 Prerequisites for NetView Management Console Version 1.3 . . . . . . 117
6.2 Setting up the NMC Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.2.1 Installing NMC Server to run as a Windows NT service . . . . . . 117
6.2.2 Setting up NMC Topology Server for Systems Automation . . . . 123
6.2.3 Starting the NMC Topology Server using TCP/IP . . . . . . . . . . . 127
6.2.4 Uninstalling the NMC Topology Server . . . . . . . . . . . . . . . . . . . 128
iv Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

7. 6.2.5 Hints and tips for the NMC Topology Server . . . . . . . . . . . . . . . 129
6.3 Setting up the NMC client workstation . . . . . . . . . . . . . . . . . . . . . . . 131
6.3.1 Installing the NMC Topology Console . . . . . . . . . . . . . . . . . . . . 131
6.3.2 Starting the NMC Console using a TCP/IP connection . . . . . . . 133
6.3.3 Uninstalling the Tivoli NMC Topology Console . . . . . . . . . . . . . 134
6.3.4 Hints and tips for the NMC Topology Console . . . . . . . . . . . . . 135
6.3.5 Issuing SA OS/390 commands using the NMC . . . . . . . . . . . . . 135
6.4 Setting up the Web interface to Tivoli NetView OS/390 . . . . . . . . . . 140
6.5 Setting up the NetView 3270 Management Console . . . . . . . . . . . . . 142
6.5.1 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.5.2 Selecting the correct files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.5.3 Available documentation and technical information. . . . . . . . . . 144
6.5.4 Setting up the host (mainframe) environment . . . . . . . . . . . . . . 144
6.5.5 Installing NetView 3270 Console on Windows 95, 98, and NT . 146
6.5.6 Uninstalling the NetView 3270 Console . . . . . . . . . . . . . . . . . . 150
6.5.7 Replicating the NetView 3270 Console . . . . . . . . . . . . . . . . . . . 151
6.5.8 Operating notes, hints, and tips . . . . . . . . . . . . . . . . . . . . . . . . 152
Chapter 7. Maintenance of Tivoli NetView and System Automation . 155
7.1 Automation table maintenance using AUTOMAN . . . . . . . . . . . . . . . 155
7.1.1 Enabling the AUTOMAN function for the Automation NetView . 155
7.1.2 Using AUTOMAN command . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
7.2 Netview and automation table optimization for performance . . . . . . . 166
7.2.1 NetView automation table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.2.2 Additional hints and tuning considerations . . . . . . . . . . . . . . . . 168
7.3 Maintenance of the System Automation policy data base . . . . . . . . . 170
7.3.1 Design a hierarchical structure . . . . . . . . . . . . . . . . . . . . . . . . . 170
7.3.2 Using ADD/REMOVE commands . . . . . . . . . . . . . . . . . . . . . . . 171
7.3.3 RACF considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
7.3.4 System Automation migration . . . . . . . . . . . . . . . . . . . . . . . . . . 172
7.3.5 Building for ACF and RODM . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
7.3.6 Policy report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
7.3.7 ACFPLOAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Chapter 8. Base automation features . . . . . . . . . . . . . . . . . . . . .. . . . 175
8.1 New automation table features of NetView for OS/390 V1R3 . .. . . . 175
8.1.1 Multi-line message support . . . . . . . . . . . . . . . . . . . . . . . .. . . . 175
8.1.2 IF-THEN condition item substrings . . . . . . . . . . . . . . . . . .. . . . 176
8.1.3 Greater-than and less-than operator support . . . . . . . . . .. . . . 177
8.1.4 Numeric comparison and current time support . . . . . . . . .. . . . 177
8.1.5 Variable value function support. . . . . . . . . . . . . . . . . . . . .. . . . 177
8.1.6 Message reformatting . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 178
8.1.7 Automation table tracing . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 179
v

8. 8.1.8 The AUTOMATED function . .................. . . . . . . . . . 180
8.2 System Automation framework . . .................. . . . . . . . . . 180
8.2.1 Automating subsystems . . . .................. . . . . . . . . . 181
8.2.2 Automating messages . . . . .................. . . . . . . . . . 193
8.3 System Automation and NetView base automation rules . . . . . . . . . 197
Chapter 9. Automation example scenarios . . . . . . . . . . . . . . . . . . . . . 199
9.1 NetView SMTP mail gateway support . . . . . . . . . . . . . . . . . . . . . . . . 199
9.1.1 NetView provided samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
9.1.2 Required customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
9.1.3 Sending SMTP e-mail with EZLEMAIL . . . . . . . . . . . . . . . . . . . 201
9.1.4 Sending SMTP e-mail from AON Inform policies. . . . . . . . . . . . 202
9.1.5 Sending SMTP e-mail from user-written clists. . . . . . . . . . . . . . 203
9.2 System Automation in a multi-system focal point environment . . . . . 204
9.2.1 Defining Automation Network process . . . . . . . . . . . . . . . . . . . 205
9.3 Using NetView AON inform policies by System Automation . . . . . . . 214
9.3.1 Installation of AON inform policy in the Automation NetView. . . 214
9.3.2 Inform policy customizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
9.3.3 Calling the Inform policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
9.3.4 Calling AON Inform policy from System Automation . . . . . . . . . 218
9.4 Brief comparison of NMC and SDF Consoles . . . . . . . . . . . . . . . . . . 224
9.5 Example NMC screens of the ITSO project scenario . . . . . . . . . . . . 225
Appendix A. NetView 1.3 toleration for System Automation 1.3 . . . . 231
Appendix B. System Automation V1R3 members and jobs . . . . . . . . 233
B.1 Other System Automation jobs and definitions . . . . . . . . . . . . . . . . . . . . 234
B.1.1 Automation NetView start-up procedure . . . . . . . . . . . . . . . . . . . . . 235
B.1.2 System Automation RODM procedure . . . . . . . . . . . . . . . . . . . . . . 237
B.1.3 Automation GMFHS start-up procedure . . . . . . . . . . . . . . . . . . . . . 238
B.1.4 SA RODM data model load job. . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Appendix C. One RODM/GMFHS focal point configuration. . . . . . . . . 241
Appendix D. Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Appendix E. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
E.1 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
E.2 IBM Redbooks collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
E.3 Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
E.4 Referenced Web sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
How to get ITSO redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
IBM Redbook fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
vi Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

9. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
vii

10. viii Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

11. Preface
The objective of this redbook is to provide an easy to use and understand
automation guide for large organizations. The major focus of this redbook is
on how to efficiently set up and customize Tivoli NetView for OS/390 and
Systems Automation for OS/390 in a multi-systems enterprise environment.
In addition to this, this redbook provides best practices and tips for
maintenance issues of the Tivoli NetView and System Automation
environment. This will include the AUTOMAN feature for maintenance of
multiple automation tables, basic tuning considerations to improve general
NetView and automation table performance, as well as an optimized structure
of the System Automation policy database.
To help system administrators and operators establish and leverage their
automation environment, this redbook provides further information on basic
automation features, such as the System Automation framework, and some
automation scenarios using the new NetView AON inform policy feature.
Examples include an automation scenario of the ITSO project environment,
as well as integration aspects of System Automation using the new NetView
AON inform policy features, such as notifications via pager support or
escalations by sending e-mails using the SMTP gateway support.
The steps outlined in this redbook are based on, and supported by, examples
derived from the actual installation, set up, and customization of Tivoli
NetView for OS/390 and System Automation for OS/390 at the ITSO.
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.
Holger Stamme is a Certified IT Architect at the ITSO, Austin Center, who
has more than 10 years of working experience in consulting, designing, and
implementing Systems Management solutions within IBM. Before joining the
ITSO in 1999, he was leading the architectural and design phases of large
customer projects in the finance and insurance industry in Germany.
Ling Xiao Gao is a Advisory IT Specialist in China. He has seven years of
experience in MVS and OS/390 fields. His areas of expertise include NetView
for OS/390 and System Automation.
© Copyright IBM Corp. 2000 ix

12. Marcio Guimaraes is an Advisory IT Specialist in Brazil. He has eight years
of experience in the IT field, of which the last five years have been in
developing, designing, and supporting the System Management area. His
areas of expertise include Tivoli NetView for OS/390 and System Automation
for OS/390.
Clive Kennedy is a Network Automation Specialist with AT&T Global
Networks in the UK. He has over 20 years experience in Systems and
Network Management in large MVS installations and over 12 years
experience using NetView OS/390 for Systems and Network Automation.
Jason Wyer is an IT Consultant working for PricewaterhouseCoopers in the
USA. He has three years of experience in the Systems Administration field.
He holds a BS from the University of Connecticut along with being an A+
Certified Technician and Microsoft Certified Professional. His areas of
expertise include Microsoft Windows environments.
Thanks to the following people for their invaluable contributions to this project:
Adam Barry
Tivoli Systems Raleigh, Network Management Applications Development
Denny Beary
IBM Gaithersburg, S/390 Systems Management Technology Support
Budi Darmawan
International Technical Support Organization, Austin Center
Gary Forghetti
Tivoli Systems Raleigh, Tivoli Product Introduction
Roland Haibl
IBM Boeblingen, System Automation for OS/390 Information Development
Robert Haimowitz
International Technical Support Organization, Raleigh Center
Stephan Hartig
IBM Boeblingen, System Automation for OS/390 Information Development
Joseph Macera
IBM Los Angeles, Tivoli Migration Team
Wade Miller
Tivoli Systems Raleigh, NetView Performance Group
x Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

13. Paul Quigley
Tivoli Systems Raleigh, Network Management Applications Development
Phil Riedel
Tivoli Systems Raleigh, Network Management Applications Development
Joachim Schmalzried
IBM Boeblingen, System Automation for OS/390 Information Development
Aimee Tattersall
Tivoli Systems Raleigh, NetView for OS/390 Technical Evangelist
Comments welcome
Your comments are important to us!
We want our redbooks to be as helpful as possible. Please send us your
comments about this or other redbooks in one of the following ways:
• Fax the evaluation form found in “IBM Redbooks review” on page 265 to
the fax number shown on the form.
• Use the online evaluation form found at http://www.redbooks.ibm.com/
• Send your comments in an Internet note to redbook@us.ibm.com
xi

14. xii Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

15. Chapter 1. Introduction to Tivoli NetView for OS/390 V1R3
This chapter provides a brief overview of the functions in Tivoli NetView for
OS/390 V1R3, which is extracted from the Request for Announcement (RFA).
In addition, some information about the configuration used during the
residency will be provided.
A complete list of all the hardware and software requirements for each Tivoli
NetView for OS/390 V1R3 function is provided in the announcement letter
and also in the Tivoli NetView for OS/390 V1R3 Planning Guide, GC31-8226.
1.1 At a glance
Tivoli NetView for OS/390 V1R3 targets enterprise control of the e-business
complexity. Building on the already rich functionality of Tivoli NetView for
OS/390, V1R3 provides enhancements in the following areas:
• It is possible to issue any TCP/IP, SNMP, or UNIX command from Tivoli
NetView for OS/390 either through a user-friendly panel interface or in
Clists that are written to extend the functions NetView provides.
• SNMP services include a MIB compiler/loader and a MIB browser
launched from the NMC. There is also a robust 3270 interface for issuing
SNMP requests, such as GET/SET/etc. MIB polling and thresholds also
aid in monitoring and automation.
• Graphical Network Management now includes IP agents available for:
- Tivoli NetView on Sun Solaris or Windows NT
- HP OpenView on Sun Solaris or HP-UX
- Tivoli NetView on AIX
• Tivoli NetView for OS/390 now provides the ability to convert SNMP traps
to SNA alerts and SNA alerts to SNMP traps.
• Web interfaces for third-party Web applications can be launched.
• The timer and automation capabilities are further enhanced.
1.2 Overview
Tivoli NetView for OS/390 addresses the challenges of network and systems
management by focusing on operator productivity through the use of
graphical displays and embedded automation capability. Tivoli NetView for
© Copyright IBM Corp. 2000 1

16. OS/390 continues its leadership in SNA management and strongly addresses
the management of mixed network architecture environments.
Tivoli NetView for OS/390 V1R3 focuses on management of IP networks and
SNMP-based devices, management of IP clients accessing mainframe
applications, and integration with third-party network and element
management vendors.
TCP/IP management can be accomplished through the use of native OS/390
TCP/IP management or in cooperation with management applications on
distributed platforms. This includes IP agents available for Tivoli NetView on
AIX, Sun Solaris, or Windows NT, and HP OpenView on Sun Solaris or
HP-UX.
An SNMP stack and MIB services (MIB compiler/loader, MIB browser)
improve the management of TCP/IP resources and sessions. In addition,
NetView can receive and process any SNMP V1 trap.
Full function SNMP command support from the NMC, 3270 panels, or
command procedures, support for logical groupings of MIB variables, remote
Ping support, MIB polling, and thresholds aid in resource monitoring and
automation. Not all functions are available from both the NMC and 3270
interfaces.
Any socket can now be monitored for availability. If the socket is down, then
automation can attempt to restart its associated application, job, or task.
TN3270 session management now includes support for the remote TN3270
server feature on both Cisco and IBM routers plus support for connections
with any TCP socket.
Tivoli NetView for OS/390 provides the ability to launch a Web interface for
any vendor application from the NetView Management Console (NMC).
NMC improvements include view cycling, view and resource security, and
other ease-of-use enhancements. In addition, there are enhancements that
integrate the NMC and NetView 3270 Management Console into a single
console.
Tivoli NetView's robust timer and automation table capabilities are expanded
to assist in automation table management, and a new CHRON command with
calendering support.
Tivoli NetView for OS/390 now adapts dynamically to daylight savings time
and other system time changes without requiring a recycle.
2 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

17. 1.3 Description
Building on the already rich functionality of Tivoli NetView for OS/390, the
V1R3 provides the additional enhancements, which are discussed in the
following sections.
1.3.1 IP management
Tivoli NetView for OS/390 V1R3 provides the operator with the ability to
monitor and control the enterprise-wide, multi-protocol network from a single
console. This includes the ability to view and manage the protocol-based
network topologies, network devices, and the interrelationships between
them.
• Graphical Network Management now includes IP agents available on
Tivoli NetView for Sun Solaris, Tivoli NetView for Windows NT, HP
OpenView for Sun Solaris, and HP OpenView for HP-UX. The agents
enable collection of IP topology and status discovered by the distributed
SNMP-based network managers and forwarded to Tivoli NetView for
OS/390 on a TCP/IP session. This enables management of IP networks
from one central location. There is also a TCP/IP connection between the
agent on Tivoli NetView for AIX and Tivoli NetView for OS/390 as well as
an LU6.2 connection.
• For topology updates and status changes, Tivoli NetView for OS/390 now
has the ability to receive SNMP traps about IP resources and convert them
to SNA alerts and status updates.
• Conversion of SNA alerts into SNMP traps allows OS/390 captured alerts
to be forwarded to distributed SNMP management applications.
• A sample IP Layer 3 discovery engine that runs natively on OS/390
minimizes the need to define resources to be managed.
• Topology correlation has been enhanced to generate enterprise specific
views more easily. Critical resources can now be automatically linked to a
hierarchy of topology resources, such as "Room 12, Warehouse 2, Hong
Kong, Manufacturing." If business views are not found, they will be
created. Topology correlation is now easier to invoke through integration
with BuildViews and Visual BuildViews.
• Continuing to build on end-to-end network management, NetView for
OS/390 provides the ability to launch a Web interface for any vendor
application from the NetView Management Console. Use of this function
includes CiscoWorks Blue and IBM Nways Manager Element Manager.
This allows operators to manage the enterprise from one control console
Chapter 1. Introduction to Tivoli NetView for OS/390 V1R3 3

18. and seamlessly work with other management tools without changing
management consoles.
• From the NMC, you can retrieve inventory data for IBM and Cisco network
interconnect devices from the Tivoli Inventory database. The Tivoli
Inventory database is populated by Tivoli Manager for CiscoWorks 2000
and Tivoli Manager for IBM NWAYS.
• An NMC-based MIB Browser functions as a client of MIB services and
SNMP services on OS/390. The MIB services provide a MIB
compiler/loader function, which allows Tivoli NetView for OS/390 to
support any vendor specific MIB described using the standard ASN.1
format. SNMP services provide an SNMP stack facility. Full SNMP command
support is provided from NMC command pull-downs.
• The Tivoli Management Region (TMR) agent is enhanced to collect
topology and monitors for critical Tivoli Management Agents (TMAs).
• The ATM topology agent supports new alerts for status updates.
• Operators can now issue SNMP GET, GETNEXT, SET, and WALK commands from
Tivoli NetView for OS/390 in addition to PING, TRACERTE, IPSTAT, and NETSTAT.
In general, it is possible to issue any IP, SNMP, or UNIX command. These
commands can also be used in REXX clists and other automation
routines.
• It is possible to define which MIB variables to check at specified intervals
and take action if a threshold is exceeded. User exits are available for MIB
polling and MIB thresholding to provide the capability to do more extensive
analysis or automation.
• Extending previous support for managing TN3270 and FTP sessions, any
socket connection can now be monitored for availability. Operators can
display session status for any socket connection, including TN3270
sockets, FTP, SMTP, telnet, and Web browser. If the socket is down,
automation can attempt to restart its associated application, job, or task.
• If you are running OS/390 V2R6, or later, and have it properly configured
to support multiple TN3270 sockets, then Session Management can also
be configured to support multiple sockets for TN3270 connections.
• Sessions being displayed by Session Management can be filtered. For
example, operators can set filters to see only TN3270 sessions from
subnet 146.48.*.* to applications starting with CICS.
• IP session management has been extended to include sessions between
IP clients and SNA mainframe applications connected through TN3270
servers. Servers supported include IBM 2210 and 2216 and Cisco's
Channel Interface Processors (CIP) and Channel Port Adapters (CPAs).
4 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

19. • Tivoli NetView for OS/390 has predefined MIB group definitions to collect
SNMP data that is most meaningful to the operators. Additionally, it is
possible to define your own groups to present MIB data best suited for the
specific SNMP environment.
1.3.2 Graphical console
The NetView Management Console (NMC) now has equivalent functionality
to NGMF plus several additional customer-requested capabilities. In addition,
there are enhancements that integrate the NMC and NetView 3270
Management Console (formerly known as the 3270 Java (TM) Client) into a
single console. These enhancements include:
• View cycling
• Resource session data from session monitor (including configuration data)
• Launching Web interface for vendor applications, such as CiscoWorks
Blue and IBM Nways Manager Element Manager
• Sending messages to a specific console or broadcast to all consoles
• View and resource security
• Non-SNA command line (now called Service Point Command Line)
• Visual NETCONV status (to more clearly see when NETCONV is down)
• Single sign on for NMC and NetView 3270 Management Console
• The ability to create a note associated with a flag (user status)
• Operator ID and timestamp stored whenever a flag is changed
• Console log freeze and thaw to prevent scrolling while you are trying to
read a message
• Additional hot key support, such as ctrl-H for help, ctrl-L for locate
resource, and ctrl-F for find
• New menu item to quickly suspend/unsuspend resources from
aggregation
• Closing a view and/all descendent views
• Selection of multiple resources (including selecting objects in a specified
region of the view)
• Customized dynamic views displayed on a business tree structure
• Finding objects in a view
Chapter 1. Introduction to Tivoli NetView for OS/390 V1R3 5

20. • The ability to write a client application to send a command to Tivoli
NetView for OS/390 and receive a correlated response back for
subsequent processing
• Built-in Java runtime environment eliminating the need for a separate
installation and configuration of the Java Development Kit
• Productivity kit
- The ability to write console-based Java applications
- The ability to extend console operation using plug-ins
- Advanced customization guide
- Self-standing demonstration mode of the NMC (server not required)
1.3.3 Automation features
The automation enhancements include additional functions and usability in
the automation table, timers, and TCP/IP. These enhancements include:
• Support of greater-than and less-than in the automation table
• Triggering of information in multiple lines of MLWTOs in the automation
table
• The ability to use PIPE EDIT functionality in automation table conditions
and actions
• A tool for managing multiple automation tables (AUTOMAN)
• Support allowing operators to send e-mail directly from Tivoli NetView for
OS/390 via a panel interface using SMTP
• Greatly enhanced timer support through a new CHRON command which
provides capabilities such as:
- The ability to define enterprise-unique dates of importance, such as
holidays, vacations, and payroll days, using a customizable calendar
that can be dynamically reloaded.
- Very flexible specification of dates and times for timer execution
including days of the week or days of the month; for example, you can
specify that a certain command is to be executed at 10:00 every
Monday that is not a holiday.
- The ability to specify repeated timers that automatically compensate for
daylight savings time or other system time changes.
• An enhanced panel interface (TIMER) for viewing and creating
timer-driven commands, including support for the CHRON command
6 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

21. 1.3.4 Other customer satisfaction enhancements
Further customer satisfaction enhancements include:
• Dynamic timer adjustment to allow Tivoli NetView for OS/390 to remain up
and running through daylight savings time changes or other system time
changes.
• The ability to dynamically define Tivoli NetView for OS/390 commands,
removing one of the final reasons to recycle Tivoli NetView for OS/390.
This enhancement provides truly 24x7 operation of Tivoli NetView for
OS/390 since planned outages are no longer necessary except for
application of maintenance between releases.
• The use of system symbolics for all components of Tivoli NetView for
OS/390 allows easier configuration of multiple instances of Tivoli NetView
for OS/390 throughout your enterprise and reduces maintenance efforts in
a multi-system OS/390 environment.
• Visual BLDVIEWS support to provide an easy-to-use graphical interface to
create views and modify resource information.
• A new NetView SOCKET command to facilitate communication with other
TCP/IP applications and devices from automation procedures or the
NetView command line.
• The ability for an operator to log on with an active autotask of the same
name or take over a task logged on elsewhere. In addition, the RMTCMD
command can take over tasks already logged on or make use of tasks
being used for other purposes.
• Conversion of initial clist to use REXX and pipes.
• Support for personal operator data sets to allow for operator
customizations, including the ability to save and restore personalized PF
key settings.
• The ability to use up to eight characters for the command prefix used to
issue Tivoli NetView for OS/390 commands from an MVS console.
• Support for Tivoli Software Distribution file packs to distribute and install
workstation components where Tivoli Software Distribution is deployed,
thus, making software install easier on distributed platforms connecting to
Tivoli NetView for OS/390.
• The ability to view session monitor configuration data from the NMC or
from a Web browser.
• Customizable Title Line on the Command Facility screen.
• Many improvements to the NetView Pipe command.
Chapter 1. Introduction to Tivoli NetView for OS/390 V1R3 7

22. • Upgrading of MEMSTORE and IDLEOFF from samples to supported Tivoli
NetView for OS/390 commands.
• BROWSE NETLOG support for the HDRMTYPE field.
• Enhanced ability to locate network node (NN) servers in APPN
environments and run commands remotely at these network nodes.
• Security enhancements include:
- Enhanced security for DB2 access.
- Disk read security for %INCLUDE members.
- Security for VTAM commands prefixed with 'MVS'.
- Checking an operator's READSEC or WRITESEC authorization before
reading from or writing to a data set member when EXECIO is done in
a NetView command list.
- More granularity in submitting jobs via NetView's SUBMIT command.
• Resource monitor enhancements to help determine which task is queuing
too many messages and to provide more flexibility in logging usage
statistics in SMF.
• Several customer requested enhancements to the NetView 3270
Management Console (previously known as the 3270 Java client), such as
remappable colors and keyboard, an editable session list, and an option to
hide the PF keys palette.
• Access to Tivoli NetView for OS/390 using a standard Web browser
includes these enhancements:
- An operator sending a LOGOFF command to NetView from a Web
browser can be prompted for their operator ID and password the next
time they send a command to NetView from the browser. Previously,
the operator had to close the browser.
- Set an idle time limit for Web-connected operator tasks, after which the
operator will be prompted again for an ID and password.
- The ability to specify which operators are authorized to access NetView
from a Web browser.
- The ability to differentiate commands entered through Web access
from commands entered through traditional NetView tasks.
- Support for frames and support for JavaScript (.js) as a valid file type.
8 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

23. 1.3.5 Product positioning in the market
Tivoli NetView for OS/390 Version 1 Release 3 is an integral part of the Tivoli
environment that provides a comprehensive set of tools for maintaining
complex, multi-vendor, multi-platform networks and systems from a single
point of control.
With its open application programming interfaces (APIs), Tivoli NetView for
OS/390 can be an integration point for other S/390 vendors to the Tivoli
distributed environment.
Tivoli NetView for OS/390 is a program for managing networks and systems
through a strong set of automation features and graphical console displays. It
reduces manual resource definition and complex automation set-up through
production-ready automation and extends centralized management into
multiple, non-SNA network environments. Tivoli NetView for OS/390 can be
used in a large enterprise organization as a centralized manager, a mid-level
manager, or just as a S/390 management endpoint.
Note
Tivoli NetView for OS/390 Version 1 Release 3 is the last release that will
support the OS/2-based NetView Graphical Monitor Facility (NGMF).
Subsequent to Release 3, only the NetView Management Console (NMC)
will be supported for graphical topology and status display.
This information is being provided for customer awareness and is based on
IBM best technical judgement at this time. IBM makes no guarantee that
this information will not change based on future business decisions.
Chapter 1. Introduction to Tivoli NetView for OS/390 V1R3 9

24. 10 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

25. Chapter 2. Benefits of using System Automation for OS/390
This chapter describes why it is essential to use System Automation for
OS/390. An effective and proactive management of OS/390 subsystem
components or applications includes functions, such as monitoring, recovery
capabilities, and ease of use.
2.1 Why automate?
The need to simplify operations increases as you add hardware and software
products to your data center, data centers to your network, and personnel to
your data-processing staff. By simplifying your operations, System
Automation can help you meet required service levels, contain costs, make
efficient use of your operation staff, and remove repetitive tasks from being
reliant on human frailties.
System Automation offers system-wide benefits by simplifying your operating
environment. You can reduce the amount of manual intervention required to
manage operating systems, subsystems, application programs, and many
other products.
This is particularly important in a multiple system, especially for a Parallel
Sysplex environment. However, the job of managing these multiple images or
systems is not a simple task.
There are opportunities during the operation in multiple system or Parallel
Sysplex environments where, despite the best efforts of software developers
and testers, human intervention is required. The phrase “to err is human” has
never been more true than in computer operations.
Given that the enterprise wide environment is complex, and that human
errors can occur, the use of an automation tool that responds in a consistent
way to a particular event can help in delivering on the promise of continuous
operations.
One of the questions surrounding automation is: “Just what do I automate?”
In this book, we look at some of the issues surrounding set up, customization,
and automation examples in a multiple system environment.
A similar, but more specific to the Parallel Sysplex environment focusing, is
the ITSO redbook, Parallel Sysplex Automation: Using System Automation for
OS/390, SG24-5442, published in September of 1999.
© Copyright IBM Corp. 2000 11

26. 2.2 Proactive management of OS/390 subsystem tasks
The purpose of the proactive management features of System Automation is
addressing the automation of repetitive tasks that operators currently
perform. Today, the operators usually respond in a particular way to a
message, or perform a task in accordance to the standard operating
procedures. Coding automation routines to replace these tasks is relatively
straight forward since the triggers for the actions, and the actions themselves,
are well known.
Another approach is to collect a number of days of SYSLOG data and to use
a program, such as the MVS SYSLOG Message Analysis Program, which can
be downloaded from URL http://www.s390.ibm.com/sa, to see what
message triggers are being issued and base your automation (and message
suppression) on the output of the tool.
In this book, you will find information, hints, and tips to start up and control a
multiple system OS/390 environment and how to build a hierarchy of your
connected OS/390 systems and subsystem components.
2.3 Monitoring and recovery capabilities of OS/390 subsystems
Next to the proactive management are the monitoring and recovery
capabilities of System Automation for OS/390. It addresses the automation of
events based on what is currently happening in your OS/390 systems.
Typically, automation routines address both of these areas. But of the two, the
monitoring and recovery capabilities of unsolicited events are by far more
complex to resolve. This is due to the fact that it is not precisely known what
to automate without having experienced relevant problems.
When developing automation routines to handle error conditions, the triggers
are not always as obvious. One way around this is to experience the problem
first, then, based on what happened, code routines to automate the handling
of that condition. This works as long as you are happy to experience every
problem or error condition at least once. One other approach is to dive into all
the message manuals and try and look for likely messages to automate.
This book will provide some information, hints, and tips on unsolicited events
in a multiple system OS/390 environment and how to monitor and recover
from these critical situations.
In addition, it will be shown how to notify or escalate in situations where
successful recovery is not possible.
12 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

27. 2.4 Automation features of System Automation for OS/390 V1R3
This section provides a brief overview of the new System Automation V1R3
features.
The following major enhancements are new to SA OS/390 V1R3:
• New interface - Single system image
• Managing your applications with triggers, events, and service periods
• Simultaneously updating policy databases for applications
2.4.1 New Interface - Single system image support
System Automation for OS/390 V1R3 comprises full sysplex and single
system image support. Now, systems in the sysplex need not be automated
separately, but one system in the sysplex acts as a single point of control
where the operator can specify the resources and their automation of the
entire sysplex environment. Using the System Display Feature (SDF) on the
System Automation focal point and System Automation instances on each of
the systems in the sysplex environment, it is possible to display the status
and workloads of resources as well as control and manage them. The support
of single system image helps to optimize operating tasks and improves
productivity.
2.4.2 Better managing your applications
Optimizing the availability of applications when they are needed is an
important issue in data processing. System Automation enables the user to
define the availability of resources to meet a company's specific needs with
the following set of functions:
• Service periods are user specified time intervals, during which an
application should be active.
• Events are part of a trigger condition. If the event of a trigger condition
has occurred, the startup or shutdown of an application is performed. If
there is a service period also connected to the trigger, then it will check
the service window to determine whether a shutdown or start-up should be
performed.
• Triggers, in combination with events, and optionally with service periods,
allows control over the startup and shutdown of resources. For example,
the shutdown of application A automatically triggers the start-up of
application B.
Chapter 2. Benefits of using System Automation for OS/390 13

28. 2.4.3 Simultaneously updating policy databases for applications
The customization dialogs are enhanced to allow for multi-user access to the
policy database for applications. To improve the ease-of-use for updates of
the policy database for applications, changes can now be done in parallel by
various automation administrators.
2.4.4 Notifying the Tivoli Enterprise Console
System Automation for OS/390 V1R3 now includes integration with the Tivoli
Management Environment. Events reported by System Automation, as well
as events reported in a distributed environment, are received at, and handled
from, a single point of control. Therefore, System Automation notifies the
Tivoli Enterprise Console (TEC) in situations when System Automation issues
messages and alerts indicating critical situations. These messages and alerts
are forwarded to the TEC event server by the Event Automation Server
(EAS).
2.4.5 Other enhancements
The following enhancements were further introduced by System Automation
for OS/390 V1R3:
• Workload Manager (WLM) resource name support
By introducing this ability, the interface to the operating system OS/390
has been improved. SA OS/390 now passes status information about the
resources to the operating system's Workload Manager.
• AOCQRES command
With this command you can examine where, in a sysplex environment, a
resource is located and return information about this resource. Optionally,
it also supplies up-to-date status information about resources.
• Partial ACF load
The new ACFPLOAD command allows small changes in the automation
configuration without having to reload the entire ACF file and without
interrupting automation.
• Line mode output
A number of commands have been enhanced with a new parameter
(OUTMODE=LINE) to allow for specifying output mode. All NetView based
commands are now able to be piped for further processing. The operator
dialog NetView panels have been enhanced to support displays of up to
43 lines per panel.
• SHUTSYS command
14 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

29. The default of the SHUTSYS command is now set to VERIFY=NO for
unattended processing.
• Overall performance
The overall performance has been improved by restructuring tasks, which
accelerates the start-up and the shutdown of subsystems.
In the System Automation customization dialog it is now possible to define
a set of auto operators to handle subsystem automation.
Chapter 2. Benefits of using System Automation for OS/390 15

30. 16 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

31. Chapter 3. The ITSO automation project environment
The following sections will provide a brief description of some basic concepts
that are commonly used when working with focal points and graphical
enterprise features. Further detailed information about these topics are
provided within the Tivoli Netview for OS/390 and System Automation for
OS/390 technical documentations.
System Automation for OS/390 allows control of the customization,
monitoring, and management functions of multiple systems or images in the
enterprise (each running System Automation instances), using a single,
centrally located OS/390 system. This controlling OS/390 system is called the
focal point system. The managed systems in the environment are called
target systems. All connected systems communicate between each other
through Tivoli NetView for OS/390 using specific Netview data transport
mechanisms.
Figure 1 on page 18 shows a high-level diagram of the environment used
during the project at the ITSO. The environment consisted of three systems,
each of them running OS/390 V2R7, Tivoli NetView for OS/390 V1R3, and
System Automation for OS/390 V1R3.
The system SC66 is the designated focal point system, while the other two
systems, SC42 and SC69, are target systems.
Note
Within this ITSO project, it was decided to set up the environment
consisting of the three systems, SC66, SC42, and SC69, without any
system resource (storage/workload) limitations. Assuming the networking
and automation objects within the enterprise should be managed by their
own RODM, it was decided to run separate RODM/GMFHS applications for
the networking and the automation environment on the focal point system.
For a limited system resource (storage/workload) approach on the focal
point system, when managing a reasonable number of networking and
System Automation objects, a configuration with only one RODM/GMFHS
on the focal point system for both environments can be chosen. Refer to
Appendix C, “One RODM/GMFHS focal point configuration” on page 241,
for a customization checklist.
© Copyright IBM Corp. 2000 17

32. Figure 1. ITSO project environment
18 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

33. 3.1 Types of communication
Since its earliest releases, Tivoli Netview for OS/390 provides three different
data transport mechanisms that support the centralized operations from a
focal point system. The transport mechanisms are:
• Communication using a LU 6.2 session
• Communication using a LUC session
• Communication using an OST-NNT session
• Communication using TCP/IP
These communications are used to transfer data between Tivoli NetView
programs that reside in different domains or systems. The LU 6.2
communication is also used to transfer data between Tivoli NetView and
non-NetView products, such as the AS/400 and its applications. When
centralizing operations between different Tivoli NetView domains, one or
more of these communication types are used.
In addition, new to Tivoli NetView for OS/390 V1R3 is the support to convert
SNMP traps to SNA NVMT alerts and vice versa, which uses the TCP/IP
communication.
3.1.1 Communication using a LU 6.2 session
Tivoli NetView supports two LU 6.2 session types, which use different
versions of the SNA LU 6.2 protocol:
1. The Management Services (MS) transport is for low-volume transmissions
that require high reliability, such as sending alerts.
2. The high-performance option of the MS transport is for large-volume
transmissions that require optimized network performance.
Tivoli NetView’s LU 6.2 session communications are based on the
MULTIPLE_DOMAIN_SUPPORT function set described in the SNA
Management Services Reference, SC30-3346. This LU 6.2 session
transports are used by Management Services (MS) applications to send and
receive data.
Note
The NetView DSI6DST task must be active to use the LU 6.2 session
transports.
Chapter 3. The ITSO automation project environment 19

34. 3.1.2 Communication using a LUC session
Unlike the communication using a LU 6.2 session, the LUC session transport
supports communication only between NetView programs. The LUC tasks in
the Tivoli NetView domain must be active to use this transport mechanism. In
addition to using the NV-UNIQ/LUC alert forwarding, the DSICRTR task must
be active.
3.1.3 Communication using an OST-NNT session
Like the communication using the LUC session, the OST-NNT session
transport supports communication only between NetView programs. To
establish an OST-NNT session between Tivoli NetView domains, the NetView
command START DOMAIN is used. In this way, a central NetView domain can
communicate with a target NetView domain.
3.2 Resource Object Data Manager (RODM)
The Tivoli NetView for OS/390 uses RODM to store topology and status
information for resources that are to be managed by automation programs
(for example, System Automation for OS/390) or to be displayed by the
NetView Management Console (NMC). The interface between RODM and the
distributed NetView Management Console server component is the NetView
Graphic Monitor Facility Host Subsystem (GMFHS), which is further
explained in the next section.
RODM provides a high-speed data cache, an application program interface
(API), and services that enable the management of system and network
resources. It stores topology data, status information, execution information,
and other details about resources or classes of resources in an object
oriented data structure. Objects in RODM represent resources in the system
or in the network environment. The data cache is located entirely in the
memory of the host processor and is designed for applications that need to
access, interpret, and alter large amounts of rapidly changing data in a short
period of time. RODM provides an open interface to enable management
applications to use the data for automation as well as allow multiple
applications to access the data simultaneously.
It is a single source for all topology and status information that Tivoli
NetView’s automation facilities support. The contained information in RODM
is updated dynamically, which is most important to all automation facilities of
Tivoli NetView for OS/390.
20 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

35. Based on any change in your system or network configuration as reported
through a NetView alert, for example, if a subsystem goes off-line, RODM
dynamically updates the object information and triggers as required
automation procedures.
To ensure fast response time, RODM operates in memory. It supports
sophisticated systems and network process control applications that need to
access, interpret, and respond to rapidly changing configuration and status
data.
3.2.1 RODM object oriented structure
In order to operate RODM, it is necessary to load one or more physical data
model structures of the managed environments into RODMs memory storage.
These data model structures consists of the following elements:
• Object: Any resource or link that is required to be managed would be
represented in the data model as an object. Link objects represent the
connection between two resource objects.
• Class: The class defines the characteristics that are common to all
objects that belong to that class. Its purpose is to define a particular type
of object.
• Field: The attributes or fields of an object contain the specific information
about a resource that you want to manage.
• Methods: The actions that can be performed against that object would be
defined as methods to that class of objects.
3.3 Graphic Monitor Facility Host Subsystem (GMFHS)
GMFHS manages the configuration, topology, and status updates from
RODM to the distributed NetView Management Console (NMC) application. It
resides in its own address space at the host and communicates to NetView
through the Program-to-Program Interface (PPI). The PPI serves as a
transport facility for commands, views, and status information passing
between GMFHS and the NetView program at the focal point host. The
information is routed over TCP/IP or LU 6.2 communication sessions between
the NetView program at the host and the NetView Management Console
(NMC) Topology Server at the distributed side, which is, in return,
communicating to connected NMC Topology clients via TCP/IP protocol.
Chapter 3. The ITSO automation project environment 21

36. Note
GMFHS is required only in the system defined as the Focal Point System or
Backup Focal Point System. It is not required to be active in target systems
3.4 Status Display Facility (SDF)
The Status Display Facility (SDF) is a System Automation system resource
monitoring feature that does, unlike the NetView Management Console, not
require RODM or GMFHS to display the status of various resources of the
automation focal point and target OS/390 systems. SDF is a non-graphical,
3270 session based, control panel that uses different colored and highlighted
text strings to inform the subsystem resource states. The resource types
displayed by SDF include:
• Applications and subsystems
• WTORs
• Gateways
Note
A Gateway is a group of one NetView-NetView task session and its two
automated operator tasks, which allows communication of messages,
commands, and responses between the two NetView systems.
SDF is also able to show spool problems and assist requests from OS/390
subcomponents. SDF consists of a hierarchy of dynamically updated panels
showing color-coded status conditions. SDF is set up during the
customization of System Automation for OS/390. The screen shown in Figure
2 on page 23 is an actual sample of the ITSO focal point system SC66.
22 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

37. Figure 2. SDF sample screen of focal point system SC66
Chapter 3. The ITSO automation project environment 23

38. 24 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

39. Chapter 4. Customization of Tivoli NetView OS/390
This chapter details the customization process of Tivoli NetView for OS/390
V1R3. The main emphasis will be a generic and fast setup approach using
system symbolics in the NetView common libraries. No changes should ever
be made to the NetView install libraries, ensuring modifications are not
deleted when applying NetView for OS/390 PTFs. The customizations will
enable system programmers to roll out several NetViews on multiple systems
with minimal additional customization efforts.
At the highest level, the installation of NetView in a multiple system
environment breaks down into five large steps, which are shown in Table 1.
Table 1. High-level NetView installation process in a multi-system environment
# Step Description
1 Plan the environment Obtain details of the environment and what
features are to be installed:
- Number of enterprise Focal Point NetViews
- Number of procedural NetViews
- What NetView features will be running
- Where these NetView will features be running
Document the findings.
2 Define the environment Decide on naming conventions for the planned
environment. Clarify existing system symbolics
being used and consider any new symbolics
that may be required or useful.
3 Full featured test install of Install a full featured copy of NetView on a test
Tivoli NetView for OS/390 system. This will validate findings previously
obtained and will help with the creation of the
common/local library structure.
4 Creation of common Create and populate the common libraries
libraries (which is in effect an install in itself) and create
a task list for the local (domain specific)
installations.
See Section 4.3.6.1, “Local install process for
the networking NetView domains” on page 38,
for an example of a local install task list.
5 Creation of local (domain Follow the task list for each local (domain
specific) libraries specific) NetView installation and create and
populate the domain specific libraries.
© Copyright IBM Corp. 2000 25

40. Note
Refer to Tivoli NetView for OS/390 Installation and Administration Guide,
SC31-8236, for full details of the NetView installation process.
4.1 Planning the Tivoli NetView for OS/390 environment
The details of the project environment are outlined in Chapter 3, “The ITSO
automation project environment” on page 17. It is planned to have one focal
point system and two target systems.
In terms of NetView, this means on the Focal Point system, one Focal Point
NetView for each of the automation and the network environments. For each
of the target systems, it also requires one NetView for each of the two
environments. The total number of NetViews for the planned environment of
three systems is six.
The two Focal Point NetViews are planned to run as full featured enterprise
NetViews, whereas all other NetViews on the target systems are planned to
run only as procedural NetViews.
In this ITSO environment, all of the six NetViews will be connected to their
individual Resource Object Data Manager (RODM) to store and manage the
individual network and system resources.
Note
Within this ITSO project it was decided to setup the environment without
any system resource (storage/workload) limitation. Assuming the
networking and automation objects within the enterprise should be
managed by their own RODM, it was chosen to run separate
RODM/GMFHS applications for the networking and the automation
environment on the focal point system SC66.
For a limited system resource (storage/workload) approach on the focal
point system, when managing not too many networking and System
Automation objects, a configuration with only one RODM/GMFHS on the
focal point system for both environment could be chosen. For a
customization checklist, refer to Appendix C, “One RODM/GMFHS focal
point configuration” on page 241.
26 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

41. For the target systems, it is noted that it is not always required to implement
RODM instances (see Note box).
Note
A RODM instance on the networking target environment is only required if
network resources are to be managed on that particular target system.
A RODM instance on the automation target environment is only required if
using the System Automation enterprise monitoring functions.
Only the Focal Point NetViews will have the graphical interface to the NetView
Management Console topology servers, which will be provided by two
instances of the Graphical Monitor Facility Host Subsystem (GMFHS).
Therefore, in addition to six NetViews to be installed and customized, there
will be also six RODM and two GMFHS installations in the ITSO environment.
4.2 Defining the Tivoli NetView for OS/390 environment
To reduce the effort and time required to roll out an implementation of Tivoli
NetView for OS/390 across multiple systems, a common library structure is
strongly recommended. Within the common libraries are those NetView
members that require no local customization for any particular system or
domain.
The use of common libraries exploits the concept of the OS/390 system and
user defined symbolics, as explained further in Section 4.2.3, “Usage of
OS/390 system symbolics” on page 32.
4.2.1 Recommended library structure in multi-system environment
Figure 3 on page 28 will explain the recommended concept and library
structure for Tivoli NetView for OS/390 in a multi system environment.
Chapter 4. Customization of Tivoli NetView OS/390 27

42. Figure 3. Recommended NetView library structure in a multi-systems environment
Given the recommendation for the NetView library structure, the following
tables will specify the explicit naming conventions for the NetView install
libraries, common network and automation libraries, and all domain specific
libraries.
Table 2. Tier 1: Tivoli NetView install libraries
Install library dataset names Content
NETVIEW.V1R3M0.DSIPARM Supplied DSIPARM members
28 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

43. Install library dataset names Content
NETVIEW.V1R3M0.CNMCLST Supplied CLIST members
NETVIEW.V1R3M0.CNMPNL1 Supplied PANEL members
... ...
It is strongly recommended to never modify the level of product install
libraries. If modifications are necessary to effect all instances of NetView,
then copy the required shipped members to next library level (NetView
common libraries) and modify them on this library level.
If the modifications are effective only for some NetView domains, the required
members need to be copied to, and afterwards modified in, the NetView
domain specific libraries.
Table 3. Tier 2: Tivoli NetView common libraries for the Network environment
Common library dataset names Content
NETVUSER.NETWORK.DSIPARM Modified DSIPARM members
NETVUSER.NETWORK.DSIPARM.ENTERP Modified DSIPARM members,
specifically for Network Focal Points
NETVUSER.NETWORK.DSIPARM.AON Modified DSIPARM members,
specifically for AON
NETVUSER.NETWORK.CNMCLST Modified CLIST members
NETVUSER.NETWORK.CNMCLST.ENTERP Modified CLIST members, specifically
for Network Focal Points
NETVUSER.NETWORK.CNMPNL1 Modified PANEL members
Modifications to this library level effect all instances of NetViews in the
Network environment.
Table 4. Tier 2: Tivoli NetView common libraries for the Automation environment
Common library dataset names Content
NETVUSER.SYSTEM.DSIPARM Modified DSIPARM members
NETVUSER.SYSTEM.DSIPARM.ENTERP Modified DSIPARM members,
specifically for Automation Focal Points
NETVUSER.SYSTEM.DSIPARM.ACF Modified DSIPARM members,
specifically for System Automation
Chapter 4. Customization of Tivoli NetView OS/390 29

44. Common library dataset names Content
NETVUSER.SYSTEM.CNMCLST Modified CLIST members
NETVUSER.SYSTEM.CNMCLST.ENTERP Modified CLIST members, specifically
for Automation Focal Points
NETVUSER.SYSTEM.CNMPNL1 Modified PANEL members
Modifications to this library level effect all instances of NetViews in the
Automation environment.
If modifications are necessary to effect only some NetView domains, then
copy the required members from the NetView common libraries (or NetView
install libraries) to the next library level (NetView domain specific libraries)
and modify them on this library level.
Table 5. Tier 3: Tivoli NetView domain specific libraries
Common library dataset names Content
NETVUSER.<domain name>.DSIPARM Modified DSIPARM members
NETVUSER.<domain name>.CNMCLST Modified CLIST members
NETVUSER.<domain name>.CNMPNL1 Modified PANEL members
where <domain name> Denotes the specific NetView domain
name, for example, SC66N or SC66A
As a common rule, it is recommended to specify a numeric system identifier,
as well as an indicator of the specific environment, into the NetView domain
name. In this project, the following naming convention for the NetView domain
names were chosen:
• Character 1, 2 - System string ‘SC’
• Character 3, 4 - Numeric system identifier, for example, 66 or 42
• Character 5 - Environment identifier, for example, ‘N’ or ‘A’
The library structure of datasets within any single implementation of Tivoli
NetView for OS/390 will then be:
a. NetView install libraries
b. NetView common (global) libraries
c. NetView domain specific (local) libraries
However, the concatenation order of these library dataset names in the
NetView for OS/390 start-up procedure is reverse because existent members
30 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

45. of the domain specific libraries should be loaded first instead of members of
common or install libraries. The concatenation order is thus:
a. NetView domain specific (local) libraries
b. NetView common (global) libraries
c. NetView install libraries
The following example shows the DSIPARM concatenation in a procedural
Network NetView for OS/390:
//DSIPARM DD DSN=&Q1..&DOMAIN..DSIPARM,DISP=SHR
// DD DSN=&Q1..NETWORK.DSIPARM.AON,DISP=SHR
// DD DSN=&Q1..NETWORK.DSIPARM,DISP=SHR
// DD DSN=&SQ1..DSIPARM,DISP=SHR
And, in addition, the example of the DSIPARM concatenation of an enterprise
Network NetView for OS/390:
//DSIPARM DD DSN=&Q1..&DOMAIN..DSIPARM,DISP=SHR
// DD DSN=&Q1..NETWORK.DSIPARM.AON,DISP=SHR
// DD DSN=&Q1..NETWORK.DSIPARM.ENTERP,DISP=SHR
// DD DSN=&Q1..NETWORK.DSIPARM,DISP=SHR
// DD DSN=&SQ1..DSIPARM,DISP=SHR
4.2.2 OS/390 subsystem extensions
Since the ITSO project addresses two different environments, the networking
and the automation NetView environment, it was decided to not only
differentiate the library structures, but to extend, in addition, the OS/390
subsystem definitions for NetView and RODM (GMFHS is not a subsystem).
This can, for example, be achieved by editing the OS/390 system definition
member IEFSSNxx (SYS1.PARMLIB) and adding the following statements:
SUBSYS SUBNAME(NETC)
SUBSYS SUBNAME(NETV)
SUBSYS SUBNAME(EKGN)
SUBSYS SUBNAME(EKGA)
These subsystem extensions created in this ITSO project lead to the following
subsystem and start-up procedure naming conventions for NetView and
RODM (for GMFHS, just start-up procedure names):
• Networking environment:
- Subsystem names:
• RODM: EKGN
• NetView: NETC
Chapter 4. Customization of Tivoli NetView OS/390 31

46. - Start-up procedure names:
• RODM: EKGNss
• NetView: NETCssN
• GMFHS: GMFHSssN
where <ss> reflects the system identifier.
• Automation environment:
- Subsystem names:
• RODM: EKGA
• NetView: NETV
- Start-up procedure names:
• RODM: EKGAss
• NetView: NETVssA
• GMFHS: GMFHSssA
where <ss> reflects the system identifier.
4.2.3 Usage of OS/390 system symbolics
Tivoli NetView for OS/390 has supported the use of MVS system and user
defined symbolics since V1R1, and each release has extended this
functionality.
The use of these symbolics can simplify the installation and maintenance
effort required in a sysplex-wide implementation of Tivoli NetView for OS/390.
Note
MVS V5R2M0 or higher is required for system and user defined symbolic
support.
The symbolics used in this project are listed in Table 6.
Table 6. System symbolics used in this project
SYMBOLIC COMMENTS
&SYSNAME. Name of the system - On the systems in this project, this was “SC”
followed by the clone ID (see below).
&SYSCLONE. On the project systems, a two-character numeric field used to
identify the clone ID.
32 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

47. For example, on system SC66, the values coded in the IEASYMxx member of
PARMLIB would be :
SYSNAME(SC66)
SYSCLONE(&SYSNAME(3:2))
To determine current symbols on one system, issue the following MVS
command from the TSO system log (SDSF) or from the NetView NCCF
interface (with prefixed command string ‘MVS‘):
D SYMBOLS
An example of the use of this technique is in the NetView start-up procedure,
where the symbolic &SYSNAME. was used to generate the NetView domain
name :
// DOMAIN=&SYSNAME.N, ** NETVIEW DOMAIN NAME
This enabled the usage of common JCL across systems running the same
NetView configuration (that is, procedural or enterprise).
Note
The &DOMAIN. symbolic generated in this way can be used in the various
NetView configuration members and will be automatically resolved to its
correct value. It was found that &DOMAIN. was, in fact, the most commonly
used symbolic and was the most useful in setting up the common libraries.
4.3 Network management environment
For the networking environment, the results of step 1 and step 2, the process
of planning and defining the networking NetView environment, were as
follows:
• System SC66 running an enterprise NetView with base AON installed.
This acted as the AON focal point for all three systems. It also ran RODM
and GMFHS linked to an NMC server.
• System SC42 running a procedural NetView with base AON installed.
• System SC69 running a procedural NetView with base AON installed.
The NetView domain name in each case was the system name suffixed with
‘N’, for example, SC66N.
Chapter 4. Customization of Tivoli NetView OS/390 33

48. 4.3.1 Creation of common networking NetView libraries
After completing step 3, the full featured test install of Tivoli NetView for
OS/390, the next sections will describe step 4, the process of
creation/modification of common networking libraries.
According to the recommended naming convention for the NetView library
structure, the following common libraries were created:
- DSIPARM:
• NETVUSER.NETWORK.DSIPARM
• NETVUSER.NETWORK.DSIPARM.AON
• NETVUSER.NETWORK.DSIPARM.ENTERP
- DSIPRF:
• NETVUSER.NETWORK.DSIPRF
- VTAMLST:
• NETVUSER.NETWORK.VTAMLST
- CLIST:
• NETVUSER.NETWORK.CNMCLST
• NETVUSER.NETWORK.CNMCLST.ENTERP
- PANELS:
• NETVUSER.NETWORK.CNMPNL1
• NETVUSER.NETWORK. SEZLPNLU
- Where the .AON suffixed library contains common modified AON
members, and the .ENTERP suffixed libraries contain modified
members specific to enterprise versions of NetView.
The creation process of the common networking libraries involves working
through the NetView install procedures and the full featured test install of
NetView and populating the common libraries with exploitation of system
symbolics to avoid the need for local customization as far as possible.
Using this approach, it was found that very little customization on the local
(domain specific) library level was required to establish the network
management environment. These local customizations are further described
in Section 4.3.6, “Creation of local (domain specific) NetView libraries” on
page 37.
34 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

49. All other networking customizations could be achieved by modifying the
common networking library level, as described below.
4.3.1.1 Common networking DSIPARM library
The following table lists the modified members in the common networking
DSIPARM library.
Table 7. Modified members in NETVUSER.NETWORK.DSIPARM
MEMBER COMMENTS
DSIDMNB TASK MOD=CNMCSSIR,TSKID=&DOMAIN.SIR, etc.
TASK MOD=DSIZDST,TSKID=&DOMAIN.LUC,MEM=DSILUCTD,
etc.
TASK MOD=CNMTARCA,TSKID=&DOMAIN.VMT,PRI=5,INIT=N
TASK MOD=CNMTGBRW,TSKID=&DOMAIN.BRW,PRI=5,INIT=N
DSIDMNK NCCFID DOMAINID=&DOMAIN.,DMNPSW=&DOMAIN., etc.
DSITBL01 SYN %NV_DOMAIN% = '''&DOMAIN.''';
DSIVPARM VPDINIT
ACBNAME=VPDACB,PASSWORD=&DOMAIN.,VPDREQ=001
DUIFPMEM SC = &DOMAIN.
DUIGINIT RODMNAME=RODM&SYSCLONE.N
DOMAIN=&DOMAIN.
FLBSYSD RODMNAME="RODM&SYSCLONE.N"
APPLNAME="&SYSNAME.NSNA"
APPLPASS="&SYSNAME.N"
FLBSYSDA APPLPASS="&SYSNAME.N"
4.3.1.2 Common networking DSIPARM library (specific AON)
The following table lists the modified members in the common networking
DSIPARM library specifically for AON.
Table 8. Modified members in NETVUSER.NETWORK.DSIPARM.AON
MEMBER COMMENTS
EZLCFG01 AUTOOPS GATOPER,ID=GAT&DOMAIN.
Chapter 4. Customization of Tivoli NetView OS/390 35