automation using tivoli netview os-390 v1r3 and system automation os-390 v1r3 sg245515

7/31/2019 Automation Using Tivoli NetView OS-390 V1R3 and System Automation OS-390 V1R3 Sg245515

1/280

SG24-5515-00

International Technical Support Organization

www.redbooks.ibm.com

Automation Using Tivoli NetView OS/390 V1R3and System Automation OS/390 V1R3

Holger Stamme, Ling Xiao Gao, Marcio Guimaraes, Clive Kennedy, Jason Wyer
http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/


2/280


3/280

Automation Using Tivoli NetView OS/390 V1R3and System Automation OS/390 V1R3

March 2000

SG24-5515-00

International Technical Support Organization


4/280

Copyr ight International Business Machines Corporati on 2000. All rights reserved.

Note to U.S Government Users Documentation related to restricted rights Use, duplication or disclosure issubject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

First Edition (March 2000)

This edition applies to Tivoli NetView for OS/390 V1R3 and System Automation for OS/390 V1R3 foruse with the OS/390.

This document created or updated on March 14, 2000.

Comments may be addressed to:IBM Corporation, International Technical Support OrganizationDept. OSJB Building 003 Internal Zip 283411400 Burnet RoadAustin, Texas 78758-3493

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

Before using this information and the product it supports, be sure to read the general information inAppendix D, Special notices on page 245 .

Take Note!


5/280


6/280

iv Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

4.3 Network management environment . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3.1 Creation of common networking NetView libraries . . . . . . . . . . . 344.3.2 Setting up the base components NetView for OS/390. . . . . . . . . 364.3.3 Setting up the Resource Object Data Manager . . . . . . . . . . . . . . 364.3.4 Setting up the Graphic Monitor Facility Host Subsystem. . . . . . . 374.3.5 Setting up the Automated Operation Network feature . . . . . . . . . 374.3.6 Creation of local (domain specific) NetView libraries . . . . . . . . . 37

4.4 Automation environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.1 Creation of common automation NetView libraries . . . . . . . . . . . 404.4.2 Setting up the base NetView for OS/390. . . . . . . . . . . . . . . . . . . 474.4.3 Setting up the Resource Object Data Manager . . . . . . . . . . . . . . 474.4.4 Customizing RODM load jobs in the automation environment. . . 494.4.5 Setting up the Graphic Monitor Facility Host Subsystem. . . . . . . 494.4.6 Creation of local (domain specific) NetView libraries . . . . . . . . . 50

Chapter 5. Customization of System Automation for OS/390 . . . . . . . 535.1 Base System Automation customization. . . . . . . . . . . . . . . . . . . . . . . 53

5.1.1 Preparation and set up jobs for System Automation . . . . . . . . . . 535.1.2 Preparing the OS/390 system environment and library . . . . . . . . 555.1.3 Creating System Automation policy database dialog panels . . . . 56

5.2 Usage of system symbolics and System Automation synonyms . . . . . 595.3 Defining all systems and objects to System Automation . . . . . . . . . . . 605.3.1 Starting the System Automation policy database dialog . . . . . . . 615.3.2 Creating a new System Automation policy database. . . . . . . . . . 625.3.3 Entering all systems and objects . . . . . . . . . . . . . . . . . . . . . . . . 645.3.4 Building SA Automation Control File (ACF) . . . . . . . . . . . . . . . . . . . . 985.3.5 Build RODM loader input file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.4 Defining dependencies and start-up behavior. . . . . . . . . . . . . . . . . . 1035.4.1 Define dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.4.2 Define start-up behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5.5 Customizing the Status Display Facility (SDF) . . . . . . . . . . . . . . . . . 1085.5.1 Customizing the panel member AOFPNLS . . . . . . . . . . . . . . . . 1085.5.2 Customizing the status member AOFTREE . . . . . . . . . . . . . . . 1105.5.3 Defining SDF gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.5.4 Starting the SDF monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Chapter 6. Installation of the NetView Management Console . . . . . . 1156.1 Prerequisites for NetView Management Console Version 1.3 . . . . . . 1176.2 Setting up the NMC Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6.2.1 Installing NMC Server to run as a Windows NT service . . . . . . 1176.2.2 Setting up NMC Topology Server for Systems Automation . . . . 1236.2.3 Starting the NMC Topology Server using TCP/IP . . . . . . . . . . . 1276.2.4 Uninstalling the NMC Topology Server . . . . . . . . . . . . . . . . . . . 128


7/280

v

6.2.5 Hints and tips for the NMC Topology Server . . . . . . . . . . . . . . . 1296.3 Setting up the NMC client workstation . . . . . . . . . . . . . . . . . . . . . . . 131

6.3.1 Installing the NMC Topology Console . . . . . . . . . . . . . . . . . . . . 1316.3.2 Starting the NMC Console using a TCP/IP connection . . . . . . . 1336.3.3 Uninstalling the Tivoli NMC Topology Console . . . . . . . . . . . . . 1346.3.4 Hints and tips for the NMC Topology Console . . . . . . . . . . . . . 1356.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 . . . . . . . . . . . . . 1426.5.1 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1426.5.2 Selecting the correct files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436.5.3 Available documentation and technical information. . . . . . . . . . 1446.5.4 Setting up the host (mainframe) environment . . . . . . . . . . . . . . 1446.5.5 Installing NetView 3270 Console on Windows 95, 98, and NT . 1466.5.6 Uninstalling the NetView 3270 Console . . . . . . . . . . . . . . . . . . 1506.5.7 Replicating the NetView 3270 Console . . . . . . . . . . . . . . . . . . . 1516.5.8 Operating notes, hints, and tips . . . . . . . . . . . . . . . . . . . . . . . . 152

Chapter 7. Maintenance of Tivoli NetView and System Automation . 1557.1 Automation table maintenance using AUTOMAN . . . . . . . . . . . . . . . 155

7.1.1 Enabling the AUTOMAN function for the Automation NetView . 1557.1.2 Using AUTOMAN command . . . . . . . . . . . . . . . . . . . . . . . . . . . 1567.2 Netview and automation table optimization for performance . . . . . . . 166

7.2.1 NetView automation table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1667.2.2 Additional hints and tuning considerations . . . . . . . . . . . . . . . . 168

7.3 Maintenance of the System Automation policy data base . . . . . . . . . 1707.3.1 Design a hierarchical structure . . . . . . . . . . . . . . . . . . . . . . . . . 1707.3.2 Using ADD/REMOVE commands . . . . . . . . . . . . . . . . . . . . . . . 1717.3.3 RACF considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1717.3.4 System Automation migration . . . . . . . . . . . . . . . . . . . . . . . . . . 1727.3.5 Building for ACF and RODM. . . . . . . . . . . . . . . . . . . . . . . . . . . 1727.3.6 Policy report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1737.3.7 ACFPLOAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Chapter 8. Base automation features . . . . . . . . . . . . . . . . . . . . . . . . . 1758.1 New automation table features of NetView for OS/390 V1R3 . . . . . . 175

8.1.1 Multi-line message support. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1758.1.2 IF-THEN condition item substrings . . . . . . . . . . . . . . . . . . . . . . 1768.1.3 Greater-than and less-than operator support . . . . . . . . . . . . . . 1778.1.4 Numeric comparison and current time support . . . . . . . . . . . . . 1778.1.5 Variable value function support. . . . . . . . . . . . . . . . . . . . . . . . . 1778.1.6 Message reformatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1788.1.7 Automation table tracing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179


8/280

vi Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

8.1.8 The AUTOMATED function. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1808.2 System Automation framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

8.2.1 Automating subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1818.2.2 Automating messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

8.3 System Automation and NetView base automation rules . . . . . . . . . 197

Chapter 9. Automation example scenarios . . . . . . . . . . . . . . . . . . . . . 1999.1 NetView SMTP mail gateway support. . . . . . . . . . . . . . . . . . . . . . . . 199

9.1.1 NetView provided samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1999.1.2 Required customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2009.1.3 Sending SMTP e-mail with EZLEMAIL . . . . . . . . . . . . . . . . . . . 2019.1.4 Sending SMTP e-mail from AON Inform policies. . . . . . . . . . . . 2029.1.5 Sending SMTP e-mail from user-written clists. . . . . . . . . . . . . . 203

9.2 System Automation in a multi-system focal point environment . . . . . 2049.2.1 Defining Automation Network process . . . . . . . . . . . . . . . . . . . 205

9.3 Using NetView AON inform policies by System Automation . . . . . . . 2149.3.1 Installation of AON inform policy in the Automation NetView. . . 2149.3.2 Inform policy customizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2159.3.3 Calling the Inform policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2179.3.4 Calling AON Inform policy from System Automation . . . . . . . . . 218

9.4 Brief comparison of NMC and SDF Consoles . . . . . . . . . . . . . . . . . . 2249.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 . . . . . . . . 233B.1 Other System Automation jobs and definitions . . . . . . . . . . . . . . . . . . . . 234

B.1.1 Automation NetView start-up procedure. . . . . . . . . . . . . . . . . . . . . 235B.1.2 System Automation RODM procedure . . . . . . . . . . . . . . . . . . . . . . 237B.1.3 Automation GMFHS start-up procedure . . . . . . . . . . . . . . . . . . . . . 238B.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249E.1 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249E.2 IBM Redbooks collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249E.3 Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249E.4 Referenced Web sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

How to get ITSO redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251IBM Redbook fax order form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252


9/280

vii

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265


10/280

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


11/280

Copyright IBM Corp. 2000 ix

Preface

The objective of this redbook is to provide an easy to use and understandautomation guide for large organizations. The major focus of this redbook ison how to efficiently set up and customize Tivoli NetView for OS/390 andSystems Automation for OS/390 in a multi-systems enterprise environment.

In addition to this, this redbook provides best practices and tips formaintenance issues of the Tivoli NetView and System Automationenvironment. This will include the AUTOMAN feature for maintenance ofmultiple automation tables, basic tuning considerations to improve generalNetView and automation table performance, as well as an optimized structureof the System Automation policy database.

To help system administrators and operators establish and leverage theirautomation environment, this redbook provides further information on basicautomation features, such as the System Automation framework, and someautomation 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 orescalations by sending e-mails using the SMTP gateway support.

The steps outlined in this redbook are based on, and supported by, examplesderived from the actual installation, set up, and customization of TivoliNetView 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 worldworking at the International Technical Support Organization, Austin Center.

Holger Stamme is a Certified IT Architect at the ITSO, Austin Center, whohas more than 10 years of working experience in consulting, designing, andimplementing Systems Management solutions within IBM. Before joining theITSO in 1999, he was leading the architectural and design phases of largecustomer projects in the finance and insurance industry in Germany.

Ling Xiao Gao is a Advisory IT Specialist in China. He has seven years ofexperience in MVS and OS/390 fields. His areas of expertise include NetViewfor OS/390 and System Automation.


12/280

x Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

Marcio Guimaraes is an Advisory IT Specialist in Brazil. He has eight yearsof experience in the IT field, of which the last five years have been indeveloping, designing, and supporting the System Management area. Hisareas of expertise include Tivoli NetView for OS/390 and System Automationfor OS/390.

Clive Kennedy is a Network Automation Specialist with AT&T GlobalNetworks in the UK. He has over 20 years experience in Systems and

Network Management in large MVS installations and over 12 yearsexperience using NetView OS/390 for Systems and Network Automation.

Jason Wyer is an IT Consultant working for PricewaterhouseCoopers in theUSA. 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 ofexpertise include Microsoft Windows environments.

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

Adam BarryTivoli Systems Raleigh, Network Management Applications Development

Denny BearyIBM Gaithersburg, S/390 Systems Management Technology Support

Budi DarmawanInternational Technical Support Organization, Austin Center

Gary ForghettiTivoli Systems Raleigh, Tivoli Product Introduction

Roland HaiblIBM Boeblingen, System Automation for OS/390 Information Development

Robert HaimowitzInternational Technical Support Organization, Raleigh Center

Stephan HartigIBM Boeblingen, System Automation for OS/390 Information Development

Joseph MaceraIBM Los Angeles, Tivoli Migration Team

Wade MillerTivoli Systems Raleigh, NetView Performance Group


13/280

xi

Paul QuigleyTivoli Systems Raleigh, Network Management Applications Development

Phil RiedelTivoli Systems Raleigh, Network Management Applications Development

Joachim SchmalzriedIBM Boeblingen, System Automation for OS/390 Information Development

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

Fax the evaluation form found in IBM Redbooks review on page 265 tothe fax number shown on the form.

Use the online evaluation form found at http://www.redbooks.ibm.com/

Send your comments in an Internet note to [email protected]
http://www.redbooks.ibm.com/contacts.htmlhttp://www.redbooks.ibm.com/contacts.htmlhttp://www.redbooks.ibm.com/contacts.htmlhttp://www.redbooks.ibm.com/contacts.html


14/280

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


15/280

Copyright IBM Corp. 2000 1

Chapter 1. Introduction to Tivoli NetView for OS/390 V1R3

This chapter provides a brief overview of the functions in Tivoli NetView forOS/390 V1R3, which is extracted from the Request for Announcement (RFA).In addition, some information about the configuration used during theresidency will be provided.

A complete list of all the hardware and software requirements for each TivoliNetView for OS/390 V1R3 function is provided in the announcement letterand 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-businesscomplexity. Building on the already rich functionality of Tivoli NetView forOS/390, V1R3 provides enhancements in the following areas:

It is possible to issue any TCP/IP, SNMP, or UNIX command from TivoliNetView for OS/390 either through a user-friendly panel interface or inClists that are written to extend the functions NetView provides.

SNMP services include a MIB compiler/loader and a MIB browserlaunched from the NMC. There is also a robust 3270 interface for issuingSNMP requests, such as GET/SET/etc. MIB polling and thresholds alsoaid 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 trapsto 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 systemsmanagement by focusing on operator productivity through the use ofgraphical displays and embedded automation capability. Tivoli NetView for


16/280

2 Automation Using Tivoli NetView OS/390 V1R3 and System Automation OS/390 V1R3

OS/390 continues its leadership in SNA management and strongly addressesthe management of mixed network architecture environments.

Tivoli NetView for OS/390 V1R3 focuses on management of IP networks andSNMP-based devices, management of IP clients accessing mainframeapplications, and integration with third-party network and elementmanagement vendors.

TCP/IP management can be accomplished through the use of native OS/390TCP/IP management or in cooperation with management applications ondistributed platforms. This includes IP agents available for Tivoli NetView onAIX, Sun Solaris, or Windows NT, and HP OpenView on Sun Solaris orHP-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, orcommand procedures, support for logical groupings of MIB variables, remotePing support, MIB polling, and thresholds aid in resource monitoring and

automation. Not all functions are available from both the NMC and 3270interfaces.

Any socket can now be monitored for availability. If the socket is down, thenautomation can attempt to restart its associated application, job, or task.

TN3270 session management now includes support for the remote TN3270server feature on both Cisco and IBM routers plus support for connectionswith any TCP socket.

Tivoli NetView for OS/390 provides the ability to launch a Web interface forany vendor application from the NetView Management Console (NMC).

NMC improvements include view cycling, view and resource security, andother ease-of-use enhancements. In addition, there are enhancements thatintegrate the NMC and NetView 3270 Management Console into a singleconsole.

Tivoli NetView's robust timer and automation table capabilities are expandedto assist in automation table management, and a new CHRONcommand withcalendering support.

Tivoli NetView for OS/390 now adapts dynamically to daylight savings timeand other system time changes without requiring a recycle.


17/280

Chapter 1. Introduction to Tivoli NetView for OS/390 V1R3 3

1.3 Description

Building on the already rich functionality of Tivoli NetView for OS/390, theV1R3 provides the additional enhancements, which are discussed in thefollowing sections.

1.3.1 IP management

Tivoli NetView for OS/390 V1R3 provides the operator with the ability tomonitor and control the enterprise-wide, multi-protocol network from a singleconsole. This includes the ability to view and manage the protocol-basednetwork topologies, network devices, and the interrelationships betweenthem.

Graphical Network Management now includes IP agents available onTivoli NetView for Sun Solaris, Tivoli NetView for Windows NT, HPOpenView for Sun Solaris, and HP OpenView for HP-UX. The agentsenable collection of IP topology and status discovered by the distributedSNMP-based network managers and forwarded to Tivoli NetView forOS/390 on a TCP/IP session. This enables management of IP networksfrom 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 asan LU6.2 connection.

For topology updates and status changes, Tivoli NetView for OS/390 nowhas the ability to receive SNMP traps about IP resources and convert themto SNA alerts and status updates.

Conversion of SNA alerts into SNMP traps allows OS/390 captured alertsto be forwarded to distributed SNMP management applications.

A sample IP Layer 3 discovery engine that runs natively on OS/390minimizes the need to define resources to be managed.

Topology correlation has been enhanced to generate enterprise specificviews more easily. Critical resources can now be automatically linked to ahierarchy of topology resources, such as "Room 12, Warehouse 2, HongKong, Manufacturing." If business views are not found, they will becreated. Topology correlation is now easier to invoke through integrationwith BuildViews and Visual BuildViews.

Continuing to build on end-to-end network management, NetView forOS/390 provides the ability to launch a Web interface for any vendorapplication from the NetView Management Console. Use of this functionincludes CiscoWorks Blue and IBM Nways Manager Element Manager.This allows operators to manage the enterprise from one control console


18/280


and seamlessly work with other management tools without changingmanagement consoles.

From the NMC, you can retrieve inventory data for IBM and Cisco networkinterconnect devices from the Tivoli Inventory database. The TivoliInventory database is populated by Tivoli Manager for CiscoWorks 2000and 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 MIBcompiler/loader function, which allows Tivoli NetView for OS/390 tosupport any vendor specific MIB described using the standard ASN.1format. SNMP services provide an SNMP stack facility. Full SNMPcommandsupport is provided from NMC command pull-downs.

The Tivoli Management Region (TMR) agent is enhanced to collecttopology 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 WALKcommands fromTivoli 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 automationroutines.

It is possible to define which MIB variables to check at specified intervalsand take action if a threshold is exceeded. User exits are available for MIBpolling and MIB thresholding to provide the capability to do more extensiveanalysis or automation.

Extending previous support for managing TN3270 and FTP sessions, anysocket connection can now be monitored for availability. Operators candisplay session status for any socket connection, including TN3270sockets, 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 configuredto support multiple TN3270 sockets, then Session Management can alsobe configured to support multiple sockets for TN3270 connections.

Sessions being displayed by Session Management can be filtered. Forexample, operators can set filters to see only TN3270 sessions fromsubnet 146.48.*.* to applications starting with CICS.

IP session management has been extended to include sessions betweenIP clients and SNA mainframe applications connected through TN3270servers. Servers supported include IBM 2210 and 2216 and Cisco'sChannel Interface Processors (CIP) and Channel Port Adapters (CPAs).


19/280


Tivoli NetView for OS/390 has predefined MIB group definitions to collectSNMP data that is most meaningful to the operators. Additionally, it ispossible to define your own groups to present MIB data best suited for thespecific SNMP environment.

1.3.2 Graphical consoleThe NetView Management Console (NMC) now has equivalent functionalityto NGMF plus several additional customer-requested capabilities. In addition,there are enhancements that integrate the NMC and NetView 3270Management Console (formerly known as the 3270 Java (TM) Client) into asingle console. These enhancements include:

View cycling

Resource session data from session monitor (including configuration data)

Launching Web interface for vendor applications, such as CiscoWorksBlue 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 toread a message

Additional hot key support, such as ctrl-H for help, ctrl-L for locateresource, and ctrl-F for find

New menu item to quickly suspend/unsuspend resources fromaggregation

Closing a view and/all descendent views

Selection of multiple resources (including selecting objects in a specifiedregion of the view)

Customized dynamic views displayed on a business tree structure

Finding objects in a view


20/280


The ability to write a client application to send a command to TivoliNetView for OS/390 and receive a correlated response back forsubsequent processing

Built-in Java runtime environment eliminating the need for a separateinstallation 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 featuresThe automation enhancements include additional functions and usability inthe 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 automationtable

The ability to use PIPE EDIT functionality in automation table conditionsand actions

A tool for managing multiple automation tables (AUTOMAN)

Support allowing operators to send e-mail directly from Tivoli NetView forOS/390 via a panel interface using SMTP

Greatly enhanced timer support through a new CHRONcommand whichprovides capabilities such as:

- The ability to define enterprise-unique dates of importance, such asholidays, vacations, and payroll days, using a customizable calendarthat can be dynamically reloaded.

- Very flexible specification of dates and times for timer executionincluding days of the week or days of the month; for example, you canspecify that a certain command is to be executed at 10:00 everyMonday that is not a holiday.

- The ability to specify repeated timers that automatically compensate fordaylight savings time or other system time changes.

An enhanced panel interface (TIMER) for viewing and creatingtimer-driven commands, including support for the CHRONcommand


21/280


1.3.4 Other customer satisfaction enhancementsFurther customer satisfaction enhancements include:

Dynamic timer adjustment to allow Tivoli NetView for OS/390 to remain upand running through daylight savings time changes or other system timechanges.

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 forOS/390 since planned outages are no longer necessary except forapplication of maintenance between releases.

The use of system symbolics for all components of Tivoli NetView forOS/390 allows easier configuration of multiple instances of Tivoli NetViewfor OS/390 throughout your enterprise and reduces maintenance efforts ina multi-system OS/390 environment.

Visual BLDVIEWS support to provide an easy-to-use graphical interface tocreate views and modify resource information.

A new NetView SOCKETcommand to facilitate communication with otherTCP/IP applications and devices from automation procedures or theNetView command line.

The ability for an operator to log on with an active autotask of the samename or take over a task logged on elsewhere. In addition, the RMTCMDcommand can take over tasks already logged on or make use of tasksbeing used for other purposes.

Conversion of initial clist to use REXX and pipes.

Support for personal operator data sets to allow for operatorcustomizations, including the ability to save and restore personalized PFkey settings.

The ability to use up to eight characters for the command prefix used toissue Tivoli NetView for OS/390 commands from an MVS console.

Support for Tivoli Software Distribution file packs to distribute and installworkstation components where Tivoli Software Distribution is deployed,thus, making software install easier on distributed platforms connecting toTivoli NetView for OS/390.

The ability to view session monitor configuration data from the NMC orfrom a Web browser.

Customizable Title Line on the Command Facility screen.

Many improvements to the NetView Pipe command.


22/280


Upgrading of MEMSTORE and IDLEOFF from samples to supported TivoliNetView for OS/390 commands.

BROWSE NETLOG support for the HDRMTYPE field.

Enhanced ability to locate network node (NN) servers in APPNenvironments 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 beforereading from or writing to a data set member when EXECIO is done ina NetView command list.

- More granularity in submitting jobs via NetView's SUBMITcommand.

Resource monitor enhancements to help determine which task is queuingtoo many messages and to provide more flexibility in logging usagestatistics in SMF.

Several customer requested enhancements to the NetView 3270Management Console (previously known as the 3270 Java client), such asremappable colors and keyboard, an editable session list, and an option tohide the PF keys palette.

Access to Tivoli NetView for OS/390 using a standard Web browserincludes these enhancements:

- An operator sending a LOGOFFcommand to NetView from a Webbrowser can be prompted for their operator ID and password the nexttime 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 accessfrom commands entered through traditional NetView tasks.

- Support for frames and support for JavaScript (.js) as a valid file type.


23/280


1.3.5 Product positioning in the marketTivoli NetView for OS/390 Version 1 Release 3 is an integral part of the Tivolienvironment that provides a comprehensive set of tools for maintainingcomplex, multi-vendor, multi-platform networks and systems from a singlepoint of control.

With its open application programming interfaces (APIs), Tivoli NetView forOS/390 can be an integration point for other S/390 vendors to the Tivolidistributed environment.

Tivoli NetView for OS/390 is a program for managing networks and systemsthrough a strong set of automation features and graphical console displays. Itreduces manual resource definition and complex automation set-up throughproduction-ready automation and extends centralized management intomultiple, non-SNA network environments. Tivoli NetView for OS/390 can beused in a large enterprise organization as a centralized manager, a mid-levelmanager, or just as a S/390 management endpoint.

Tivoli NetView for OS/390 Version 1 Release 3 is the last release that willsupport 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 onIBM best technical judgement at this time. IBM makes no guarantee thatthis information will not change based on future business decisions.

Note


24/280



25/280


Chapter 2. Benefits of using System Automation for OS/390

This chapter describes why it is essential to use System Automation forOS/390. An effective and proactive management of OS/390 subsystemcomponents or applications includes functions, such as monitoring, recoverycapabilities, and ease of use.

2.1 Why automate?

The need to simplify operations increases as you add hardware and softwareproducts to your data center, data centers to your network, and personnel toyour data-processing staff. By simplifying your operations, SystemAutomation can help you meet required service levels, contain costs, makeefficient use of your operation staff, and remove repetitive tasks from beingreliant on human frailties.

System Automation offers system-wide benefits by simplifying your operatingenvironment. You can reduce the amount of manual intervention required tomanage operating systems, subsystems, application programs, and manyother products.

This is particularly important in a multiple system, especially for a ParallelSysplex environment. However, the job of managing these multiple images orsystems is not a simple task.

There are opportunities during the operation in multiple system or ParallelSysplex environments where, despite the best efforts of software developersand testers, human intervention is required. The phrase to err is human hasnever been more true than in computer operations.

Given that the enterprise wide environment is complex, and that humanerrors 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 continuousoperations.

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, isthe ITSO redbook, Parallel Sysplex Automation: Using System Automation for OS/390 , SG24-5442, published in September of 1999.


26/280


2.2 Proactive management of OS/390 subsystem tasks

The purpose of the proactive management features of System Automation isaddressing the automation of repetitive tasks that operators currentlyperform. Today, the operators usually respond in a particular way to amessage, or perform a task in accordance to the standard operatingprocedures. Coding automation routines to replace these tasks is relativelystraight 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 usea program, such as the MVS SYSLOG Message Analysis Program, which canbe downloaded from URL http://www.s390.ibm.com/sa , to see whatmessage triggers are being issued and base your automation (and messagesuppression) on the output of the tool.

In this book, you will find information, hints, and tips to start up and control amultiple system OS/390 environment and how to build a hierarchy of yourconnected 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 recoverycapabilities of System Automation for OS/390. It addresses the automation ofevents based on what is currently happening in your OS/390 systems.

Typically, automation routines address both of these areas. But of the two, themonitoring and recovery capabilities of unsolicited events are by far morecomplex to resolve. This is due to the fact that it is not precisely known whatto automate without having experienced relevant problems.

When developing automation routines to handle error conditions, the triggersare not always as obvious. One way around this is to experience the problemfirst, then, based on what happened, code routines to automate the handlingof that condition. This works as long as you are happy to experience everyproblem or error condition at least once. One other approach is to dive into allthe message manuals and try and look for likely messages to automate.

This book will provide some information, hints, and tips on unsolicited eventsin a multiple system OS/390 environment and how to monitor and recoverfrom these critical situations.

In addition, it will be shown how to notify or escalate in situations wheresuccessful recovery is not possible.


27/280

Chapter 2. Benefits of using System Automation for OS/390 13

2.4 Automation features of System Automation for OS/390 V1R3

This section provides a brief overview of the new System Automation V1R3features.

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 supportSystem Automation for OS/390 V1R3 comprises full sysplex and singlesystem image support. Now, systems in the sysplex need not be automatedseparately, but one system in the sysplex acts as a single point of controlwhere the operator can specify the resources and their automation of theentire sysplex environment. Using the System Display Feature (SDF) on theSystem Automation focal point and System Automation instances on each ofthe systems in the sysplex environment, it is possible to display the statusand workloads of resources as well as control and manage them. The supportof single system image helps to optimize operating tasks and improvesproductivity.

2.4.2 Better managing your applicationsOptimizing the availability of applications when they are needed is animportant issue in data processing. System Automation enables the user todefine the availability of resources to meet a company's specific needs withthe following set of functions:

Service periods are user specified time intervals, during which anapplication should be active.

Events are part of a trigger condition. If the event of a trigger conditionhas occurred, the startup or shutdown of an application is performed. Ifthere is a service period also connected to the trigger, then it will checkthe service window to determine whether a shutdown or start-up should beperformed.

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 ofapplication B.


28/280


2.4.3 Simultaneously updating policy databases for applicationsThe customization dialogs are enhanced to allow for multi-user access to thepolicy database for applications. To improve the ease-of-use for updates ofthe policy database for applications, changes can now be done in parallel byvarious automation administrators.

2.4.4 Notifying the Tivoli Enterprise Console

System Automation for OS/390 V1R3 now includes integration with the TivoliManagement Environment. Events reported by System Automation, as wellas events reported in a distributed environment, are received at, and handledfrom, a single point of control. Therefore, System Automation notifies theTivoli Enterprise Console (TEC) in situations when System Automation issuesmessages and alerts indicating critical situations. These messages and alertsare forwarded to the TEC event server by the Event Automation Server(EAS).

2.4.5 Other enhancementsThe following enhancements were further introduced by System Automationfor OS/390 V1R3:

Workload Manager (WLM ) resource name support

By introducing this ability, the interface to the operating system OS/390has been improved. SA OS/390 now passes status information about theresources to the operating system's Workload Manager.

AOCQRES command

With this command you can examine where, in a sysplex environment, aresource is located and return information about this resource. Optionally,it also supplies up-to-date status information about resources.

Partial ACF load

The new ACFPLOADcommand allows small changes in the automationconfiguration without having to reload the entire ACF file and withoutinterrupting 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 basedcommands are now able to be piped for further processing. The operatordialog NetView panels have been enhanced to support displays of up to43 lines per panel.

SHUTSYS command


29/280

Chapter 2. Benefits of using System Automation for OS/390 15

The default of the SHUTSYScommand is now set to VERIFY=NO forunattended processing.

Overall performance

The overall performance has been improved by restructuring tasks, whichaccelerates the start-up and the shutdown of subsystems.

In the System Automation customization dialog it is now possible to definea set of auto operators to handle subsystem automation.


30/280



31/280


Chapter 3. The ITSO automation project environment

The following sections will provide a brief description of some basic conceptsthat are commonly used when working with focal points and graphicalenterprise features. Further detailed information about these topics areprovided within the Tivoli Netview for OS/390 and System Automation forOS/390 technical documentations.

System Automation for OS/390 allows control of the customization,monitoring, and management functions of multiple systems or images in theenterprise (each running System Automation instances), using a single,centrally located OS/390 system. This controlling OS/390 system is called thefocal point system . The managed systems in the environment are calledtarget systems . All connected systems communicate between each otherthrough Tivoli NetView for OS/390 using specific Netview data transportmechanisms.

Figure 1 on page 18 shows a high-level diagram of the environment usedduring 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 twosystems, SC42 and SC69, are target systems.

Within this ITSO project, it was decided to set up the environmentconsisting of the three systems, SC66, SC42, and SC69, without anysystem resource (storage/workload) limitations. Assuming the networkingand automation objects within the enterprise should be managed by theirown RODM, it was decided to run separate RODM/GMFHS applications forthe networking and the automation environment on the focal point system.

For a limited system resource (storage/workload) approach on the focalpoint system, when managing a reasonable number of networking andSystem Automation objects, a configuration with only one RODM/GMFHSon the focal point system for both environments can be chosen. Refer toAppendix C, One RODM/GMFHS focal point configuration on page 241 ,for a customization checklist.

Note


32/280


Figure 1. ITSO project environment


33/280

Chapter 3. The ITSO automation project environment 19

3.1 Types of communication

Since its earliest releases, Tivoli Netview for OS/390 provides three differentdata transport mechanisms that support the centralized operations from afocal 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 NetViewprograms that reside in different domains or systems. The LU 6.2communication is also used to transfer data between Tivoli NetView andnon-NetView products, such as the AS/400 and its applications. Whencentralizing operations between different Tivoli NetView domains, one ormore of these communication types are used.

In addition, new to Tivoli NetView for OS/390 V1R3 is the support to convertSNMP traps to SNA NVMT alerts and vice versa, which uses the TCP/IPcommunication.

3.1.1 Communication using a LU 6.2 sessionTivoli NetView supports two LU 6.2 session types, which use differentversions of the SNA LU 6.2 protocol:

1. The Management Services (MS) transport is for low-volume transmissionsthat require high reliability, such as sending alerts.

2. The high-performance option of the MS transport is for large-volumetransmissions that require optimized network performance.

Tivoli NetViews LU 6.2 session communications are based on the

MULTIPLE_DOMAIN_SUPPORT function set described in the SNAManagement Services Reference , SC30-3346. This LU 6.2 sessiontransports are used by Management Services (MS) applications to send andreceive data.

The NetView DSI6DST task must be active to use the LU 6.2 sessiontransports.

Note


34/280


3.1.2 Communication using a LUC sessionUnlike the communication using a LU 6.2 session, the LUC session transportsupports communication only between NetView programs. The LUC tasks inthe Tivoli NetView domain must be active to use this transport mechanism. Inaddition to using the NV-UNIQ/LUC alert forwarding, the DSICRTR task mustbe active.

3.1.3 Communication using an OST-NNT sessionLike the communication using the LUC session, the OST-NNT sessiontransport supports communication only between NetView programs. Toestablish an OST-NNT session between Tivoli NetView domains, the NetViewcommand START DOMAINis used. In this way, a central NetView domain cancommunicate with a target NetView domain.

3.2 Resource Object Data Manager (RODM)

The Tivoli NetView for OS/390 uses RODM to store topology and statusinformation 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 thedistributed NetView Management Console server component is the NetViewGraphic Monitor Facility Host Subsystem (GMFHS), which is furtherexplained 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 networkresources. It stores topology data, status information, execution information,and other details about resources or classes of resources in an objectoriented data structure. Objects in RODM represent resources in the systemor in the network environment. The data cache is located entirely in thememory of the host processor and is designed for applications that need to

access, interpret, and alter large amounts of rapidly changing data in a shortperiod of time. RODM provides an open interface to enable managementapplications to use the data for automation as well as allow multipleapplications to access the data simultaneously.

It is a single source for all topology and status information that TivoliNetViews automation facilities support. The contained information in RODMis updated dynamically, which is most important to all automation facilities ofTivoli NetView for OS/390.


35/280


Based on any change in your system or network configuration as reportedthrough a NetView alert, for example, if a subsystem goes off-line, RODMdynamically updates the object information and triggers as requiredautomation procedures.

To ensure fast response time, RODM operates in memory. It supportssophisticated systems and network process control applications that need toaccess, interpret, and respond to rapidly changing configuration and status

data.

3.2.1 RODM object oriented structureIn order to operate RODM, it is necessary to load one or more physical datamodel 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 berepresented in the data model as an object. Link objects represent theconnection between two resource objects.

Class: The class defines the characteristics that are common to allobjects 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 bedefined as methods to that class of objects.

3.3 Graphic Monitor Facility Host Subsystem (GMFHS)

GMFHS manages the configuration, topology, and status updates fromRODM to the distributed NetView Management Console (NMC) application. Itresides in its own address space at the host and communicates to NetView

through the Program-to-Program Interface (PPI). The PPI serves as atransport facility for commands, views, and status information passingbetween GMFHS and the NetView program at the focal point host. Theinformation is routed over TCP/IP or LU 6.2 communication sessions betweenthe 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.


36/280


3.4 Status Display Facility (SDF)

The Status Display Facility (SDF) is a System Automation system resourcemonitoring feature that does, unlike the NetView Management Console, notrequire RODM or GMFHS to display the status of various resources of theautomation focal point and target OS/390 systems. SDF is a non-graphical,3270 session based, control panel that uses different colored and highlightedtext strings to inform the subsystem resource states. The resource typesdisplayed by SDF include:

Applications and subsystems

WTORs

Gateways

SDF is also able to show spool problems and assist requests from OS/390subcomponents. SDF consists of a hierarchy of dynamically updated panelsshowing color-coded status conditions. SDF is set up during thecustomization of System Automation for OS/390. The screen shown in Figure2 on page 23 is an actual sample of the ITSO focal point system SC66.

GMFHS is required only in the system defined as the Focal Point System orBackup Focal Point System. It is not required to be active in target systems

Note

A Gateway is a group of one NetView-NetView task session and its twoautomated operator tasks, which allows communication of messages,commands, and responses between the two NetView systems.

Note


37/280


Figure 2. SDF sample screen of focal point system SC66


38/280



39/280


Chapter 4. Customization of Tivoli NetView OS/390

This chapter details the customization process of Tivoli NetView for OS/390V1R3. The main emphasis will be a generic and fast setup approach usingsystem symbolics in the NetView common libraries. No changes should everbe made to the NetView install libraries, ensuring modifications are notdeleted when applying NetView for OS/390 PTFs. The customizations willenable system programmers to roll out several NetViews on multiple systemswith minimal additional customization efforts.

At the highest level, the installation of NetView in a multiple systemenvironment 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 whatfeatures 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 plannedenvironment. Clarify existing system symbolicsbeing used and consider any new symbolicsthat may be required or useful.

3 Full featured test install ofTivoli NetView for OS/390

Install a full featured copy of NetView on a testsystem. This will validate findings previouslyobtained and will help with the creation of thecommon/local library structure.

4 Creation of commonlibraries

Create and populate the common libraries(which is in effect an install in itself) and createa task list for the local (domain specific)installations.See Section 4.3.6.1, Local install process forthe networking NetView domains on page 38 ,for an example of a local install task list.

5 Creation of local (domainspecific) libraries

Follow the task list for each local (domainspecific) NetView installation and create andpopulate the domain specific libraries.


40/280


4.1 Planning the Tivoli NetView for OS/390 environment

The details of the project environment are outlined in Chapter 3, The ITSOautomation project environment on page 17 . It is planned to have one focalpoint system and two target systems.

In terms of NetView, this means on the Focal Point system, one Focal PointNetView for each of the automation and the network environments. For eachof the target systems, it also requires one NetView for each of the twoenvironments. The total number of NetViews for the planned environment ofthree systems is six.

The two Focal Point NetViews are planned to run as full featured enterpriseNetViews, whereas all other NetViews on the target systems are planned torun only as procedural NetViews.

In this ITSO environment, all of the six NetViews will be connected to theirindividual Resource Object Data Manager (RODM) to store and manage theindividual network and system resources.

Refer to Tivoli NetView for OS/390 Installation and Administration Guide ,SC31-8236, for full details of the NetView installation process.

Note

Refer to Tivoli NetView for OS/390 Installation and Administration Guide ,SC31-8236, for full details of the NetView installation process.

Within this ITSO project it was decided to setup the environment withoutany system resource (storage/workload) limitation. Assuming thenetworking and automation objects within the enterprise should bemanaged by their own RODM, it was chosen to run separateRODM/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 focalpoint system, when managing not too many networking and SystemAutomation objects, a configuration with only one RODM/GMFHS on thefocal point system for both environment could be chosen. For acustomization checklist, refer to Appendix C, One RODM/GMFHS focalpoint configuration on page 241 .

Note


41/280

Chapter 4. Customization of Tivoli NetView OS/390 27

For the target systems, it is noted that it is not always required to implementRODM instances (see Note box).

Only the Focal Point NetViews will have the graphical interface to the NetViewManagement Console topology servers, which will be provided by twoinstances of the Graphical Monitor Facility Host Subsystem (GMFHS).

Therefore, in addition to six NetViews to be installed and customized, therewill 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 TivoliNetView for OS/390 across multiple systems, a common library structure isstrongly recommended. Within the common libraries are those NetViewmembers that require no local customization for any particular system ordomain.

The use of common libraries exploits the concept of the OS/390 system anduser defined symbolics, as explained further in Section 4.2.3, Usage ofOS/390 system symbolics on page 32 .

4.2.1 Recommended library structure in multi-system environmentFigure 3 on page 28 will explain the recommended concept and library

structure for Tivoli NetView for OS/390 in a multi system environment.

A RODM instance on the networking target environment is only required ifnetwork resources are to be managed on that particular target system.

A RODM instance on the automation target environment is only required ifusing the System Automation enterprise monitoring functions.

Note


42/280


Figure 3. Recommended NetView library structure in a multi-systems environment

Given the recommendation for the NetView library structure, the followingtables will specify the explicit naming conventions for the NetView installlibraries, common network and automation libraries, and all domain specificlibraries.

Table 2. Tier 1: Tivoli NetView install libraries

Install library dataset names Content

NETVIEW.V1R3M0.DSIPARM Supplied DSIPARM members


43/280


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 (NetViewcommon libraries) and modify them on this library level.

If the modifications are effective only for some NetView domains, the requiredmembers need to be copied to, and afterwards modified in, the NetViewdomain specific libraries.

Table 3. Tier 2: Tivoli NetView common libraries for the Network environment

Modifications to this library level effect all instances of NetViews in theNetwork environment.

Table 4. Tier 2: Tivoli NetView common libraries for the Automation environment

NETVIEW.V1R3M0.CNMCLST Supplied CLIST members

NETVIEW.V1R3M0.CNMPNL1 Supplied PANEL members

... ...

Commo n library d ataset n ames Con tent

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, specificallyfor Network Focal Points

NETVUSER.NETWORK.CNMPNL1 Modified PANEL members

Common libra ry dataset names Conten t

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

Install library dataset names Content


44/280


Modifications to this library level effect all instances of NetViews in theAutomation environment.

If modifications are necessary to effect only some NetView domains, thencopy the required members from the NetView common libraries (or NetViewinstall 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

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 domainname. In this project, the following naming convention for the NetView domainnames 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 TivoliNetView 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 theNetView for OS/390 start-up procedure is reverse because existent members

NETVUSER.SYSTEM.CNMCLST Modified CLIST members

NETVUSER.SYSTEM.CNMCLST.ENTERP Modified CLIST members, specificallyfor Automation Focal Points

NETVUSER.SYSTEM.CNMPNL1 Modified PANEL members


NETVUSER..DSIPARM Modified DSIPARM members

NETVUSER..CNMCLST Modified CLIST members

NETVUSER..CNMPNL1 Modified PANEL members

where Denotes the specific NetView domainname, for example, SC66N or SC66A



45/280


of the domain specific libraries should be loaded first instead of members ofcommon 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 enterpriseNetwork 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 extensionsSince the ITSO project addresses two different environments, the networkingand the automation NetView environment, it was decided to not onlydifferentiate the library structures, but to extend, in addition, the OS/390subsystem definitions for NetView and RODM (GMFHS is not a subsystem).This can, for example, be achieved by editing the OS/390 system definitionmember 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 followingsubsystem and start-up procedure naming conventions for NetView andRODM (for GMFHS, just start-up procedure names):

Networking environment:

- Subsystem names:

RODM: EKGN

NetView: NETC


46/280


- Start-up procedure names:

RODM: EKGNss

NetView: NETCssN

GMFHS: GMFHSssN

where reflects the system identifier.

Automation environment:

- Subsystem names:

RODM: EKGA

NetView: NETV

- Start-up procedure names:

RODM: EKGAss

NetView: NETVssA

GMFHS: GMFHSssA

where reflects the system identifier.

4.2.3 Usage of OS/390 system symbolicsTivoli NetView for OS/390 has supported the use of MVS system and userdefined symbolics since V1R1, and each release has extended thisfunctionality.

The use of these symbolics can simplify the installation and maintenanceeffort required in a sysplex-wide implementation of Tivoli NetView for OS/390.

The symbolics used in this project are listed in Table 6 .

Table 6. System symbolics used in this project

SYMBOLI C COMMENTS

&SYSNAME. Name of the system - On the systems in this project, this was SCfollowed by the clone ID (see below).

&SYSCLONE. On the project systems, a two-character numeric field used toidentify the clone ID.

MVS V5R2M0 or higher is required for system and user defined symbolicsupport.

Note


47/280


For example, on system SC66, the values coded in the IEASYMxx member ofPARMLIB would be :

SYSNAME(SC66)SYSCLONE(&SYSNAME(3:2))

To determine current symbols on one system, issue the following MVScommand from the TSO system log (SDSF) or from the NetView NCCFinterface (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 domainname :

// DOMAIN=&SYSNAME.N, ** NETVIEW DOMAIN NAME

This enabled the usage of common JCL across systems running the sameNetView configuration (that is, procedural or enterprise).

4.3 Network management environment

For the networking environment, the results of step 1 and step 2, the processof planning and defining the networking NetView environment, were asfollows:

System SC66 running an enterprise NetView with base AON installed.

This acted as the AON focal point for all three systems. It also ran RODMand 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 withN, for example, SC66N.

The &DOMAIN. symbolic generated in this way can be used in the variousNetView configuration members and will be automatically resolved to itscorrect value. It was found that &DOMAIN. was, in fact, the most commonlyused symbolic and was the most useful in setting up the common libraries.

Note


48/280


4.3.1 Creation of common networking NetView librariesAfter completing step 3, the full featured test install of Tivoli NetView forOS/390, the next sections will describe step 4, the process ofcreation/modification of common networking libraries.

According to the recommended naming convention for the NetView librarystructure, 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 AONmembers, and the .ENTERP suffixed libraries contain modifiedmembers specific to enterprise versions of NetView.

The creation process of the common networking libraries involves workingthrough the NetView install procedures and the full featured test install ofNetView and populating the common libraries with exploitation of systemsymbolics 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 networkmanagement environment. These local customizations are further describedin Section 4.3.6, Creation of local (domain specific) NetView libraries onpage 37 .


49/280


All other networking customizations could be achieved by modifying thecommon networking library level, as described below.

4.3.1.1 Common networking DSIPARM libraryThe following table lists the modified members in the common networkingDSIPARM library.

Table 7. Modified members in NETVUSER.NETWORK.DSIPARM

4.3.1.2 Common networking DSIPARM library (specific AON)The following table lists the modified members in the common networkingDSIPARM library specifically for AON.

Table 8. Modified members in NETVUSER.NETWORK.DSIPARM.AON

MEMBER COMMENTSDSIDMNB 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=NTASK MOD=CNMTGBRW,TSKID=&DOMAIN.BRW,PRI=5,INIT=N

DSIDMNK NCCFID DOMAINID=&DOMAIN.,DMNPSW=&DOMAIN., etc.

DSITBL01 SYN %NV_DOMAIN% = '''&DOMAIN.''';

DSIVPARM VPDINITACBNAME=VPDACB,PASSWORD=&DOMAIN.,VPDREQ=001

DUIFPMEM SC = &DOMAIN.

DUIGINIT RODMNAME=RODM&SYSCLONE.NDOMAIN=&DOMAIN.

FLBSYSD RODMNAME="RODM&SYSCLONE.N"APPLNAME="&SYSNAME.NSNA"APPLPASS="&SYSNAME.N"

FLBSYSDA APPLPASS="&SYSNAME.N"

MEMBER COMMENTS

EZLCFG01 AUTOOPS GATOPER,ID=GAT&DOMAIN.


50/280


4.3.1.3 Common networking DSIPARM library (Enterprise feature)The following table lists the modified members in the common networkingDSIPARM library specifically for the Focal Point NetView (Enterprise feature).

Table 9. Modified members in NETVUSER.NETWORK.DSIPARM.ENTERP

4.3.1.4 Common networking CLIST library (Enterprise feature)The following table lists the modified members in the common networkingCLIST library specifically for the Focal Point NetView (Enterprise feature).

Table 10. Modified members in NETVUSER.NETWORK.CNMCLST.ENTERP

4.3.2 Setting up the base components NetView for OS/390After completing step 4, the process of creation of common networkinglibraries, the following sections describe the process of setting up the basecomponents of NetView for OS/390, the Resource Object Data Manager(RODM), and the Graphic Monitor Facility Host Subsystem (GMFHS).

To simplify the local process, it was first created a local install library(NETVUSER.LOCAL.INSTALL). This was shipped (asNETVUSER.&domain..INSTALL) to each domain and the local installationtasks run from there. A specimen install process and task list is shown inSection 4.3.6.1, Local install process for the networking NetView domainson page 38 .

4.3.3 Setting up the Resource Object Data ManagerUsing system symbolics and the common library structure, all of theinitialization members were included in the common libraries, and no localcustomization was required to start an instance of RODM on any system.

MEMBER COMMENTS

DSIDMNB TASK MOD=CNMCSSIR,TSKID=&DOMAIN.SIR,PRI=5,INIT=NTASK MOD=DSIZDST,TSKID=&DOMAIN.LUC,MEM=DSILUCTD,

etc.TASK MOD=CNMTARCA,TSKID=&DOMAIN.VMT,PRI=5,INIT=NTASK MOD=CNMTGBRW,TSKID=&DOMAIN.BRW,PRI=5,INIT=N

MEMBER COMMENTS

CNME1034 DUIFHPRC = 'GMFHS'||SUBSYM('&SYSCLONE.')||'N'EKGHPRC = 'EKGN'||SUBSYM('&SYSCLONE.')


51/280


4.3.4 Setting up the Graphic Monitor Facility Host SubsystemAs mentioned in Section 4.1, Planning the Tivoli NetView for OS/390environment on page 26 , it was planned to only run two GMFHS instanceson the focal point system. However, using system symbolics and commonlibrary structure, almost all of the initialization members were included in thecommon libraries, and just one local customization was required to startGMFHS on any enterprise networking system.

The only local GMFHS customization required was to change the portaddress in the member DUIFPMEM within the local DSIPARM library to avoidconflicts, as it was decided in the project to run both the networking andautomation graphical focal points in the same LPAR (SC66).

4.3.5 Setting up the Automated Operation Network featureThe initial install of the base Automated Operation Network (AON) code wasincluded in the common networking library structure and initial setup. Only afew local customizations were maintained since the exploitation of AONfunctionality was not the focus of this ITSO project.

The local customization work for AON was performed as second part of thelocal (domain specific) install process described in the next section.

4.3.6 Creation of local (domain specific) NetView librariesStep 5, the process of creation/modification of local (domain specific)NetView libraries, is the last step to get the networking NetView environmentup and running. Using a combination of system, user symbolics, and commonlibraries significantly reduced the amount of local (domain specific) tailoring.

In the ITSO project, the only local (domain specific) modification required toestablish the basic network environment was:

Focal Point NetView SC66N:

Member DUIFPMEM in the local (domain specific) DSIPARM library.

The following local (domain specific) modifications were performed for AON:

Focal Point NetView SC66N:

The services file on the NMC server also has to be updated to use thesame port address. See Tivoli NetView for OS/390: NetView Management Console Users Guide , SC31-8665, Section 1.3.6.3.

Note


52/280


Members EZLCFG01 and EZLTREE in the local (domain specific)DSIPARM library.

Procedural NetViews SC42N and SC69N:

Member EZLTREE in local (domain specific) DSIPARM library.

All NetViews SC66N, SC42N and SC69N:

Update of all DDF panels and control files in the local (domain specific)

AON panel library SEZLPNLU with the correct Domain ID.

4.3.6.1 Local install process for the networking NetView domainsThe created local install library (NETVUSER.&domain..INSTALL) was used torun the local install process. Table 11 shows the steps needed to perform thespecific install.

The TASK column cross references to the relevant section in the productdocumentation Tivoli NetView for OS/390, Installation and Administration Guide , SC31-8236.

Table 11. Local networking NetView install process

TASK COMMENTS

2.1 .9 - Allocate all PDS CNMSJ002

2.1.10 - Change domain and SAnumbers

CNMSJ000 JCL and control cards

2.1.15 - Allocate VSAM clusters CNMSJ004 - Change domain in JCL

2.1.16 - Load VSAM files CNMSJ005 - Change VSAM high-level qualifier

2.1.17 - Assemble VTAM tables CNMSJ006 - Change high-level qualifier and adddomain - may not be required if shared VTAMLIB

2.4.3 - 2.4.6 - Create procedures Specimen procedures in LOCAL.INSTALLCopy to PROCLIB and update as required

3.3.2.7 STATMON preprocessor May not be required


53/280


4.3.6.2 Local install process for AONThe TASK column in Table 12 cross references the relevant section in theproduct documentation Tivoli NetView for OS/390, Installation and Administration Guide , SC31-8236.

Table 12. Local AON install process

4.4 Automation environment

For the automation environment running System Automation, the results ofstep 1 and step 2, the process of planning and defining the automationNetView environment, were as follows:

System SC66 running an enterprise NetView with System Automationinstalled. This system acted as the automation focal point for all threesystems. It also ran RODM and GMFHS linked to an NMC server.

System SC42 running a procedural NetView with System Automationinstalled.

System SC69 running a procedural NetView with System Automationinstalled.

The NetView domain name in each case was the system name suffixed withA, for example, SC66A.

TASK COMMENTS

2.2.2 - Copy AON members tolocal (domain specific) AONpanel library SEZLPNLU

EZLSJ100 - First allocate the local (domain specific)AON library SEZLPNLU. Then run the step inEZLJS100 that copies the named members into thelocal AON library SEZLPNLU. The AON members forthe libraries DSIPRF and DSIPARM are already inthe NetView common libraries.

2.2.3 - Change domain ID Run against local SEZLPNLU only.

2.2.4 - Allocate datasets EZLSJ005, if required.

2.2.5 - Allocate RACF datasets EZLJS006, if required.

2.2.6 - Allocate VSAM files EZLJS008.

3.9.2 - Tailor DDF As required.

3.9.5 - Tailor Gateways and FP As required.


54/280


4.4.1 Creation of common automation NetView librariesThe creation of the common automation NetView libraries used to run theSystem Automation features follow the same pattern already described in thenetwork environment section.

According to the recommended naming convention for the NetView librarystructure, the following common libraries were created:

- DSIPARM:

NETVUSER.SYSTEM.DSIPARM

NETVUSER.SYSTEM.DSIPARM.ENTERP

- DSIPRF:

NETVUSER.SYSTEM.DSIPRF

- VTAMLST:

NETVUSER.SYSTEM.VTAMLST

- CLIST:

NETVUSER.SYSTEM.CNMCLST

NETVUSER.SYSTEM.CNMCLST.ENTERP- PANELS:

NETVUSER.SYSTEM.CNMPNL1

The creation process of the common automation libraries involves workingthrough the NetView install procedures and populating the common librarieswith exploitation of system symbolics to avoid the need for localcustomization 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 systemautomation environment. These local customizations are further described inSection 4.4.6, Creation of local (domain specific) NetView libraries on page50 .

All other automation customizations could be achieved by modifying thecommon automation library level as described in the following sections.

4.4.1.1 Common automation DSIPARM libraryTable 13 on page 41 lists the modified members in the common automationDSIPARM library compared to the NetView install DSIPARM library. These

7/31/2019 Automation Using Tivoli NetView OS-390 V1R3 and System Automation OS-390 V1

automation using tivoli netview os-390 v1r3 and system automation os-390 v1r3 sg245515

Documents